Subject: [tcpm] (no subject)

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Nov 2019 11:54:51 +0800

Mark,

Apologies for this late review. It's been a while since I read the draft,
and I have just a couple of comments.

I have one high-order point. The document limits itself to transports where
loss detection *and retransmission* occurs. Specifically, Section (S.2)
says: "The requirements in this document only apply to cases where loss
detected via a timer is repaired by a retransmission of the original data.
Other cases are certainly possible---e.g., replacing the lost data with an
updated version---but fall outside the scope of this document."

There are a couple of other places as well ("all timer-based retransmission
mechanisms", and also in requirement (3)). I would suggest that the draft
applies to loss detection, not to recovery or retransmission. Specifically,
QUIC detects loss using a Probe Timeout (equivalent to an RTO), but may not
retransmit lost data for a variety of reasons. Is there a reason to
preclude this behavior?

More generally, TCP conflates *what* to send with *when* to send it, and
whether to send something is presumed "yes". QUIC decouples these pieces,
and that may be true of other future protocols as well. (This is true of
SCTP using the partial-reliability extension as well, RFC 3758).

The requirements in the document already apply to these protocols, because
the principles apply to the loss detection function of the transport, not
the recovery function.

In terms of text changes, I think simply removing "and retransmission" from
most places is adequate to achieve this. Requirement (3) however relies on
the data getting acked, which can be generalized. The current text is:
"The backoff SHOULD be removed after the successful repair of the lost data
and subsequent transmission of non-retransmitted data."
This can be replaced by:
"The backoff SHOULD be removed after an acknowledgement is received for a
subsequently sent packet."
---

Editorial suggestions:
- remove para beginning with "This document is a bit "weird" ...", and also
drop the phrase "At this point, however" from the beginning of the next
para. This is unnecessary text, IMO.
- Take it or leave it: change title from "Requirements" to "Guidelines".

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Nov 2019 11:56:52 +0800

Gah! Now with a (better) subject line.

On Fri, Nov 22, 2019 at 11:54 AM Jana Iyengar <[email-masked]> wrote:

> I have one high-order point. The document limits itself to transports
> where loss detection *and retransmission* occurs. Specifically,
> Section (S.2) says: "The requirements in this document only apply to cases
> where loss detected via a timer is repaired by a retransmission of the
> original data. Other cases are certainly possible---e.g., replacing the
> lost data with an updated version---but fall outside the scope of this
> document."
>
> There are a couple of other places as well ("all timer-based
> retransmission mechanisms", and also in requirement (3)). I would suggest
> that the draft applies to loss detection, not to recovery or
> retransmission. Specifically, QUIC detects loss using a Probe Timeout
> (equivalent to an RTO), but may not retransmit lost data for a variety of
> reasons. Is there a reason to preclude this behavior?
>
> In terms of text changes, I think simply removing "and retransmission"
> from most places is adequate to achieve this. Requirement (3) however
> relies on the data getting acked, which can be generalized. The current
> text is:
> "The backoff SHOULD be removed after the successful repair of the lost
> data and subsequent transmission of non-retransmitted data."
> This can be replaced by:
> - remove para beginning with "This document is a bit "weird" ...", and
> also drop the phrase "At this point, however" from the beginning of the
> next para. This is unnecessary text, IMO.

---

From: G Fairhurst <[email-masked]>
Date: Fri, 22 Nov 2019 12:12:01 +0800

I presented slides to motivate more review of RTO-consider, (as an 
invited reviewer providing individual comments), so it seemed useful to 
copy these comments in the TCPM list,
best wishes,

Gorry

---

I read draft-ietf-tcpm-rto-consider-08.

I found this *is* readable.
The basis seems correct to me.
It (mostly) comes to the same “conclusions” as CC Guidelines (an 
individual draft) and this can I think proceed in parallel - I don't see 
that any future CC Guidelines needs to proceed first.
---
(Comment 1)
This sets out to BCP status, which makes me note:
Current text: "The correct way to
view this document is as the default case and these other specifications 
as agreed upon deviations from the default."
- where as the abstract concludes:
Current text: "Within the requirements, implementations have latitude
to define particulars that best address each situation."
- My comment is ... Does this really update existing RFCs?

As also current text:
E.g., a protocol like SCTP (or DCCP) could leverage...

- Is that over-riding the RFCs that define these, or is this intended as 
something more like:
“E.g., a new protocol with a design like SCTP [RFC4960] could leverage”
---
(Comment 2)
Current text: "In steady state the RTO SHOULD be set based on recent
observations of both the FT and the variance of the FT."
- I don’t think these are wrong, but I think the advice of "recent" is 
not very crisp for a BCP - how recent? Can we set any upper bound or 
motivate how we would judge whether a protocol met the "SHOULD"?

---
(Comment 3)
Current text: "FT observations SHOULD be taken regularly ...
The notion of "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where that 
happens less frequently than once per RTT."
- To me, this reads as impossible to read RFC2119 text, is this a 
definition or something else? or Designs are REQUIRED to define ... etc.

I hope this actually is intended to be:

I wonder if this proposed text below could be better "FT observations 
SHOULD be taken be at least once
per RTT or as frequently as data is exchanged in cases where that 
happens less frequently than once per RTT."
----
(Comment 4)
Current text: "Retransmissions triggered by the RTO mechanism MUST be 
taken as indications of network congestion and the sending rate adapted 
using a standard mechanism (e.g., TCP collapses the congestion window to 
one segment [RFC5681]).
- Is this the word intended to be /retransmissions/, or a time-out of 
the RTO?
(in CC guidelines this described as a lack of response that needs to be 
handled in this way).
---
(Comment 5)
Current text: "Finally, we note that while allowing implementations to 
be more aggressive may in fact increase the number of needless 
retransmissions"
- Textual NiT: I think it would be wiser to say /could/ rather than 
/may/ to be sure no-one seems readable as potentially permissive.

---