[Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 28 February 2007 15:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQSv-0006bS-UO; Wed, 28 Feb 2007 10:11:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQSu-0006bK-Lh for tsvwg@ietf.org; Wed, 28 Feb 2007 10:11:36 -0500
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQSt-0001Fr-5J for tsvwg@ietf.org; Wed, 28 Feb 2007 10:11:36 -0500
Received: from [10.10.10.2] (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1SFBMws019065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Feb 2007 15:11:23 GMT
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="WINDOWS-1252"; delsp="yes"; format="flowed"
Message-Id: <699816EE-2153-4D51-A7C6-241701198893@erg.abdn.ac.uk>
Content-Transfer-Encoding: quoted-printable
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Wed, 28 Feb 2007 15:11:28 +0000
To: tsvwg@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

 >       Title           : UDP Usage Guidelines for Application  
Designers
 >       Author(s)       : L. Eggert
 >       Filename        : draft-eggert-tsvwg-udp-guidelines-00.txt

Thanks Lars,

This seems like this is heading the correct direction. From a first  
read I have the following observations:

---------
1)
If I understand, that what the ID says applies to unicast use of UDP  
(and UDP-Lite for that matter), but there are also different concerns  
when we use datagram transport fro multicast.
---------

2) Section 3:
Says: “Similarly, well-designed applications can
    shift maintenance of the TIME-WAIT state after a connection ends to
    the client”
- Not clear what this means.
---------

3) Section 3.1
Says:“If an application or upper-layer protocol chooses not to use a
    congestion-controlled transport protocol, it SHOULD control the rate
    at which it sends UDP messages to a destination, using one of the
    approaches discussed in this section.”
_ I think so too.
- It would be nice to note the impact here of path reservations  
(RSVP, INTSERV) et al - what CC do you need to use if you reserv per- 
flow capacity? and how does the app know this really is reserved?
---------

4) Section 3.2
Says: “application SHOULD implement path MTU discovery”
- or should support and use the path MTU information provided by the  
IP network layer, including the use of probing.... but note that  
applications do NOT need to probe above the largest size that they  
intend to use.

The discussion of “natural” packet sizes (as in latest pmtud work) is  
also pertinent here to UDP apps.
---------

5)
I think we need to offer some comment on the old issue of multiple  
UDP ports between the same applications;-)
---------

6) You may wish to point out a note to the dangers in embedding IP  
addresses in UDP payloads, etc --- Guidance already published elsewhere.

---------

7) It could also mention link-local addressing in IPv6. the lalter  
raises some issues, in that you don’t expect there to be any networlk  
routers in a path that is link-local.... Do you need CC here?

One NiT:  I guess “octets” is OK, but I’d have found bytes more obvious.

Best wishes,

Gorry