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

[[e-mail]]

> On Mon, Jun 16, 2014 at 1:31 PM, <[e-mail]> wrote:
>
>> 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).
>>
>
> Again, this is topology dependent. It may also operate on much shorter
> timescales.
>
> Greg
>
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

>
>> Gorry
>>
>> > On Mon, Jun 16, 2014 at 1:12 PM, <[e-mail]> wrote:
>> >
>> >> In-line
>> >>
>> >> > Inline:
>> >> >
>> >> > On Mon, Jun 16, 2014 at 12:34 PM, <[e-mail]> wrote:
>> >> >
>> >> >> See-in-line
>> >> >> > On Mon, Jun 16, 2014 at 11:33 AM, <[e-mail]> 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).
>> >> >>
>> >> >
>> >> > 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.
>> >
>> >
>> > 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.
>> >
>> >
>> >> >
>> >> >> 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 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.
>> >
>> >
>> > 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
>> >
>> >
>> >> >
>> >> >> 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
>> >> >
>> >> >
>> >> > ..which goes into the description of various CC mechanisms and
>> departs
>> >> > from
>> >> > any applicability of RTT.
>> >> >
>> >> > Greg
>> >> >
>> >>
>> >>
>> >> Gorry
>> >> >
>> >> >>
>> >> >> 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
>> <[e-mail]>
>> >> >> 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:
>> >> >> >> >>
>> >> >> >> >> > From: <[e-mail]>
>> >> >> >> >> > Subject: New Version Notification for
>> >> >> >> >> draft-eggert-tsvwg-rfc5405bis-00.txt
>> >> >> >> >> > Date: June 14, 2014 at 12:14:42 GMT+2
>> >> >> >> >> > To: Lars Eggert <[e-mail]>, Godred Fairhurst <
>> >> >> >> >> [e-mail]>, Gorry Fairhurst
>> <[e-mail]>,
>> >> >> Lars
>> >> >> >> >> Eggert <[e-mail]>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > 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
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>