Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-udp-guidelines-02.txt

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Sep 2007 15:32:26 +0100

Lars,

On 23 Aug 2007, at 15:31, Lars Eggert wrote:
> On 2007-7-23, at 19:20, ext Colin Perkins wrote:
>> On 9 Jul 2007, at 04:50, [email-masked] wrote:
>>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp- 
>>> guidelines-02.txt
>>
>> Section 3.5 states:
>>
>>    Applications MAY in addition send periodic keep-alive messages to
>>    attempt to refresh middlebox state.  Unfortunately, no common  
>> timeout
>>    has been specified for per-flow UDP state for arbitrary  
>> middleboxes.
>>    For NATs, [RFC4787] requires a state timeout of 2 minutes or  
>> longer,
>>    and it is likely that other types of middleboxes use timeouts of
>>    similar timescales.  Consequently, if applications choose to send
>>    periodic keep-alives, they SHOULD NOT send them more frequently  
>> than
>>    once every two minutes.  (Not that some deployed middleboxes use a
>>    shorter timeout value than 2 minutes, violating [RFC4787].)
>>
>> which is fine, except that draft-ietf-mmusic-ice-17 suggests a 15  
>> second keep alive interval by default. Can we align these?
>
> We discussed this in the hallways in Chicago, and I've become  
> grudgingly convinced that for specialized uses of UDP, where  
> communication disruptions due to disappearing middlebox state are  
> highly problematic (e.g., media transmission), 15-second timeouts  
> are probably needed. But I did want to make it clear that such  
> timeouts - or even the use of keepalives in general - are not  
> recommended for arbitrary UDP applications.
>
> Below is the modified Section 3.5 from my working copy of -03 FYI.  
> Please let me know what you think of the changes.

This looks fine to me - although you may want to give a reference to  
some of the techniques that allow an application to detect and/or  
modify the binding time-out (e.g. the STUN NAT control work, MIDCOM,  
etc.), so it can choose an appropriate keep-alive interval?

-- 
Colin Perkins
http://csperkins.org/

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 4 Sep 2007 11:36:05 -0400

On Mon, Jul 09, 2007 at 05:50:01AM -0400, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group Working Group of the IETF.
> 
> 
>         Title           : UDP Usage Guidelines for Application Designers
>         Author(s)       : L. Eggert, G. Fairhurst
>         Filename        : draft-ietf-tsvwg-udp-guidelines-02.txt
>         Pages           : 15
>         Date            : 2007-07-09
>                                                                                            

Overall, this looks strong and helpful to me.  Here are some more
detailed comments / suggestions, which you're welcome to ignore if you
don't like them:

1) Abstract:

suggest appending:

"Given the frequent scenario of UDP applications working well in a test
environment, but having issues when run in more widespread use over the
Internet, this document should aid application designers in producing more
robust products."

2) Introduction:

After "A second unique charagteristic of UDP is that it provides no inherent
congestion control mechanisms.", I suggest adding this sentence:

"It is often possible to send UDP datagrams out a link interface at line rate,
which may be much greater than the available end-to-end path's capacity."

This helps to further clarify the issue, I think, before jumping into the 2914
guidelines.

3) "frequently requires IP fragmentation" -> "usually requires IP fragmentation"
since this is a near certainty when the Internet is in the path, maybe an even
stronger statement is justified ... "frequently" doesn't quite seem strong
enough to me.

4) Section 3:

[I-D.ietf-tcpm-syn-flood] is now [RFC 4987]

5) After "When the UDP traffic of such applications leaks out on unprovisioned
paths, results are detrimental.", I suggest adding:

"Applications that support an uncontrolled or unadaptive sending behavior
SHOULD force users to explicitly configure this and SHOULD NOT enable this as a
default mode of operation."

6) "Applications that choose not adapt" -> "Applications that choose not to
adapt"

7) Even using the minimum IPvX PMTUs can lead to fragments given tunnelling,
though I'm not sure it's dangerous enough to bother noting here or further
reducing the suggested datagram sizes, so maybe this is a no-op comment.

8) Section 3.3 - is it worth noting here that this was one of the reasons for
using TCP in diameter rather than udp used in radius?  RFC 3588 and 3539 go
into some detail on this

9) This document is sort of like RFC 1122, except at the next layer up;
at least, I think it could be viewed that way.  It might be nice to have
an 1122-style "checklist" or "summary table" (as in section 3.5 of 1122,
and a few other places) with a row for each feature/behavior and "X"s in
columns for "MUST", "MAY", "SHOULD", etc.  as was done in 1122.  This
would condense the draft's message and make crisper the overall set of
items to be considered.  I'd be willing to draw up a prototype of it if
the authors don't want to pour the sweat into it.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Lars Eggert <[email-masked]>
Date: Wed, 5 Sep 2007 15:04:26 +0300

Hi,

> detailed comments / suggestions, which you're welcome to ignore if you

thanks for the feedback! I've rolled some of your suggestions into my  

> using TCP in diameter rather than udp used in radius?  RFC 3588 and  

Can you point me at a section in one of those RFCs that succinctly  
discusses this rationale? A quick read didn't reveal one.

> the authors don't want to pour the sweat into it.

Hm. Maybe I lack imagination, but even after looking at 1122 I can't  
quite picture what this would look like...

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 5 Sep 2007 15:09:15 +0300

On 2007-9-4, at 17:32, ext Colin Perkins wrote:
> This looks fine to me - although you may want to give a reference  
> to some of the techniques that allow an application to detect and/ 
> or modify the binding time-out (e.g. the STUN NAT control work,  
> MIDCOM, etc.), so it can choose an appropriate keep-alive interval?

Good idea; I've added a sentence on this.

Lars

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 5 Sep 2007 09:14:24 -0400

> discusses this rationale? A quick read didn't reveal one.

Radius's design is probably more of a case-study or side-note for the
udp-guidelines document, but here are some possibly interesting bits:

Here's one bit from 3588:

   Reliable transport
      RADIUS runs over UDP, and does not define retransmission behavior;
      as a result, reliability varies between implementations.  As
      described in [ACCMGMT], this is a major issue in accounting, where
      packet loss may translate directly into revenue loss.  In order to
      provide well defined transport behavior, Diameter runs over
      reliable transport mechanisms (TCP, SCTP) as defined in
      [AAATRANS].

In draft-ietf-radext-fixes-06:
   This text has a number of implications.  First, without duplicate
   detection, a RADIUS server may process an authentication request
   twice, leading to an erroneous conclusion that a user has logged in
   twice.  That behavior is undesirable, so duplicate detection is
   desirable.

Decent thread here on MSL and other issues:
http://psg.com/lists/radiusext/2007/msg00448.html

Also, an interesting bit from 3127:

   It was noted
   that AAA was a transaction-oriented application.  Other request-
   response applications, such as DNS, seem to scale welt to Internet-
   scale using simple application-level retries and UDP transport.  TCP
   has problems with head-of-line blocking, especially when multiple
   sessions are using a single TCP connection.  AAA typically will send
   3 or 4 iterations and then indicate a failure to the upper layers.
   It won't continue retransmissions in the face of congestion, like
   TCP.  It was noted that bulk data transfer may not best be
   implemented in the AAA protocol.  Concern was voiced that SCTP is not
   a widely implemented protocol.  AAA will implement congestion control
   by limiting the number of outstanding requests.  Some RADIUS
   implementations send lots of traffic when they encounter
   misconfigured shared secrets, but this is likely caused by a lack of
   proper error recovery.