|Subject:||Re: [RFC/PATCH] "strict" ipv4 reassembly|
|From:||Rick Jones <rick.jones2@xxxxxx>|
|Date:||Tue, 17 May 2005 12:33:30 -0700|
|References:||<Pine.LNX.4.61.0505170914130.29021@xxxxxxxxxx> <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <m1zmut7l5q.fsf@xxxxxx> <428A3F86.1020000@xxxxxxxxxx> <428A425F.7000807@xxxxxx> <428A452B.2010008@xxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304|
Actually, the problem is much worse now - we have virtual partitions in the Xen environment for instance where some packets are headed for local consumption (virtual network, no actual network latency to speak of) and some going out to the network. Having a global IP id generator just won't be able to keep up - we could wrap in submilliseconds...
and the classic TCP sequence number isn't _really_ all that far behind :)
The larger NFS UDP mount sizes mean more fragments, but intriguingly, they also mean slower wrap of the IP ID space :)True, but in a 32 NIC environment, see how they wrap ;)...
Yep - I'd thought that just about everyone had gone to per-dest or per-route IP ID's by now, but even then
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [RFC/PATCH] "strict" ipv4 reassembly, John Heffner|
|Next by Date:||Re: [PATCH 11/12] orinoco: monitor mode support, Pavel Roskin|
|Previous by Thread:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Rick Jones|
|Next by Thread:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Andi Kleen|
|Indexes:||[Date] [Thread] [Top] [All Lists]|