Re: [tcpm] GF review of draft-ietf-tcpm-rto-consider-08

[G Fairhurst <[e-mail]>]

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.

---