This I-D needs a little work WRT the RTO words, IMO.
About the doc's words ...
- I'd be interested to hear why it is RECOMMENDED to adhere to the
RTO algorithm in RFC6298. In my view, in 2016 this is just
unnecessary and wrong (see my broader opinion below). (That
said, if someone wants to use that algorithm, I think it is
fine... but, prescribing it is not needed, IMO.)
- I'd also like to see the normative text better underscore the
importance of backoff.
- "TCP requires the initial RTT to be set to no less than 1
second" ... TCP requires the initial ***RTO*** be no less than 1
second. There is a difference between the RTT and the RTO and
this draft is pretty liberal with using them interchangeably
(which is both confusing and wrong).
- And, it isn't quite clear whether the document is saying that UDP
apps should use the full 6298 algorithm or just that for computing
the SRTT. If the former then why discuss the SRTT? And, if the
latter then it needs to better indicate how UDP apps are supposed to
use half the algorithm.
- Further, it notes the RTT is used for things like rate control
that I am not sure 6298 applies to. Certainly it wasn't
designed for that. Do we know it is reasonable for rate
control? Is it important we nail down the precise RTT
estimation for rate control?
A broader opinion is that we should just elide these words in favor
of a set of general RTO guidelines that span protocols (see
draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TCPM
for now because TCP is where it started, but comments would be
appreciated from all corners).
FWIW.
allman
--
http://www.icir.org/mallman/
signature.asc
Description: PGP signature