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

[Lars Eggert <[e-mail]>]

On 2007-3-12, at 23:12, ext Gorry Fairhurst wrote:
> On 7/3/07 12:27, "Lars Eggert" <[e-mail]> wrote:
>> 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.
...
> 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).

I rephrased that paragraph (see attached diff).

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

I'm not sure I understand where you're going with this. Do yo mean  
that when path capacity has been provisioned for a given UDP flow,  
that it MAY ignore the guidelines?

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

Makes sense. I've rephrased that (see attached diff).

>>> 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;-)

Enlighten me - what's the issue here?

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

Have an appropriate RFC number handy?

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

I've tried to tweak the abstract accordingly.

Diff between -00 and my current working version attached FYI.

Lars