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

[Greg Shepherd <[e-mail]>]

On Mon, Jun 16, 2014 at 11:46 PM, <[e-mail]> wrote:

> > 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
> >
> Maybe layered congestion control is a good example, where congestion at
> the edge of the tree results in a response as soon as multicast router
> before the congestion bottleneck prunes the traffic - but I'm not sure
> this implies the router immediately stops forwarding?
>

If there is only one receiver on that branch, the router should stop
forwarding packets on that branch immediately upon receiving a IGMP leave
message. If not, your router is broken. The time between the sending of the
leave message and the pruning of the branch is the leave latency.


> Maybe we can agree on:
>
> Section 4.1:
> Congestion control mechanisms for multicast may operate on different
> timescales than for unicast depending on the topology, CC method and point
> of
> congestion.  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).
>

Looks good, thanks!

Greg


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