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

[Lars Eggert <[e-mail]>]

Hi,

thanks for the feedback!

On 2007-2-28, at 17:11, ext Gorry Fairhurst wrote:
> 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.

The last paragraph in Section 1 tries to say something about  
multicast - do you think this needs refinement?

    This document focuses on providing guidelines to designers of
    applications that use UDP for unicast transmission.  A special class
    of applications uses UDP for IP multicast transmissions.  Congestion
    control of multicast transmissions is more difficult than  
controlling
    unicast transmissions, because a single sender may transmit to
    multiple receivers across potentially very heterogeneous paths at  
the
    same time.  Designing multicast applications requires congestion
    control expertise that goes beyond the simple guidelines given in
    this document.  The IETF has defined a reliable multicast framework
    [RFC3048] and several building blocks to aid the designers of
    multicast applications, such as [RFC3738] or [RFC4654].

> 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.

HTTP 1.0 had the server close the connection to indicate that all  
data had been transmitted, which caused an accumulation of TIME-WAIT  
state there. If the protocol logic is reversed, that state can be  
distributed onto the clients. I'll try to explain this a bit better  
in the text.

> 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?

I'm open for text suggestions

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

I think you mean this text in section 7.3 of pmtud-method, but that  
is a pretty fine point to include in this guidelines document, IMO:

    Some protocols may use other mechanisms to choose the probe sizes.
    For example, protocols that have certain natural data block sizes
    might simply assemble messages from a number of blocks until the
    total size is smaller than search_high, and if possible larger than
    search_low.

(If it isn't, can you point me at the section you mean?)

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

I'm open for text suggestions

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

A reference would be sufficient, because that isn't a specific issue  
for UDP - it's an issue independent of what transport is used.

> 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?

I'd rather not include this - this is a specific scenario, and the  
document attempts to talk about what to do in general when using UDP  
on the Internet.

Thanks,
Lars