Subject: Re: Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice

From: Mark Allman <[email-masked]>
Date: Tue, 31 May 2016 14:57:57 -0400

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/