Subject: [tsvwg] soliciting comments on draft-ietf-tcpm-rto-consider

From: Mark Allman <[email-masked]>
Date: Wed, 01 Jun 2016 09:24:47 -0400

Folks-

A long time ago we started a document in TCPM that sought to
synthesize what we have figured out over the years about the RTO
estimator.  Basically, we have learned that an RTO estimator needs a
few aspects for network safety, but does not need to be nailed down
as concretely as we have done in the past (e.g., in RFC 6298).

As this effort evolved it seems like the high-level principles and
requirements are actually not tied to TCP, but are in fact protocol
agnostic.  E.g., before we have some notion of an RTT across a
specific path, an RTO scheme needs to use some initial length of
time to trigger a retransmit.  This equally applies to TCP, SCTP,
RTP, UDP-based apps, etc.

The draft name includes "ietf-tcpm", but is actually broader.  My
own assessment is that the draft enjoys pretty wide consensus in
TCPM.  But, I am looking for technical comments to ensure that the
document doesn't suffer from TCP blinders as it has evolved.

The draft is:

  https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-03

Happy to hear comments on the list or off the list.

Many thanks!

allman

--
http://www.icir.org/mallman/

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 2 Jun 2016 10:06:25 +0100

Mark,

As I previously said, I think this is a useful document. However,  I do 
think we need to be careful here when we use terms like "retransmission 
timer algorithms" and "RTO". See below.

> Happy to hear comments on the list or off the list.
For TCP/SCTP these terms are fairly well-specified for TCP/SCTP and I 
also agree on what TCP/SCTP should do. The draft uses the term "RTO" 
... As I understand, an RTO expires in TCP  when there is a lack of 
confirmed delivery across a network path. To me, this detects times when 
the sender can no longer be confident that data is being received -- 
i.e., there is risk that congestion has been detected. To be "safe", the 
network needs to reduce the volume of traffic it sends in response to 
detecting this potential congestion. Exponential backoff of the RTO is 
an important part of the TCP response.
However, to make these recommendations applicable to other protocols, I 
think we need to agree about what we mean by timers, retransmission and 
the term "RTO" in the context of all protocols, and make sure the draft 
says what it understands by these terms.

I'll try to explain why I think this is a new problem for UDP - my hope 
is that this will paint a picture against which we can agree some simple 
definitions that apply beyond TCP, it's long and tutorial (and I'm 
typing over breakfast coffee, so maybe has some oversights, but I'm 
hoping the resulting introductory text is concise, once we understand 
each other's starting points).

---

There are very important differences in the way TCP and UDP handle 
retransmission and timers:

* TCP organises data as a reliable byte stream, UDP does not. This means 
that a modern TCP flow typically can (and does) use other methods to 
detect loss and hence retransmit, and the timer-based RTO mechanism is 
not usually the primary retransmission mechanism. Current thinking is 
that this should not be triggered often in normal operation.

* UDP applications can use timers for retransmission: They need to 
respond "similarly" to TCP when they detect loss, in that they must 
reduce their volume of traffic sent in response when they detect 
congestion. They also can use timers for various reasons. Timers can 
also provide retransmission (in UDP, this is not always of the original 
data). Transmission (and retransmission) are often also controlled by 
timers. The term RTO is not used widely in UDP (and note defined in 
DCCP). this sort of retransmission timer expiry is not necessarily 
equivalent to a TCP RTO.

* Applications can attach different priorities to different UDP 
datagrams they send: All data does not need to be equal, some data may 
be considered more important or more time-critical (e.g., think of data 
from a video codec using UDP). It's quite OK for such an application to 
set a short delivery deadline for some data (more responsive), and to 
care much less about loss of other data. If a timer triggers, the app 
can decide which data to retransmit (or send some sort of repair request 
to compensate for the loss), and when to send this. This includes the 
possibility to use timers for critical datagrams, or to use other 
methods. The thing I think that is important is that an app must reduce 
the total volume of data sent went it experiences loss, it is nothing to 
do with whether timers are used. A re-ransmission timeout can be 
different to a TCP RTO.

I disagree for UDP with: (draft-ietf-tcpm-rto-consider-03.txt says: 
"Ideally, if we know a segment will be lost before reaching the 
destination, a second copy of it would be sent immediately after the 
first transmission." The draft says this is a tradeoff, I think this 
becomes one of many design decisions for a partially reliable datagram 
service. The second copy part is purely dependent on the app, etc)

* Frequency of RTT measurement: Many UDP apps do not make per RTT 
measurements of the path. These have some functions that resemble RTO 
expiry in TCP, but they are not the same. They mayuse  less frequent 
feedback messages to confirm the path they use (e.g., RTCP often used 
with reporting intervals greater than 1 RTT). This is usually a 
conscious decision based on application processing or network capacity 
tradeoff. A lack of reception feedback still needs to be regarded as a 
trigger for a congestion response (aka rate reduction or flow 
termination). These methods work on longer timescales than a TCP RTO 
would operate (and often react differently to a TCP CC , e.g., TFRC). 
This use seems to slightly contradict the current draft, (e.g., I doubt 
if there would be RAI consensus that RTP is wrong.)

* Low volume: Some UDP apps do not implement feedback indicating the RTT 
and volume of successful data transmitted across the path needs special 
consideration (RFC5405 talks about this, SIP is an example - this usage 
resembles TCP SYN transmission, and could probably be handled 
similarly). If the app does not know that data is successfully reaching 
the remote endpoint it needs to take other action (such an app can not 
calculate a safe reduction, e.g., halving the rate) - 
exponentially-backed off request messages from a starting value are 
commonly used in this way. This has similarities with the use by TCP of 
the RTO during Open, where a lack of feedback results in a RTO expiry. 
Methods are described in the UDP Guidelines (RFC5405)to cope with 
senders that send very few packets per RTT, or ones do not measure RTT, etc.

* Low volume: Some UDP applications use a keep alive message to confirm 
their path (STUN is an example, there are others). The IETF circuit 
breaker documents also define a set of last-resort methods for detecting 
what i will call persistent congestion for UDP. These methods work on 
longer timescales than a TCP RTO would operate (and react more 
vigourously than CC), but have similaeity in provide a method of last 
resort.  However, I think this use of timers I think does not fall 
within the scope of the document, but the Guidelines need to note these 
timers need to backoff.

* Backoff - and timer retransmission not harmful: UDP needs to avoid 
congestion collapse. For UDP, the best trade-off (whether it is worth 
risking to send a particular retransmission early or not) is best known 
by the application (e.g., for transaction-based apps - DNS?, exponential 
back-off for each failed retransmission would seem appropriate; in 
contrast for multimedia streaming,  fast retransmission of key data is 
often vital, and some unnecessary retransmissions may be desirable - 
even if that then means less lower priority data can be sent; there are 
likely other cases). If an app sends early, then it MUST be considered 
as a segment that is congestion-controlled (i.e., I think equivalent to 
consuming one MSS of cwnd, in TCP language -  the acknowledgment 
ambiguity that would happen in TCP should not occur in a protocol 
designed for this, that's a result of TCP choosing to use culmulative 
ACKs). To me, the first important thing is not whether timers are used 
to trigger retransmissions, but that data transmission avoids congestion 
collapse. The second important thing, is that this use does not confirm 
the path capacity - hence this does not replace the need for  a method 
of detecting congestion in the last resort. This sort of use seems 
outside the scope of your draft.

* efficiency and timers: I agree there can be an efficiency trade-off 
when using timers (noted as you say for TCP - true also of keep-alives, 
etc), if the RTT isn't measured accurately  and then not used correctly 
to calculate a suitable timeout, then early retransmissions will add 
volume to the data sent by an app. That absolutely needs to be taken 
into consideration. If all data were equal, it would be really wise to 
avoid sending data in early retransmissions (e.g., >RTT but <RTO) - 
because it may not be needed, and TCP may not account for such a 
retransmission using cwnd. Setting the RTO timeout then becomes a 
trade-off for TCP. UDP applications that do not have specific needs, 
should by default design ensure they use a SRTT with variance to set the 
limit on expected feedback time. UDP applications that do understand how 
to use timers near the RTT can do so (but then need to do CC as noted 
above).

---

I'm hopefully learning also as we discuss this, and will also try to 
clarify things with my co-editors in the RFC5405.bis document after I 
have worked through this topic a little further.

For the RTO draft, I think it is well worth trying to sort out the the 
scope for the document, and it is really important to define what is 
actually meant by a RTO, especially in the context of a UDP application.

Gorry