Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Fragment\s+ID\s+wrap\s+workaround\s+$read\-only\,\s+untested$\.\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Fragment\s+ID\s+wrap\s+workaround\s+$read\-only\,\s+untested$\.\s*$/: 22 ]

Total 22 documents matching your query.

1. Fragment ID wrap workaround (read-only, untested). (score: 1): Author: iguang Shi <wgshi2002@xxxxxxxx>; Date: Thu, 15 Jul 2004 15:57:58 +1000; Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround St; /archives/netdev/2004-07/msg00379.html (22,065 bytes)
2. Fragment ID wrap workaround (read-only, untested). (score: 1): Author: sahide NAKAMURA <nakam@xxxxxxxxxxxxxx>; Date: Thu, 15 Jul 2004 16:36:56 +1000; Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround St; /archives/netdev/2004-07/msg00383.html (22,079 bytes)
3. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: ahide NAKAMURA <nakam@xxxxxxxxxxxxxx>; Date: Thu, 15 Jul 2004 02:28:05 -0600; Those ideas should work if both sides are Linux, but not when mixing with something else. A non-Linux receiver won't detect wrap and drop the packet, generally, even if the fragments overlap and don; /archives/netdev/2004-07/msg00384.html (10,187 bytes)
4. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author:; Date: Thu, 15 Jul 2004 11:27:17 +0200; Won't that make the worst case behaviour on a congested link much worse? e.g. consider a very congested link with variable RTTs. Or a link that works relatively smoothly and suddenly the RTT increase; /archives/netdev/2004-07/msg00385.html (9,696 bytes)
5. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: Schubert-While); Date: Thu, 15 Jul 2004 07:49:13 -0700; Andi Kleen <ak@xxxxxxx> wrote on 07/15/2004 02:27:17 AM: I know what you mean here, but just to be precise, this isn't an RTT estimator, but an estimator for the time to receive a complete set of fra; /archives/netdev/2004-07/msg00394.html (11,757 bytes)
6. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: xxxxxxxxx>; Date: Thu, 15 Jul 2004 18:27:35 +0200; The data corruption problem only starts to become a real issue at Gigabit Speeds and faster. Normally such congested links are much slower [...] I'm well aware of the Gigabit+ NFS problem. My standar; /archives/netdev/2004-07/msg00401.html (11,018 bytes)
7. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: t-While); Date: Thu, 15 Jul 2004 12:24:45 -0400 (EDT); FYI, we have an informational internet-draft documenting this problem. Currently can be foud at: <http://www.ietf.org/internet-drafts/draft-mathis-frag-harmful-00.txt>. -John; /archives/netdev/2004-07/msg00403.html (8,846 bytes)
8. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: >; Date: Thu, 15 Jul 2004 09:54:53 -0700; Andi Kleen wrote on 07/15/2004 09:27:35 AM: solve No disagreement here. That's the problem it's intended to solve, but of course any actual solution would have to behave well for all links, and that'; /archives/netdev/2004-07/msg00406.html (10,096 bytes)
9. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: adi@xxxxxxxxxx>; Date: Thu, 15 Jul 2004 19:34:09 +0200; I'm pretty sure inet->id is wrong here. You would like the counter in the inet peer entry. inet_sk(sk)->id is just used for the pseudo counter in TCP that only works around VJ compression bugs. It's; /archives/netdev/2004-07/msg00411.html (9,095 bytes)
10. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: rrilhes <jt@xxxxxxxxxxxxxxxxxx>; Date: Thu, 15 Jul 2004 19:02:49 +0200; I wouldn't go that far, just make extremly sure that any solution works on slow links too. The problem I see is that if you make the delay factor long enough to make the extremly variable links not r; /archives/netdev/2004-07/msg00412.html (9,362 bytes)
11. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: r@xxxxxxxx>; Date: Tue, 27 Jul 2004 14:38:42 +0200; In the scenarios we were looking at, packet loss rate was fairly low. What compounded the problem was that the NFS payload wasn't very varied, so the UDP checksum distribution was far from even. Whe; /archives/netdev/2004-07/msg00610.html (11,029 bytes)
12. Fragment ID wrap workaround (read-only, untested). (score: 1): Author: "Rusty Russell (IBM)" <rusty@xxxxxxxxxxx>; Date: Thu, 15 Jul 2004 15:57:58 +1000; Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround St; /archives/netdev/2004-07/msg01195.html (22,065 bytes)
13. Fragment ID wrap workaround (read-only, untested). (score: 1): Author: "Rusty Russell (IBM)" <rusty@xxxxxxxxxxx>; Date: Thu, 15 Jul 2004 16:36:56 +1000; Hi all, I spoke about this today, thought I'd send the code out. Useful only for reading, as it's entirely untested and some is tricky and needs careful thinking. Name: Fragment ID Wrap Workaround St; /archives/netdev/2004-07/msg01199.html (22,079 bytes)
14. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: David Stevens <dlstevens@xxxxxxxxxx>; Date: Thu, 15 Jul 2004 02:28:05 -0600; Rusty, Those ideas should work if both sides are Linux, but not when mixing with something else. A non-Linux receiver won't detect wrap and drop the packet, generally, even if the fragments overlap a; /archives/netdev/2004-07/msg01200.html (10,247 bytes)
15. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Thu, 15 Jul 2004 11:27:17 +0200; Won't that make the worst case behaviour on a congested link much worse? e.g. consider a very congested link with variable RTTs. Or a link that works relatively smoothly and suddenly the RTT increase; /archives/netdev/2004-07/msg01201.html (9,886 bytes)
16. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: David Stevens <dlstevens@xxxxxxxxxx>; Date: Thu, 15 Jul 2004 07:49:13 -0700; Andi Kleen <ak@xxxxxxx> wrote on 07/15/2004 02:27:17 AM: I know what you mean here, but just to be precise, this isn't an RTT estimator, but an estimator for the time to receive a complete set of fra; /archives/netdev/2004-07/msg01210.html (11,787 bytes)
17. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Thu, 15 Jul 2004 18:27:35 +0200; The data corruption problem only starts to become a real issue at Gigabit Speeds and faster. Normally such congested links are much slower [...] I'm well aware of the Gigabit+ NFS problem. My standar; /archives/netdev/2004-07/msg01217.html (11,178 bytes)
18. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: John Heffner <jheffner@xxxxxxx>; Date: Thu, 15 Jul 2004 12:24:45 -0400 (EDT); FYI, we have an informational internet-draft documenting this problem. Currently can be foud at: <http://www.ietf.org/internet-drafts/draft-mathis-frag-harmful-00.txt>. -John; /archives/netdev/2004-07/msg01219.html (8,926 bytes)
19. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: David Stevens <dlstevens@xxxxxxxxxx>; Date: Thu, 15 Jul 2004 09:54:53 -0700; Andi Kleen wrote on 07/15/2004 09:27:35 AM: solve No disagreement here. That's the problem it's intended to solve, but of course any actual solution would have to behave well for all links, and that'; /archives/netdev/2004-07/msg01222.html (10,130 bytes)
20. Re: Fragment ID wrap workaround (read-only, untested). (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Thu, 15 Jul 2004 19:34:09 +0200; I'm pretty sure inet->id is wrong here. You would like the counter in the inet peer entry. inet_sk(sk)->id is just used for the pseudo counter in TCP that only works around VJ compression bugs. It's; /archives/netdev/2004-07/msg01227.html (9,213 bytes)

Current List: 1 - 20
Page: [1] [2]