Subject: [Tsvwg] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP

From: Lars Eggert <[email-masked]>
Date: Mon, 7 Apr 2008 19:00:04 +0300

(Forwarding for Magnus - this should have gone to TSVWG but went to  
TSVAREA.)

Hi,

I would like to inform that currently TSVWG has started the WG last  
call on "UDP Usage Guidelines for Application Designers" (draft-ietf- 
tsvwg-udp-guidelines-06) with the intended status of BCP. It runs  
until the 21st of April. If you like to provide any comments please  
send them to the TSVWG mailing list ([email-masked]).

Abstract:

   The User Datagram Protocol (UDP) provides a minimal, message-passing
   transport that has no inherent congestion control mechanisms.
   Because congestion control is critical to the stable operation of the
   Internet, applications and upper-layer protocols that choose to use
   UDP as an Internet transport must employ mechanisms to prevent
   congestion collapse and establish some degree of fairness with
   concurrent traffic.  This document provides guidelines on the use of
   UDP for the designers of such applications and upper-layer protocols.
   Congestion control guidelines are a primary focus, but the document
   also provides guidance on other topics, including message sizes,
   reliability, checksums and middlebox traversal.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 21 Apr 2008 21:14:05 +0100

Hi all,

Some nearly late last-call comments on the below:

Overall:
- this document restricts its scope to UDP, but is there any reason why the
same content would not apply to 'applications' using any other
non-congestion-controlled protocol? (Is there some reason to restrict to UDP
in particular?)
- is it intended that adherence to these principles will be standard IESG
review criteria (e.g. will this start to get referenced from
http://www.ietf.org/ID-Checklist.html?)

1. Introduction

Para 3: It might be worth adding some text to the effect that congestion
sensitivity is in the interests of the application itself, which otherwise
may not be obvious to some of the intended audience. (At the moment it reads
that congestion avoidance is purely a matter of good citizenship rather than
self interest.)
Final para: does this guidance apply to anycast also?

3. Usage

Para 1: It might be worth noting that, if an application knows its peer is
on the local link (e.g. because of the destination address), then it can
make stronger assumptions about the path, and congestion control and mtu
issues should not have to be handled (at least at the IP layer). 
Para 3 (end): In addition, TCP is probably more efficient at tuning its RTO
and spotting when a retransmission is actually needed than most home-brew
application-layer reliability schemes.

3.1.2 penultimate para "Note that the initial timeout...": I found this
confusing because there is no 'timeout' in such scenarios: what you mean in
general is that there is a natural timescale over which UDP applications
should send a single packet; this is either the RTT (if you can measure that
- not the timeout in this case either), or a fixed number if you cannot.

3.1.3 bullet 2 (this may just be a typo)
s/to be IP-based or is known to be IP-based, but not congestion-controlled/
  to be IP-based, or is known to be IP-based but not congestion-controlled.

3.2 para 3:
I found this very confusing. Surely you are saying that applications SHOULD
adapt their transmit message size; if they "choose not to" they may generate
UDP datagrams with precisely the properties you complain about. I think the
term 'effective PMTU' should be called out more formally (I am fine with the
definition, 576 magic number and all, but would find "... exceed the
effective PMTU, defined as follows:") easier to follow.

Two issues aren't highlighted explicitly in this part of the text:
- applications which do their own fragmentation to achieve reliable delivery
of a large message need to be encouraged to do efficient reassembly (i.e.
the ability to retransmit a single UDP datagram rather than the whole
message); otherwise they are just repeating the inefficiency of the IP layer
but with better middlebox traversal properties.
- applications which generate multiple UDP datagrams for a single
application message need to be encouraged (do they?) to apply congestion
control to the individual UDP datagrams, rather than to the application
layer message. Otherwise they will hit the network with packet bursts.
(It isn't clear how DTLS, which is recommended as a security solution later,
handles these issues for its initial handshake.)

3.5 penultimate para:
- it might be a good idea to recommend some jitter here (for synchronisation
avoidance).

==end

Thanks for writing the document.

robert h.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: 07 April 2008 16:05
> To: TSV Area
> Subject: [tsv-area] TSVWG last call on "UDP Usage Guidelines 
> for Application Designers" to BCP
> 
> 
> Hi,
> 
> I would like to inform that currently TSVWG has started the 
> WG last call 
> on "UDP Usage Guidelines for Application Designers" 
> (draft-ietf-tsvwg-udp-guidelines-06) with the intended status 
> of BCP. It 
> runs until the 21st of April. If you like to provide any 
> comments please 

Best Regards

Magnus Westerlund