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

From: Joe Touch <[email-masked]>
Date: Mon, 22 Oct 2007 16:23:15 -0700

Lars Eggert wrote:
...
> As far as we authors are concerned, this document is complete, i.e.,
> there isn't anything we think is missing. This should be ready for wider
> review.

I agree. It's in reasonable shape.

Some minor suggestions below....

Sec 3.1.
   It is important to stress
   that an application SHOULD perform congestion control over all UDP
   traffic it sends to a destination, independently from how it
   generates this traffic.
to a destination -> between a socket pair
i.e., the current wording implies taht congestion control should be
per-dest, whereas TCP is per socket-pair, and UDP's can be too.

Sec 3.1
   Finally, in the past, the IETF has investigated integrated congestion
   control mechanisms that act on the traffic aggregate between two
   hosts, i.e., across all communication sessions active at a given time
   independent of specific transport protocols, such as the Congestion
   Manager [RFC3124].
and TCP control block sharing [RFC2140] ;-)
   Such mechanisms have failed to see deployment,
   but would otherwise also fulfill the congestion control requirements
   in [RFC2914], because they provide congestion control for UDP
   sessions.
The CM hasn't been deployed, but TCP CB sharing is, and could be
applicable to RTT calculation across UDP exchanges, although it doesn't
provide congestion control without an additional pacing mechanism.
i.e., this could be noted in Sec 3.1.

Sec 3.3
   Applications that require ordered delivery
   SHOULD reestablish message ordering themselves.
SHOULD -> MUST
There's no SHOULD about this - if the apps require ordering, they MUST
do it themselves.

Sec 3.4
   The UDP header includes an optional, 16-bit ones' complement checksum
   that provides an integrity check.
ones' complement -> ones-complement or one's complement as per other RFCs
integrity -> datagram integrity (i.e., it's over the body, IP header,
and UDP header)

Sec 3.4
   The use of the
   UDP checksum is MANDATORY when applications transmit UDP over IPv6
   [RFC2460] and applications consequently MUST NOT disable their use.
This is confusing. If it's already a MUST, you don't really need to say
anything about it. An API that lets you turn it off is noncompliant anyway.

I would not duplicate recommendations on how to use UDP-Lite that
already appear in that RFC (it seems like that's what's happening in
this section, more than in others).

Sec 3.5
I don't understand what "reestablish UDP sessions" means; perhaps you
mean "reestablish application layer sessions and state"?

Table 1:
	SHOULD handle message loss, duplication, reordering
MUST handle message loss, duplication, and reordering if any of these
are required by the application.
(app designers don't need to handle *any* of these if the application
doesn't care)

---