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

From: Martin Duke <[email-masked]>
Date: Tue, 7 Apr 2020 09:08:44 -0700

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

---

From: Neal Cardwell <[email-masked]>
Date: Tue, 7 Apr 2020 14:49:18 -0400

On Tue, Apr 7, 2020 at 12:09 PM Martin Duke <[email-masked]> wrote:
>
> Not a full review, but I may be missing something in this paragraph in Section 3:
>

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 7 Apr 2020 20:16:08 +0100

On 07/04/2020 19:49, Neal Cardwell wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> 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

---

From: Martin Duke <[email-masked]>
Date: Tue, 7 Apr 2020 13:39:41 -0700

Either is fine with me.

BTW there's no Table of Contents in the draft either.

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 27 Apr 2020 14:58:18 -0700

On Tue, Apr 7, 2020 at 1:39 PM Martin Duke <[email-masked]> wrote:
> On Tue, Apr 7, 2020 at 12:16 PM Gorry Fairhurst <[email-masked]> wrote:
>>
>>
looks fine. We'll take this paragraph you suggested.

also we'll add a ToC

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 28 Apr 2020 14:29:41 +0100

Thanks,

Gorry

-- 
G. Fairhurst, School of Engineering