Date: Sat, 19 Nov 2016 14:50:50 +0100 From: Michael Tuexen <tuexen@freebsd.org> To: hiren panchasara <hiren@strugglingcoder.info> Cc: freebsd-transport@freebsd.org Subject: Re: Loss recovery at tail Message-ID: <8F1153AE-7BB1-4393-8D90-70E9FEF458AF@freebsd.org> In-Reply-To: <20161118231307.GN42586@strugglingcoder.info> References: <3A9A8225-A296-408F-BEC5-3E9CEFB65AF0@freebsd.org> <20161118231307.GN42586@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19 Nov 2016, at 00:13, hiren panchasara = <hiren@strugglingcoder.info> wrote: >=20 > On 11/18/16 at 09:20P, Michael Tuexen wrote: >> Dear all, >>=20 >> in the last telco we discussed the behaviour when that last N packets = are dropped. >> It was mentioned that multiple retransmission timers where used to = recover. >>=20 >> I wrote a packetdrill script which >> * Get the cwnd to 30 segments >> * Sends 30 segments, which all get lost >> * Observe how the 30 dropped segments are retransmitted. >>=20 >> It uses only a single timeout as one would expect. >> So this script does NOT reproduce the problem, but I'm attaching it = such that >> you can see how the stack behaves. >> Tested with FreeBSD head r308802. >=20 > Thanks for testing. >=20 > https://reviews.freebsd.org/D8556 was the issue detecting a valid > RTO as bad and resetting snd_nxt to snd_max (instead of snd_una as = done by > valid RTO) causing us to not trigger retransmit of missed packets but > wait for RTO for all of lost packets. Ahh, I see. Thanks for the pointer. Best regards Michael >=20 > Cheers, > Hiren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F1153AE-7BB1-4393-8D90-70E9FEF458AF>