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

[hiren panchasara]

Getting back to this old thread...

On 10/30/15 at 01:09P, Jonathan Looney 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.

As Randall said (in response to this), that rewrite is not necessary. And
I agree to that. I don't see tcp_sack.c being in that bad shape that it
demands a rewrite. But ofc, if you have something really cleaner/faster
in mind, I'm all ears. :-)
> 
> In any case, how do you propose tracking holes that are carved up by later
> packets?

I think this scenario is rather easy as a single hole is being carved
out bellow:
Let me know if I am missing anything obvious.
> 
> E.g.
> 
> Hole is 1:1500.

hole1: strike=1
> 
> Then, you receive a packet with 500:750, leaving two holes.

subhole 1:500 strike=2, subhole 750:1500 strike=2
> 
> Then, you receive a packet with 1000:1250, leaving three holes.

subhole 1:500 strike=3, subhole 750:1000 strike=3, subhole 1250:1500 strike=3
> 
> 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?

Basically, whenever a hole gets broken up, subholes carry-forward the
dupack strike 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.

By 'too fast', I think you mean spurious retransmissions. If so, can you
explain a bit more?

> 
> Just my initial reaction...

Thanks you for the discussion!

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20151116/c23938d8/attachment.bin>