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

From: Lars Eggert <[email-masked]>
Date: Wed, 7 Mar 2007 14:27:07 +0200

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 12 Mar 2007 21:12:33 +0000

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

>     control of multicast transmissions is more difficult than controlling
>     multiple receivers across potentially very heterogeneous paths at the
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
>>    the client²
OK

>> 3) Section 3.1
>> Says:³If an application or upper-layer protocol chooses not to use a
>>    approaches discussed in this section.²
>> _ I think so too.
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)
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.

> I'm open for text suggestions
... Don't open multiple ports to the same destination process;-)

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

> 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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 Mar 2007 12:03:45 +0200

On 2007-3-12, at 23:12, ext Gorry Fairhurst wrote:
>>     applications that use UDP for unicast transmission.
...
> congestion control (although that is of course important).

I rephrased that paragraph (see attached diff).

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

> utilise larger datagrams, would this be good advice.

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

> ... Don't open multiple ports to the same destination process;-)

Enlighten me - what's the issue here?

>> for UDP - it's an issue independent of what transport is used.

Have an appropriate RFC number handy?

> 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