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

On 07/04/2020 19:49, Neal Cardwell wrote:
> On Tue, Apr 7, 2020 at 12:09 PM Martin Duke <martin.h.duke@gmail.com> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

Neil, would you accept something that doesn't inflame a discussion of 
what is prevalent and where?

Such as:

"Using a threshold for counting duplicate acknowledgments (i.e.,
DupThresh) alone is not reliable in the presence of significant packet
reordering. Any time at least DupThresh packets in a flight arrive out
of order, traditional packet-counting approaches
[RFC5681][RFC6675][FACK] can incur 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 actual
losses in the common case of small flights of data."

- and would you allow "dynamically increased
the DupThresh packet count (e.g., methods based on RFC5960)"?

Gorry