Re: [tcpm] Comment on draft-ietf-tcpm-rack

[Neal Cardwell <[e-mail]>]

On Tue, Apr 7, 2020 at 12:09 PM Martin Duke <[e-mail]> wrote:
>
> Not a full review, but I may be missing something in this paragraph in Section 3:
>
>    Using a threshold for counting duplicate acknowledgments (i.e.,
>    DupThresh) alone is no longer reliable because of today's prevalent
>    reordering patterns.  A common type of reordering is that the last
>    "runt" packet of a window's worth of packet bursts gets delivered
>    first, then the rest arrive shortly after in order.  To handle this
>    effectively, a sender would need to constantly adjust the DupThresh
>    to the burst size; but this would risk increasing the frequency of
>    RTOs on real losses.
>
> In the "runt" pattern you describe, would not the returning sequence be
>
> Dupack, Ack, Ack, Ack ...
>
> So that any threshold > 1 would handle this with no problems?
>
> Martin

Thanks, I think this point about the threshold is a good point. AFAICT
the "final runt packet" case was a real problem for the FACK loss
recovery algorithm used by Linux for many years until RACK, but this
case was probably not a problem for implementations that used RFC6675
(since RFC6675 basically requires 3 packets SACKed above a hole to
mark it lost).

To address this, what do you think about the following more general
text as a replacement for that paragraph:

"Using a threshold for counting duplicate acknowledgments (i.e.,
DupThresh) alone is no longer reliable because of today's prevalent
reordering. Any time at least DupThresh packets in a flight arrive out
of order, traditional packet-counting approaches
[RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To
avoid such problems, some implementations have dynamically increased
the DupThresh packet count based on the measured degree of reordering
in sequence space; but this increases the frequency of RTOs upon real
losses in the common case of small flights of data."

Thanks,
neal