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

Randall Stewart rrs at
Fri Oct 30 16:50:54 UTC 2015

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:

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

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..


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

> On 10/30/15, 2:24 AM, "hiren panchasara"
> <owner-freebsd-transport at on behalf of
> hiren at> 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

More information about the freebsd-transport mailing list