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

[Greg Shepherd <[e-mail]>]

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