Date: Fri, 30 Oct 2015 13:09:23 +0000 From: Jonathan Looney <jlooney@juniper.net> To: hiren panchasara <hiren@strugglingcoder.info>, Randall Stewart <rrs@netflix.com> Cc: FreeBSD Transports <transport@FreeBSD.org> Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Message-ID: <D258E1AC.4A234%jlooney@juniper.net> In-Reply-To: <20151030062423.GB5261@strugglingcoder.info> References: <DA8A5844-8F11-42D5-B923-3F329203B867@netflix.com> <20151030062423.GB5261@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/30/15, 2:24 AM, "hiren panchasara"
<owner-freebsd-transport@freebsd.org on behalf of
hiren@strugglingcoder.info> wrote:
>(Something Randall and I discussed today)
>
>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)
>
>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.
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.
In any case, how do you propose tracking holes that are carved up by later
packets?
E.g.
Hole is 1:1500.
Then, you receive a packet with 500:750, leaving two holes.
Then, you receive a packet with 1000:1250, leaving three holes.
Do you charge all three holes with the duplicate ACKs? Do you copy the
counter to the holes?
Or, is the fact that the ACK is slightly different enough to reset the
counter?
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.
Just my initial reaction...
Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D258E1AC.4A234%jlooney>