Maintaining dupack counter per hole (was: The trouble with sack..)

[Randall Stewart]

I don’t 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 “rewrite” 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
“new data” 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. 

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’s section for his implementation in Quic..

R

On Oct 30, 2015, at 6:09 AM, Jonathan Looney <jlooney at juniper.net> wrote:

> On 10/30/15, 2:24 AM, "hiren panchasara"
> <owner-freebsd-transport at freebsd.org on behalf of
> hiren at strugglingcoder.info> wrote:
> 
>> (Something Randall and I discussed today)
>> 
>> On 10/07/15 at 12:17P, Randall Stewart via freebsd-transport wrote:
>>> 
>>> 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

--------
Randall Stewart
rrs at netflix.com
803-317-4952