Question:
1- Is this not an issue that would have been seen elsewhere? We can not
be the first people to have SACK enabled behind a NAT? What is it about
our situation which catches this? Or are we all just late to the party?
Plus SACK was invented originally for a purpose so probably do not want
to turn it off if we can avoid it. Perhaps it should be re-enabled on
the on the DPM and TB-support advice should be to SACK=0 for all WNs.
Only a suggestion and would like comments...
I also agree with the previous point, if this is such a basic level
problem in terms of a problem in the tcp stack; why is this problem not
seen more widely across WLCG?
Brian
-----Original Message-----
From: Testbed Support for GridPP member institutes
[mailto:[log in to unmask]] On Behalf Of Stephen Burke
Sent: 30 June 2010 22:28
To: [log in to unmask]
Subject: Re: LHCb transfer problem + solution
Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Ewan MacMahon said:
> Given that this phenomenon is somewhat timing dependent, would it be
> reasonable to describe it as a sack race condition?
NIC nack lacks ack back, packets back-track - NAT trick sucks. Quick fix
hack: nix sack.
Stephen
(I'll get my Pacamac)
|