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

[Greg Shepherd <[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


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