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

[[e-mail]]

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.

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

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