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

[Yuchung Cheng <[e-mail]>]

On Tue, Apr 7, 2020 at 1:39 PM Martin Duke <[e-mail]> wrote:
>
> Either is fine with me.
>
> BTW there's no Table of Contents in the draft either.
>
> On Tue, Apr 7, 2020 at 12:16 PM Gorry Fairhurst <[e-mail]> wrote:
>>
>>
>> On 07/04/2020 19:49, Neal Cardwell wrote:
>> > 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
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > [e-mail]
>> > 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."
looks fine. We'll take this paragraph you suggested.

also we'll add a ToC



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