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

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 17 Jun 2016 13:45:08 +0000

Hi,

On 2016-05-31, at 20:57, Mark Allman <[email-masked]> wrote:
>  - 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.)

because it's a reasonable example for which we have a spec. I'm happy to recommend something else that is reasonable.

>  - I'd also like to see the normative text better underscore the
>    importance of backoff.

More than we currently do?

   It is important to note that the initial timeout value is not the
   maximum possible timeout -- the RECOMMENDED algorithm in [RFC6298]
   doubles the measured RTT value after each timeout (e.g., [RFC3261]).
   After a series of timeouts, this exponential back-off therefore
   results in values that are much longer than the initial value.

Would you suggest text?

>  - "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).

Oops. Will check.

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

We could do that. At this point, I'm in favor of doing whatever get this off my plate faster :-)

Lars

---

From: "Gorry (erg)" <[email-masked]>
Date: Fri, 17 Jun 2016 17:05:35 +0100

> On 17 Jun 2016, at 14:45, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 
>   doubles the measured RTT value
/measured rtt/timeout period/ was what I suggested.

> after each timeout (e.g., [RFC3261]).
 Basically there is not in general a concept of RTO in UDP protocols, although reliable protocols could follow TCP. 

> We could do that. At this point, I'm in favor of doing whatever get this off my plate faster :-)

The publication status and scope of Marks draft currently in TCPM still needs discussion... Including how and whether it will mention UDP...  Let's hope that is clear soon. This ref to that draft was intended to help progress both. I fear Removing the mention of retransmission from the guidelines to only an external reference stalls both drafts to a discussion in Berlin... 

> Lars

I think suggested text would be helpful.

Gorry

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 17 Jun 2016 09:15:00 -0700

On Fri, Jun 17, 2016 at 9:05 AM, Gorry (erg) <[email-masked]> wrote:

> > because it's a reasonable example for which we have a spec. I'm happy to
> recommend something else that is reasonable.
> >
>  Basically there is not in general a concept of RTO in UDP protocols,
> although reliable protocols could follow TCP.

While that's true, there can be an expectation of something like an RTO. We
did this for LEDBAT, and we called it a Congestion Timeout (CTO). From RFC
6817:

update_CTO()
    # implements an RTT estimation mechanism using data
    # transmission times and ACK reception times,
    # which is used to implement a congestion timeout (CTO).
    # If implementing LEDBAT in TCP, sender SHOULD use
    # mechanisms described in RFC 6298
<https://tools.ietf.org/html/rfc6298> [RFC6298
<https://tools.ietf.org/html/rfc6298>],
    # and the CTO would be the same as the retransmission timeout (RTO).

and this is used as follows:

   if no ACKs are received within a CTO:
       # extreme congestion, or significant RTT change.
       # set cwnd to 1MSS and backoff the congestion timer.
       cwnd = 1 * MSS
       CTO = 2 * CTO

The UDP guidelines draft can a reflect similar concept and language.

> The publication status and scope of Marks draft currently in TCPM still
> needs discussion... Including how and whether it will mention UDP...  Let's
> hope that is clear soon. This ref to that draft was intended to help
> progress both. I fear Removing the mention of retransmission from the
> guidelines to only an external reference stalls both drafts to a discussion
> in Berlin...
>

+1 to using rto-consider as the reference if at all possible.

- jana