Date: Fri, 30 Oct 2015 09:50:56 -0700 From: Randall Stewart <rrs@netflix.com> To: Jonathan Looney <jlooney@juniper.net> Cc: hiren panchasara <hiren@strugglingcoder.info>, FreeBSD Transports <transport@FreeBSD.org> Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Message-ID: <4C66DD2E-DFD0-4334-B14F-16289DC82A41@netflix.com> In-Reply-To: <D258E1AC.4A234%jlooney@juniper.net> References: <DA8A5844-8F11-42D5-B923-3F329203B867@netflix.com> <20151030062423.GB5261@strugglingcoder.info> <D258E1AC.4A234%jlooney@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I don=92t think you would reset the counter just because a hole was = broken up. You are either getting re-ordering in combination with TSO or possibly a retransmission which fills in some but not all of the hole.. And as to the =93rewrite=94 I am not sure its needed, its complex code I = will admit but it does seem to work. I would say only rewrite if its needed to make = the strike per hole work. Of course we need to think about this a bit more. Generally we know what = the =93new data=94 is in a SACK, so thats probably key. Hiren also pointed = out a recent Google draft to me: https://tools.ietf.org/html/draft-cheng-tcpm-rack-00 It seems to me that this is a very good thing :-) Of course there are lots of other things that need to be implemented = with it.. reorder detection being one.=20 I would imagine this is a big source of some of the gains that Quic gets = in recovery.. if you note Jana is noted in the Ack=92s section for his implementation in Quic.. R On Oct 30, 2015, at 6:09 AM, Jonathan Looney <jlooney@juniper.net> = wrote: > On 10/30/15, 2:24 AM, "hiren panchasara" > <owner-freebsd-transport@freebsd.org on behalf of > hiren@strugglingcoder.info> wrote: >=20 >> (Something Randall and I discussed today) >>=20 >> On 10/07/15 at 12:17P, Randall Stewart via freebsd-transport wrote: >>>=20 >>> 3) When we have more than one hole the goal of SACK was to = retransmit >>> every time that >>> a hole had 3 dup-acks so that one could recover multiple blocks >>> that were lost. We just >>> plain don?t track dup-acks per hole. We do continue to count, but >>> we will wait to retransmit >>> anything until after we have drained 1/2 the data in flight from >>> the network at a minimum. And only then >>> do we start incrementing cwnd (remember we crashed it to 1 MTU) = so >>> that we can retransmit. There >>> may be some other twists in the code that we are missing but this >>> is what we believe (this could could >>> probably win the C obfuscation contest if someone were willing to >>> enter it :-D) >>=20 >> Wondering if we can add this dupack counter in struct sackhole {} and >> every time we process acks with sack in tcp_sack_doack(), we = increment >> this counter if the same hole appears again. And retransmit it on (or >> after?) 3rd dupack. >=20 > The SACK hole-tracking code is already quite complex. If we're going = to > make a fundamental change, perhaps it is time to consider a rewrite, > rather than a smaller patch? Maybe this is the best code we can write. = Or, > maybe it is time for a re-coding to make it more easily accessible. >=20 > In any case, how do you propose tracking holes that are carved up by = later > packets? >=20 > E.g. >=20 > Hole is 1:1500. >=20 > Then, you receive a packet with 500:750, leaving two holes. >=20 > Then, you receive a packet with 1000:1250, leaving three holes. >=20 > Do you charge all three holes with the duplicate ACKs? Do you copy the > counter to the holes? >=20 > Or, is the fact that the ACK is slightly different enough to reset the > counter? >=20 > If you reset the counter anytime the hole is broken up, it will take a > while to get to three in a really out-of-order network scenario. On = the > other hand, if you don't reset the counter, you may retransmit too = fast. >=20 > Just my initial reaction... >=20 > Jonathan -------- Randall Stewart rrs@netflix.com 803-317-4952
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C66DD2E-DFD0-4334-B14F-16289DC82A41>