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

Thanks,

Gorry

On 27/04/2020 22:58, Yuchung Cheng wrote:
> On Tue, Apr 7, 2020 at 1:39 PM Martin Duke <martin.h.duke@gmail.com> 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 <gorry@erg.abdn.ac.uk> wrote:
>>>
>>> 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."
> 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

-- 
G. Fairhurst, School of Engineering