Subject: Re: [Tsvwg] A few comments to draft-ietf-tsvwg-udp-guidelines-06

From: Lars Eggert <[email-masked]>
Date: Tue, 13 May 2008 10:36:28 +0300

Hi,

On 2008-4-25, at 9:59, ext Jukka MJ Manner wrote:
> - Related to Rob's comments, the document could be extended to cover  
> also
>  protocols that run directly over IP. The introduction could highlight
>  this, but then say that what the document says about UDP applies also
>  to other like protocols. So, no need to write long additional text,
>  just note that there are, and will be, also protocols that do are not
>  run over UDP.

please see my response to Rob's email from yesterday.

> - The introduction talks about multicast, but then leaves the topic  
> quite
>  open. At least one subsection could be usefull to discuss the topic a
>  bit furhter.

The only way in which the document talks about multicast is to note  
that:

"This document provides guidelines to designers of applications that  
use UDP for unicast transmission. A special class of applications uses  
UDP for IP multicast transmissions. Congestion control, flow control  
or reliability for multicast transmissions is more difficult to  
establish than for unicast transmissions, because a single sender may  
transmit to multiple receivers across potentially very heterogeneous  
paths at the same time. Designing multicast applications requires  
expertise that goes beyond the simple guidelines given in this  
document. The IETF has defined a reliable multicast framework <xref  
target="RFC3048"/> and several building blocks to aid the designers of  
multicast applications, such as <xref target="RFC3738"/> or <xref  
target="RFC4654"/>."

I've added: "The guidelines in this document do not intend to apply to  
multicast-using UDP applications."

So, should the document say something more about multicast? I'm  
unsure. To me, it seems that the difference between what applications  
that use UDP unicast and applications that uses UDP multicast are  
recommended to do is vastly different, probably different enough to  
warrant a separate document. (And I don't have the expertise to write  
that second document.)

If people think that this document should say something more about UDP  
multicast and that they could come up with a section for this document  
on this, send me text :-) The author count is below the bar at which  
the RFC Editor starts yelling at us.

> - p.7, 1st line: s/"chose not to"/"may choose not to"/
> - p.9, 2nd bullet, 2nd para, 1st line "This can be [the] case,"

Both fixed.

> - I was going to throw the same comment than Pasi already did  
> regarding
>  the NAT/FW keep-alive and mobile, battery-operated devices.

See my reply to him.

> - Should POSIX really be a Normative ref? Probably informative is  
> enough.

Point taken, change made.

Lars

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 13 May 2008 10:48:31 +0300 (EEST)

Hi Lars,

See below, I pretty much agree on your points made.

Jukka

On Tue, 13 May 2008, Lars Eggert wrote:

> >- Related to Rob's comments, the document could be extended to cover also

Yes, I read it, and think that a statement about the "spirit" would be 
good to have.

> >- The introduction talks about multicast, but then leaves the topic quite
> The only way in which the document talks about multicast is to note that:
> 
> "This document provides guidelines to designers of applications that use UDP
> for unicast transmission. A special class of applications uses UDP for IP
> multicast transmissions. Congestion control, flow control or reliability for
> multicast transmissions is more difficult to establish than for unicast
> transmissions, because a single sender may transmit to multiple receivers
> across potentially very heterogeneous paths at the same time. Designing
> multicast applications requires expertise that goes beyond the simple
> guidelines given in this document. The IETF has defined a reliable multicast
> framework <xref target="RFC3048"/> and several building blocks to aid the
> designers of multicast applications, such as <xref target="RFC3738"/> or <xref
> target="RFC4654"/>."
> 
> So, should the document say something more about multicast? I'm unsure. To me,
> it seems that the difference between what applications that use UDP unicast
> and applications that uses UDP multicast are recommended to do is vastly
> different, probably different enough to warrant a separate document. (And I
> don't have the expertise to write that second document.)
> 
> multicast and that they could come up with a section for this document on
> this, send me text :-) The author count is below the bar at which the RFC
> Editor starts yelling at us.

I could come up with some text on the general considerations of using 
multicast communication, if more people think that this should be 
mentioned. But I'm not going to put a fight about it. ;) Just saying that 
multicast is out of scope is a fine option, too.

> >- I was going to throw the same comment than Pasi already did regarding

I believe at least mentioning the problem would be important. I would be 
happy to work on separate draft, too, that would discuss in more depth the 
challenge of choosing the "right" transport for an application.

> 
> >- Should POSIX really be a Normative ref? Probably informative is enough.
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 May 2008 11:50:46 +0300

Hi,

> Yes, I read it, and think that a statement about the "spirit" would be

I've added this to the introduction:

"Finally, it is worth noting that although this document is specific  
to applications that use UDP, the spirit of some of its guidelines -  
specifically, on congestion control, message sizes and reliability -  
also applies to other message-passing applications and protocols.  
Examples include signaling or control applications that choose to run  
directly over IP by registering their own IP protocol number with  
IANA. This document may provide useful background reading to the  
designers of such applications and protocols."

> multicast is out of scope is a fine option, too.

Thanks for the offer - let's see what the WG thinks.

> I believe at least mentioning the problem would be important.

Want to suggest a sentence or two to stick into that section?

Lars

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 13 May 2008 13:52:08 +0300 (EEST)

Sounds good. About the extra sentences, in the spirit of giving the credit 
to the original author, you could use the text from Pasi's email. I think 
it captures the point nicely, in a few lines, just enough to point out 
there is a problem that may be worth thinking about when using UDP - 
nothing more.

Jukka

On Tue, 13 May 2008, Lars Eggert wrote:

> "Finally, it is worth noting that although this document is specific to
> applications that use UDP, the spirit of some of its guidelines -
> specifically, on congestion control, message sizes and reliability - also
> applies to other message-passing applications and protocols. Examples include
> signaling or control applications that choose to run directly over IP by
> registering their own IP protocol number with IANA. This document may provide
> useful background reading to the designers of such applications and
> protocols."
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 May 2008 14:18:54 +0300

> there is a problem that may be worth thinking about when using UDP -

OK. I've taken Pasi's text as a starting point and came up with this:

"Finally, it is important to again stress that keep-alive messages are  
NOT RECOMMENDED for general use. They are unnecessary for many  
applications and can consume significant amounts of system and network  
resources. For example, on battery-powered devices, if an application  
needs to maintain connectivity for long periods with little traffic,  
the frequency at which keep-alives are sent becomes the determining  
factor that governs power consumption. Because many middleboxes are  
designed to require keep-alives for TCP connections at a frequency  
that is much less than that needed for UDP, this difference alone can  
often be sufficient to prefer TCP over UDP for these deployments. On  
the other hand, there is anecdotal evidence that suggests that direct  
communication through middleboxes, e.g., by using ICE, does succeed  
less often with TCP than with UDP. The tradeoffs between different  
transport protocols - especially when it comes to middlebox traversal  
- deserve carful analysis."

Lars

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 13 May 2008 15:24:43 +0300 (EEST)

Hi, looks very good.

Jukka

On Tue, 13 May 2008, Lars Eggert wrote:

> "Finally, it is important to again stress that keep-alive messages are NOT
> RECOMMENDED for general use. They are unnecessary for many applications and
> can consume significant amounts of system and network resources. For example,
> on battery-powered devices, if an application needs to maintain connectivity
> for long periods with little traffic, the frequency at which keep-alives are
> sent becomes the determining factor that governs power consumption. Because
> many middleboxes are designed to require keep-alives for TCP connections at a
> frequency that is much less than that needed for UDP, this difference alone
> can often be sufficient to prefer TCP over UDP for these deployments. On the
> other hand, there is anecdotal evidence that suggests that direct
> communication through middleboxes, e.g., by using ICE, does succeed less often
> with TCP than with UDP. The tradeoffs between different transport protocols -
> especially when it comes to middlebox traversal - deserve carful analysis."
> 
> Lars
>

---

From: <[email-masked]>
Date: Wed, 14 May 2008 11:22:17 +0300

Lars Eggert wrote:

> "Finally, it is important to again stress that keep-alive messages
> are NOT RECOMMENDED for general use. They are unnecessary for many
> applications and can consume significant amounts of system and
> network resources. For example, on battery-powered devices, if an
> application needs to maintain connectivity for long periods with
> little traffic, the frequency at which keep-alives are sent becomes
> the determining factor that governs power consumption. Because many
> middleboxes are designed to require keep-alives for TCP connections
> at a frequency that is much less than that needed for UDP, this
> difference alone can often be sufficient to prefer TCP over UDP for
> these deployments. On the other hand, there is anecdotal evidence
> that suggests that direct communication through middleboxes, e.g.,
> by using ICE, does succeed less often with TCP than with UDP. The
> tradeoffs between different transport protocols - especially when it
> comes to middlebox traversal - deserve carful analysis."

Looks good! However, the part "becomes the determining factor that
governs power consumption" probably should be slightly hedged
(e.g., "can become. .. depending on the network technology .."), 
since in this regard, different link-layer behave really differently.

Best regards,
Pasi

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 May 2008 11:34:15 +0300

Change made - thanks!

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 May 2008 06:39:59 -0700

> On 2008-5-13, at 10:48, ext Jukka MJ Manner wrote:
...
> Thanks for the offer - let's see what the WG thinks.

I would expect some sort of multicast advice in this doc, e.g., that 
would indicate care needed when multicast is used, referring to docs on 
multicast scoping, etc., and possibly limiting unregulated multicast due 
to the impact on congestion-reactive protocols.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 May 2008 13:47:12 -0700

Gorry Fairhurst wrote:
> Joe Touch wrote:
>> would indicate care needed when multicast is used, referring to docs 
>> on multicast scoping, etc., and possibly limiting unregulated 
>> multicast due to the impact on congestion-reactive protocols.
>>
>> Joe
>>
> 
> 
> If we do add multicast, I think we need to go through the whole 
> document, and check: we need to consider recommendations on timers, ARQ, 
> scoping, API, and PMTUD, etc.
> 
> My first choice would be to declare it out of scope" and tackle in a 
> separate document, but I'd be happy to work with people on text for 
> multicast issues and recommendations.

My concern is saying it's out of scope. It would be more useful to say 
BOTH of the following in that case:

	- this document does not address multicast-specific BCPs
	(i.e., out of scope)

	- this document's BCPs apply only to unicast, and are not
	intended to apply to multicast
	(i.e., don't just blindly apply this stuff to multicast)

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 15 May 2008 20:31:47 +0100

Gorrry

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 May 2008 12:07:41 +0300

Hi,

I'm with Gorry about leaving recommendations on how to use multicast  
out of this document. (Having a similar document would be a good idea  
IMO, but I'm not qualified to write it.)

On 2008-5-15, at 23:47, ext Joe Touch wrote:
> My concern is saying it's out of scope. It would be more useful to  
> say BOTH of the following in that case:
>

Doesn't #1 imply #2? At least to me, it does.

I'd be happy to further clarify this in the document, if you think  
it's needed. Currently, we say:

"This document provides guidelines to designers of applications that  
use UDP for unicast transmission. A special class of applications uses  
UDP for IP multicast transmissions. Congestion control, flow control  
or reliability for multicast transmissions is more difficult to  
establish than for unicast transmissions, because a single sender may  
transmit to multiple receivers across potentially very heterogeneous  
paths at the same time. Designing multicast applications requires  
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]. It is not  
intended that the guidelines in this document apply to multicast  
applications that use UDP."

Do we need to rephrase the first and/or last sentence?

Thanks,
Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 May 2008 07:19:26 -0700

Lars Eggert wrote:
> Hi,
> 
> I'm with Gorry about leaving recommendations on how to use multicast out 
> of this document. (Having a similar document would be a good idea IMO, 
> but I'm not qualified to write it.)
> 

It might to you, but I am concerned it would not to others.

> I'd be happy to further clarify this in the document, if you think it's 
> needed. Currently, we say:
> 
> "This document provides guidelines to designers of applications that use 
> UDP for unicast transmission. A special class of applications uses UDP 
> for IP multicast transmissions. Congestion control, flow control or 
> reliability for multicast transmissions is more difficult to establish 
> than for unicast transmissions, because a single sender may transmit to 
> multiple receivers across potentially very heterogeneous paths at the 
> same time. Designing multicast applications requires expertise that goes 
> beyond the simple guidelines given in this document. The IETF has 

replace "simple" with "simple, unicast-specific"

> defined a reliable multicast framework [RFC3048] and several building 
> blocks to aid the designers of multicast applications, such as [RFC3738] 
> or [RFC4654]. It is not intended that the guidelines in this document 
> apply to multicast applications that use UDP."
> 

See above; it's more like one in the middle. The title, abstract, and 
intro might need to add the word unicast in various places.

Also, there's more than just multicast here; there's anycast and 
broadcast too.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 May 2008 07:25:47 -0700

Hi, all,

Let me be a little more specific:

...
> The title, abstract, and 

1. add to the multicast discussion; make it sound more like "unicast 
specific" than "not multicast", including anycast and broadcast in the 
list of places the recommendations are not intended to apply.

FWIW, I would say even that multicast/anycast/unicast ought to obey at 
LEAST these requirements, but will definitely need more stringent 
controls in addition.

2. update the title, abstract, and intro to say "Unicast UDP" rather 
than just UDP in a few key places.

Joe

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 19 May 2008 19:01:23 +0300 (EEST)

Hi, this sounds like a good proposal to get us forward.

Jukka

On Mon, 19 May 2008, Joe Touch wrote:

> > The title, abstract, and intro might need to add the word unicast in various
> > places.
> > 
> > Also, there's more than just multicast here; there's anycast and broadcast
> > too.
> 
> 1. add to the multicast discussion; make it sound more like "unicast specific"
> than "not multicast", including anycast and broadcast in the list of places
> the recommendations are not intended to apply.
> 
> FWIW, I would say even that multicast/anycast/unicast ought to obey at LEAST
> these requirements, but will definitely need more stringent controls in
> addition.
> 
> 2. update the title, abstract, and intro to say "Unicast UDP" rather than just
> UDP in a few key places.
> 
> Joe
> 
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 May 2008 12:31:06 +0300

On 2008-5-19, at 17:19, ext Joe Touch wrote:
>> very heterogeneous paths at the same time. Designing multicast  
>> applications requires expertise that goes beyond the simple  
>> guidelines given in this document. The IETF has
>

Done.

I've also rephrased the entrire paragraph in response to your comment  
below, i.e., to say something about broadcast and anycast. It now reads:

    This document provides guidelines to designers of applications that
    use UDP for unicast transmission, which is the most common case.
    Specialized classed of applications use UDP for IP multicast
    [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions.
    The design of such specialized applications requires expertise that
    goes beyond the simple, unicast-specific guidelines given in this
    document.  Multicast and broadcast senders may transmit to multiple
    receivers across potentially very heterogeneous paths at the same
    time, which significantly complicates congestion control, flow
    control and reliability mechanisms.  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].
    Anycast senders must be aware that successive messages sent to the
    same anycast address may be delivered to different underlying IP
    addresses, i.e., arrive at different locations in the topology.  It
    is not intended that the guidelines in this document apply to
    multicast, broadcast or anycast applications that use UDP.

>> defined a reliable multicast framework [RFC3048] and several  
>> building blocks to aid the designers of multicast applications,  
>> such as [RFC3738] or [RFC4654]. It is not intended that the  
>> guidelines in this document apply to multicast applications that  
>> use UDP."
> See above; it's more like one in the middle. The title, abstract,  
> and intro might need to add the word unicast in various places.

I'll do that now.

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 May 2008 06:36:15 -0700

The paragraph looks good.

Joe

Lars Eggert wrote:
>>> blocks to aid the designers of multicast applications, such as 
>>> [RFC3738] or [RFC4654]. It is not intended that the guidelines in 
>>> this document apply to multicast applications that use UDP."