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

[[e-mail]]

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