Subject: [tsvwg] Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 16 Jun 2014 08:50:05 +0000

Hi,

Gorry and me have started to put together an update to RFC5405 in light of the recent discussions. Comments welcome.

Lars

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt
> Date: June 14, 2014 at 12:14:42 GMT+2
> To: Lars Eggert <[email-masked]>, Godred Fairhurst <[email-masked]>, Gorry Fairhurst <[email-masked]>, Lars Eggert <[email-masked]>
> 
> 
> A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt
> has been successfully submitted by Lars Eggert and posted to the
> IETF repository.
> 
> Name:		draft-eggert-tsvwg-rfc5405bis
> Revision:	00
> Title:		UDP Usage Guidelines
> Document date:	2014-06-14
> Group:		Individual Submission
> Pages:		36
> URL:            http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
> Htmlized:       http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00
> 
> 
> Abstract:
>   The User Datagram Protocol (UDP) provides a minimal message-passing
>   transport that has no inherent congestion control mechanisms.
>   Because congestion control is critical to the stable operation of the
>   Internet, applications and other protocols that choose to use UDP as
>   an Internet transport must employ mechanisms to prevent congestion
>   collapse and to establish some degree of fairness with concurrent
>   traffic.  They may also need to implement additional mechanisms,
>   depending on how they use UDP.
> 
>   This document provides guidelines on the use of UDP for the designers
>   of applications, tunnels and other protocols that use UDP.
>   Congestion control guidelines are a primary focus, but the document
>   also provides guidance on other topics, including message sizes,
>   reliability, checksums, and middlebox traversal.
> 
>   If published as an RFC, this document will obsolete RFC5405.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: [email-masked]
Date: Mon, 16 Jun 2014 20:35:41 +0100

> See-in-line
>> On Mon, Jun 16, 2014 at 11:33 AM, <[email-masked]> wrote:
>>
>>> I'll respond on the RTT query - since I wrote that section.
>>>
>>> I'm, not sure what you are saying, are you saying there are methods
>>> that
>>> determine how to respond to congestion that take less than one RTT, or
>>> simply the group RTT isn't an issue - maybe I'd see better with an
>>> example?
>>
>>
>> Right, the whole concept of RTT is irrelevant here since there is no
>> message round trip from receiver to source and back. The CC
>> determination
>> (channel selection/combination) is determined by the application without
>> upstream signaling at all. That was the point of the last sentence in
>> the
>> previous paragraph which came from section 2.1 of my
>> draft draft-shepherd-multicast-udp-guidelines-01.txt
>>
> I had some doubt about that part: Let me see if I can explain what I am
> thinking:
>
> - For example, using ALC, I'd have expected loss due to congestion at a
> bottleneck to result in  each receiver downstream of the bottleneck in
> reducing the group membership for the higher-rate streams, but the
> required rate reduction takes a little while to propagate up the (PIM)
> multicast distribution tree, and the source only ceases when there are no
> further subscriptions (or timeout).
>
> Whatever, ALC would take at least a RTT to the furthest receiver (with
> loss) that has subscribed to the group, before the source has a chance to
> reduce the load on the bottleneck.
>
> I know you could also immediately react to loss (aka NORM), but then that
> would prevent heterogenous operation where one part of the group can
> receive faster than others. This reaction is more conservative from a CC
> viewpoint
>
> Gorry
>
>> Greg
>>
>>
>>
>>>
>>> Gorry
>>>
>>>
>>> > Thanks Lars. Much of this text is taken directly from my previous
>>> > draft, draft-shepherd-multicast-udp. Can you please add me to the
>>> authors
>>> > list of this draft?
>>> >
>>> > Content notes:
>>> >
>>> > Section 4.1:
>>> >
>>> > Congestion control mechanisms for multicast may operate on longer
>>> >    timescales than for unicast (e.g., due to the higher group RTT of
>>> a
>>> >    heterogeneous group); appropriate methods are particularly for any
>>> >    multicast session were all or part of the multicast distribution
>>> tree
>>> >    spans an access network (e.g., a home gateway).
>>> >
>>> >
>>> > The above isn't relevant for application based CC mechanism. In fact,
>>> an
>>> > application-based mechanism may often operate faster than any RTT
>>> > dependent
>>> > mechanism. I think we should either remove this paragraph entirely or
>>> > restructure it to make the point that application based CC operates
>>> > without
>>> > dependency on RTT.
>>> >
>>> > Greg
>>> >
>>> >
>>> > On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars <[email-masked]>
>>> wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> Gorry and me have started to put together an update to RFC5405 in
>>> light
>>> >> of
>>> >> the recent discussions. Comments welcome.
>>> >>
>>> >> Lars
>>> >>
>>> >>
>>> >> Begin forwarded message:
>>> >>
>>> >> > To: Lars Eggert <[email-masked]>, Godred Fairhurst <
>>> >> [email-masked]>, Gorry Fairhurst <[email-masked]>, Lars
>>> >> Eggert <[email-masked]>
>>> >> >
>>> >> >
>>> >> > URL:
>>> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt
>>> >> > Status:
>>> >> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
>>> >> > Htmlized:
>>> >> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00
>>> >> >
>>> >> >
>>> >> > Abstract:
>>> >> >   Because congestion control is critical to the stable operation
>>> of
>>> >> the
>>> >> >   Internet, applications and other protocols that choose to use
>>> UDP
>>> as

---

From: [email-masked]
Date: Mon, 16 Jun 2014 21:12:54 +0100

In-line

> Inline:
>
> On Mon, Jun 16, 2014 at 12:34 PM, <[email-masked]> wrote:
>
>> See-in-line
> We're already gone off track here; RTT is just a measure of time. It
> doesn't itself directly refer to any form of CC. Join latency is not RTT.
> WEBRC coined the term MRTT in an attempt to tie join-latency to the
> concept
> of RTT as it applies to CC.
>
I don't agree - even though there may be no "RTT timer", the largest round
trip time of any receiver in the ALC group is still the parameter that
controls the responsiveness of the CC mechanism.

> I don't believe ALC sources change rates at all. There is a rate/group
> profile which the receiver application side selects.
>
I should have been clearer, the rate at which the source injects traffic
into the congested bottleneck queue. The rate at which the ALC source
feeds this queue varies as the subscription to higher-rate groups subside.

> ..which goes into the description of various CC mechanisms and departs
> from
> any applicability of RTT.
>
> Greg
>

Gorry
>> >> >    timescales than for unicast (e.g., due to the higher group RTT
>> of a
>> >> >> > Please note that it may take a couple of minutes from the time
>> of
>> >> >> submission

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 16 Jun 2014 13:19:08 -0700

> controls the responsiveness of the CC mechanism.

Almost right.. It's not any round trip time. It's join/leave latency. I'm
not arguing the mechanism, I'm arguing the term. We need to be clear -
there is not control RTT like TCP here.

> feeds this queue varies as the subscription to higher-rate groups subside.

Sure, but this is a topology dependency and no application will be able to
respond to where congestion occurs, only if/when they see congestion
directly. Just like TCP - it has no clue where congestion occurs. It just
reacts to local detection.

Greg

---

From: [email-masked]
Date: Mon, 16 Jun 2014 21:31:07 +0100

So, basically,  ALC doesn't mention RTT, but NORM does. Both of these
react on larger time scales than TCP would have reacted to the same
congestion event. So if we remove RTT is this OK:

Section 4.1:
Congestion control mechanisms for multicast may operate on longer
timescales than for unicast (especially where group members have
widely different path delays). Appropriate methods are particularly
important for any multicast session were all or part of the multicast
distribution tree spans an access network (e.g., a home gateway).

Gorry

>> >> >> determine how to respond to congestion that take less than one
>> RTT,
>> >> or
>> >> multicast distribution tree, and the source only ceases when there
>> are
>> >> no
>> >> loss) that has subscribed to the group, before the source has a
>> chance
>> >> to
>> >> >> >    heterogeneous group); appropriate methods are particularly
>> for
>> >> any
>> >> >> > mechanism. I think we should either remove this paragraph
>> entirely
>> >> or

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 16 Jun 2014 13:45:44 -0700

> distribution tree spans an access network (e.g., a home gateway).

Again, this is topology dependent. It may also operate on much shorter
timescales.

Greg

---

From: [email-masked]
Date: Tue, 17 Jun 2014 07:46:29 +0100

> Again, this is topology dependent. It may also operate on much shorter
Maybe layered congestion control is a good example, where congestion at
the edge of the tree results in a response as soon as multicast router
before the congestion bottleneck prunes the traffic - but I'm not sure
this implies the router immediately stops forwarding?

Maybe we can agree on:

Section 4.1:
Congestion control mechanisms for multicast may operate on different
timescales than for unicast depending on the topology, CC method and point of
congestion.  Appropriate methods are particularly important for any
multicast session were all or part of the multicast distribution tree
spans an access network (e.g., a home gateway).

Gorry

>> >> >> > Right, the whole concept of RTT is irrelevant here since there
>> is
>> >> no
>> >> >> > upstream signaling at all. That was the point of the last
>> sentence
>> >> in
>> >> >> the
>> >> >> I had some doubt about that part: Let me see if I can explain what
>> I
>> >> am
>> >> >> thinking:
>> >> >>
>> >> >> - For example, using ALC, I'd have expected loss due to congestion
>> at
>> >> a
>> >> >> bottleneck to result in  each receiver downstream of the
>> bottleneck
>> >> in
>> >> > doesn't itself directly refer to any form of CC. Join latency is
>> not
>> >> RTT.
>> > Sure, but this is a topology dependency and no application will be
>> able
>> to
>> >> >> I know you could also immediately react to loss (aka NORM), but
>> then
>> >> >> that
>> >> >> receive faster than others. This reaction is more conservative
>> from a
>> >> CC
>> >> >> viewpoint
>> >> >
>> >> >
>> >> >> >> > The above isn't relevant for application based CC mechanism.
>> In
>> >> >> fact,
>> >> >> >> an
>> >> >> >> >> Gorry and me have started to put together an update to
>> RFC5405
>> >> in
>> >> >> >> light
>> >> >> >> >> of
>> >> >> >> >> [email-masked]>, Gorry Fairhurst
>> <[email-masked]>,
>> >> >> Lars
>> >> >> >> >> Eggert <[email-masked]>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > has been successfully submitted by Lars Eggert and posted
>> to
>> >> the
>> >> >> >> >> > IETF repository.
>> >> >> >> >> >
>> >> >> >> >> >   Internet, applications and other protocols that choose
>> to
>> >> use
>> >> >> UDP
>> >> >> >> as
>> >> >> >> >> >   This document provides guidelines on the use of UDP for
>> the
>> >> >> >> >> designers
>> >> >> >> >> >   Congestion control guidelines are a primary focus, but
>> the
>> >> >> >> document
>> >> >> >> >> >   also provides guidance on other topics, including
>> message
>> >> >> sizes,

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 17 Jun 2014 07:54:28 -0700

> this implies the router immediately stops forwarding?

If there is only one receiver on that branch, the router should stop
forwarding packets on that branch immediately upon receiving a IGMP leave
message. If not, your router is broken. The time between the sending of the
leave message and the pruning of the branch is the leave latency.

> spans an access network (e.g., a home gateway).

Looks good, thanks!

Greg