|Subject:||Re: [RFC] netif_rx: receive path optimization|
|From:||Rick Jones <rick.jones2@xxxxxx>|
|Date:||Thu, 31 Mar 2005 16:42:11 -0800|
|References:||<email@example.com> <firstname.lastname@example.org> <email@example.com> <424C6A98.firstname.lastname@example.org> <email@example.com> <424C7CDC.firstname.lastname@example.org> <424C81B8.email@example.com> <424C8790.firstname.lastname@example.org> <email@example.com>|
|User-agent:||Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304|
Well, I'm in an email discussion with someone who seems to bump their TCP windows quite large, and disable timestamps...
Minor nit - potential data corruption, perhaps even probable, but I don't think they are all that concerned yet - feeling secure in their belief that 2*MSL on a LAN is rather short indeed, and perhaps even in WANs where using 1GB TCP windows (although I may have mixed too much together there).
Of course, if we believe that stacks should be smart enough to limit the initial receive windows (or does a setsockopt() actrually override that?), and grow them over time based on what the transfer rates might be and the like, perhaps the stack should have a hard interlock on TCP window >= 65535 and timestamp option on. No timestamps, no window > 65535 bytes. At present, it seems possible to have one without the other. Of course, if one is indeed on a "LAN" and _knows_ (somehow, given the existence of remote bridges) that it is a LAN.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [RFC] netif_rx: receive path optimization, Nivedita Singhvi|
|Next by Date:||Re: RFC: Redirect-Device, jamal|
|Previous by Thread:||Re: [RFC] netif_rx: receive path optimization, Stephen Hemminger|
|Next by Thread:||Re: [RFC] netif_rx: receive path optimization, Nivedita Singhvi|
|Indexes:||[Date] [Thread] [Top] [All Lists]|