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

[Martin Duke <[e-mail]>]

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