[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTinueBFkVmR-Hd6d1Yojt+gsAV9PYw@mail.gmail.com>
Date: Sun, 19 Jun 2011 17:22:04 +0200
From: Dominik Kaspar <dokaspar.ietf@...il.com>
To: netdev@...r.kernel.org
Cc: Alexander Zimmermann <alexander.zimmermann@...sys.rwth-aachen.de>,
Yuchung Cheng <ycheng@...gle.com>,
Carsten Wolff <carsten@...ffcarsten.de>,
John Heffner <johnwheffner@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>,
Lennart Schulte <Lennart.Schulte@...sys.rwth-aachen.de>,
Arnd Hannemann <arnd@...dnet.de>
Subject: Re: Linux TCP's Robustness to Multipath Packet Reordering
Hello again,
I have another question to Linux TCP and packet reordering. What
exactly happens, when a packet is so much delayed (but not causing a
timeout), that it gets overtaken by a retransmitted version of itself?
It seems to me that this results in "SACK reneging", but I don't
really understand why...
The simplified situation goes this:
- Segment A gets sent and very much delayed (but not causing RTO)
- Segments B, C, D cause dupACKs
- Segment A_ret is retransmitted and ACKed (sent over new path)
- Some more segments E, F, ... are sent and ACKed
- Segment A (the delayed one) arrives at the receiver.
- Now what exactly happens next...?
I use default Linux TCP (with sack=1, dsack=1, fack=1, timestamps=1,
...) and the above described series of events is cause why
transparently forwarding IP packets over multiple paths with RTTs of
10 and 100 milliseconds.
I'd appreciate your help - best regards,
Dominik
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists