Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\/PATCH\]\s+\"strict\"\s+ipv4\s+reassembly\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\/PATCH\]\s+\"strict\"\s+ipv4\s+reassembly\s*$/: 160 ]

Total 160 documents matching your query.

81. [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Arthur Kepner <akepner@xxxxxxx>; Date: Tue, 17 May 2005 09:18:26 -0700 (PDT); The Problem -- There's a well-known problem with IPv4 fragmentation/ reassembly - the 16-bit IP ID can uniquely identify only 65535 datagrams, and a gigabit/sec source can emit that many datagrams in; /archives/netdev/2005-05/msg01892.html (20,425 bytes)
82. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 17 May 2005 10:49:47 -0700 (PDT); Even the most simplistic flow over the real internet can get slight packet reordering. Heck, reordering happens on SMP on any network. IP is supposed to be resilient to side effects of network topolo; /archives/netdev/2005-05/msg01894.html (9,382 bytes)
83. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Arthur Kepner <akepner@xxxxxxx>; Date: Tue, 17 May 2005 11:28:05 -0700 (PDT); IP was designed a looong time ago. I think it's reasonable to make (or at least allow for) some accomodation when networking bandwidths have gone up by several orders of magnitude. (And while we wait; /archives/netdev/2005-05/msg01895.html (9,994 bytes)
84. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Tue, 17 May 2005 20:38:25 +0200; If anything it would be better as a per route flag. Then you could set it only for your local network where you know Gigabit happens and reordering might be avoidable in some cases. -Andi P.S.: Arthu; /archives/netdev/2005-05/msg01896.html (10,615 bytes)
85. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Pekka Savola <pekkas@xxxxxxxxxx>; Date: Tue, 17 May 2005 21:45:00 +0300 (EEST); If more explicit analytical or theoretical background would be convincing, look no further than http://www.watersprings.org/pub/id/draft-mathis-frag-harmful-00.txt -- Pekka Savola "You each name your; /archives/netdev/2005-05/msg01897.html (10,534 bytes)
86. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 17 May 2005 11:48:29 -0700 (PDT); Can I tell users to call you when they enable the strict fragmentation and they can no longer talk UDP to remote sites outside of their subnet, or it breaks on their heavily SMP machine due to natura; /archives/netdev/2005-05/msg01898.html (10,099 bytes)
87. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 17 May 2005 11:50:20 -0700 (PDT); This is still bogus, on SMP we get packet reordering all the time. I already know it happens, and that IBM has gotten NFS corruption due to this problem. Using NFS over UDP is stupid. I find it ironi; /archives/netdev/2005-05/msg01899.html (10,491 bytes)
88. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: John Heffner <jheffner@xxxxxxx>; Date: Tue, 17 May 2005 14:57:38 -0400; It would be better still to have a per-route packet reassembly timeout in milliseconds. Expecting perfect ordering seems very fragile even for a LAN. -John; /archives/netdev/2005-05/msg01900.html (11,589 bytes)
89. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Rick Jones <rick.jones2@xxxxxx>; Date: Tue, 17 May 2005 11:56:55 -0700; I already know it happens, and that IBM has gotten NFS corruption due to this problem. Frankengrams can be fun :) Using NFS over UDP is stupid. I find it ironic to claim that folks are "stuck with UD; /archives/netdev/2005-05/msg01901.html (10,648 bytes)
90. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Nivedita Singhvi <niv@xxxxxxxxxx>; Date: Tue, 17 May 2005 12:01:26 -0700; 1) Fragments must arrive in order (or in reverse order) - out of order fragments are dropped. Even the most simplistic flow over the real internet can get slight packet reordering. Heck, reordering; /archives/netdev/2005-05/msg01902.html (12,877 bytes)
91. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 17 May 2005 12:09:50 -0700 (PDT); I agree. And if we can setup the infrastructure such that the drivers can indicate the speed of the link they are communicating on, then we can set sane default values on the automatically created su; /archives/netdev/2005-05/msg01903.html (10,686 bytes)
92. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Rick Jones <rick.jones2@xxxxxx>; Date: Tue, 17 May 2005 12:13:35 -0700; This is a fast LAN problem - real internet latencies don't allow for the wrapping of the id field that fast. What is a "fast" LAN these days? We were seeing IP ID wrap with NFS traffic back in the ti; /archives/netdev/2005-05/msg01904.html (11,989 bytes)
93. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Tue, 17 May 2005 21:17:30 +0200; In fact I implemented that a long time ago for the SUSE 2.4 kernel. But for some reason nobody liked it very much, so I never submitted it. I can dig out the old patches if there is interest. -Andi; /archives/netdev/2005-05/msg01905.html (11,017 bytes)
94. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Rick Jones <rick.jones2@xxxxxx>; Date: Tue, 17 May 2005 12:21:47 -0700; It would be better still to have a per-route packet reassembly timeout in milliseconds. I agree. And if we can setup the infrastructure such that the drivers can indicate the speed of the link they a; /archives/netdev/2005-05/msg01906.html (11,246 bytes)
95. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Nivedita Singhvi <niv@xxxxxxxxxx>; Date: Tue, 17 May 2005 12:25:31 -0700; This is a fast LAN problem - real internet latencies don't allow for the wrapping of the id field that fast. What is a "fast" LAN these days? We were seeing IP ID wrap with NFS traffic back in the t; /archives/netdev/2005-05/msg01907.html (13,266 bytes)
96. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 17 May 2005 12:26:23 -0700; It would be better still to have a per-route packet reassembly timeout in milliseconds. I agree. And if we can setup the infrastructure such that the drivers can indicate the speed of the link they a; /archives/netdev/2005-05/msg01908.html (12,116 bytes)
97. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: John Heffner <jheffner@xxxxxxx>; Date: Tue, 17 May 2005 15:31:36 -0400; The problem is latency independent. -John; /archives/netdev/2005-05/msg01909.html (10,683 bytes)
98. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Rick Jones <rick.jones2@xxxxxx>; Date: Tue, 17 May 2005 12:33:30 -0700; 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 latenc; /archives/netdev/2005-05/msg01910.html (11,669 bytes)
99. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Nivedita Singhvi <niv@xxxxxxxxxx>; Date: Tue, 17 May 2005 12:52:20 -0700; Yes, a different manifestation of the problem ;). I was talking in the context of current Linux code and the common ethernet drivers and typical current Internet/Intranet latencies. The problem is l; /archives/netdev/2005-05/msg01912.html (11,238 bytes)
100. Re: [RFC/PATCH] "strict" ipv4 reassembly (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Tue, 17 May 2005 21:53:08 +0200; But it has PAWS at least. But I agree even IPv6 fragmentation with 32bit IDs is not significantly safer. -Andi; /archives/netdev/2005-05/msg01913.html (11,474 bytes)

Current List: 81 - 100
Page: [1] [2] [3] [4] [5] [6] [7] [8]