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

[Gorry Fairhurst <[e-mail]>]

On 7/3/07 12:27, "Lars Eggert" <[e-mail]> wrote:

> 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].
> 
I just meant that when speaking of multicast there was also no one-size-fits
all for security, flow-control, reliability, discovery. It's not just
congestion control (although that is of course important).

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

>> 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
> 
I was thinking that you could say that IntServ can be used to associate a
flow with different (non-default) network characteristics.

>> 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?)
>
Yes that's text I remember.

It seemed a little odd to say: "Consequently, an application SHOULD
implement path MTU discovery to determine the maximum message size for each
destination they communicate with."

If the application can only support a small subset of natural sizes (e.g.
It's a block-based disk server, or a streaming media server) then it doesn't
make sense to probe for larger MTUs... Only if your application is able to
utilise larger datagrams, would this be good advice.

>> 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
>
... Don't open multiple ports to the same destination process;-)

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

>> 7) It could also mention link-local addressing in IPv6. the latter
>> raises some issues, in that you don¹t expect there to be any
>> network 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.
> 
OK.

> Thanks,
> Lars
> 
> 
I think some of these comments are wider in scope than congestion control,
but I was taking the lead from the title, rather than the abstract.

Best wishes,

Gorry