[tcpm] review of draft-ietf-tcpm-rto-consider-08

[Jana Iyengar <[e-mail]>]

Gah! Now with a (better) subject line.

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

> 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
>