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

[[e-mail]]

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

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