[R-C] BoF approved
Michael Welzl
michawe at ifi.uio.no
Sun Jul 8 17:32:36 CEST 2012
- I agree with everything that's been said here and I'm delighted to
see a significant amount of consensus.
Cheers,
Michael
On Jul 7, 2012, at 10:59 PM, Matt Mathis wrote:
> I would like to point out that nobody has actually disagreed: If
> "fixing the network" means something like "deploy QoS" then yes it
> is absolutely out of scope. However "diagnosing (the lack of) QoS"
> is absolutely in scope. It should have the indirect effect of
> causing the former, irregardless of scope or who owns the problem.
>
> Note that the Internet will almost certainly be better served by QoS
> metrics that are built into all applications and determined by their
> needs, rather than the intent of the QoS implementers.
>
> And (I hope) we all agree that rtcweb can not directly fix network
> problems, no matter how well it performs.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it. - Alan Kay
>
>
>
> On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys <jg at freedesktop.org>
> wrote:
> On 07/07/2012 01:35 PM, Bob Briscoe wrote:
> > Michael, Bill,
> >
> > The proposed logic for focusing on the R-T transport is that network
> > fixes will only be deployed piecemeal, so some parts of the Internet
> > won't have the new functions in them, therefore any fix has to be
> done
> > in the e2e transport. This sounds logical if you don't think too
> hard
> > about it, but...
> >
> > 1/ If the chosen problem to address is that TCP flow(s) are
> running up
> > to the tail of a slow buffer and causing delays and losses that make
> > simultaneous r-t delivery quality poor, then no amount of
> improvement
> > to RTP alone will fix this. The impairment would be caused by the
> TCP
> > traffic even if the RTP flow(s) weren't there, so adding an RTP flow
> > cannot /reduce/ impairments caused by other transports (unless it
> > includes a magic anti-delay-sucking nano-worm).
>
> Bob is exactly correct: no programming around bufferbloat will work
> for
> real time, no protocols magic will work that I can see.
>
> Ledbat only works because you are trying to do the opposite: keep it
> from interfering with TCP. And even there, Ledbat stops working once
> AQM (e.g. CoDel) keeps the delays low. The inverse just won't work.
>
> c.f. http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/
>
> And even a single TCP connection will do you in today.
>
> >
> > For instance, if we added delay sensing to the R-T transport, it
> will
> > sense delay, back-off and TCP will just continue, while the RTP
> > starves itself (cf Vegas).
> >
> > If TCP-induced impairment is indeed the chosen problem, then
> limiting
> > the scope to R-T transport only will therefore achieve precisely
> nothing.
> >
> > 2/ If the chosen problem is to prevent an R-T transport doing harm
> to
> > other elastic (TCP) traffic (or other R-T traffic for that matter),
> > then focusing on RTP makes perfect sense.
> >
> > 3/ If problem #1 (preventing TCP harming RT) is in scope, then
> network
> > changes are the *only* way to solve this aspect. They won't solve it
> > anywhere but where they are deployed, but this is better than
> solution
> > #1 (focus on R-T transport alone), which solves it precisely
> nowhere.
>
> I think we must presume the network gets fixed. Broadband (and WiFi)
> are
> both broken well beyond real time standards required for good audio to
> be reliable.
>
> The biggest parts of the bufferbloat problem (at least that we know
> today; we may be looking for keys under the lamppost) are the two
> common
> bottlenecks at the edge of the network. In your house, those are your
> broadband connection, and your WiFi hop (both sides of the WiFi hop;
> your operating system needs to be fixed too). Cellular wireless is
> somewhat similar, but also somewhat different.
>
> I think the right strategy for rtcweb are two fold:
> a) making sure that everything works well for real time when the
> network has been fixed.
> cf.
> http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-to-fix-it/
> b) detecting the problem, so that people know to go get it fixed,
> and which hops are broken. Preferably by pointing the finger to the
> offending component, so that it gets fixed, whether your operating
> system, your home router, your broadband cpe, your broadband head end.
>
> So Bob is exactly correct on this; you can't engineer real time
> traffic
> around bufferbloat in today's broken internet by protocol magic. You
> can, however fix the broken components (and in your home, with care,
> do
> pretty well even today if you are clever). cf.
> http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbloat-in-home-routers-and-operating-systems/
> And you can come help fix the problem for real, in home routers, and
> elsewhere in the network.
> - Jim
>
>
> >
> >
> >
> > Bob
> >
> >
> >
> > At 16:03 07/07/2012, Michael Welzl wrote:
> >> I agree.
> >>
> >> It seems clear to me that the ability to work everywhere is the top
> >> goal of rtcweb; interactions with the network have to be
> considered,
> >> of course (any congestion control algorithm will have to consider
> >> queue behavior).
> >>
> >> More below, in line:
> >>
> >>
> >> On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:
> >>
> >>> I agree that this is not the right forum for discussing middlebox
> >>> buffer management algorithms. I would add that even if the network
> >>> elements do creep into scope, the host-based congestion control
> >>> algorithms still have to work with the existing systems found in
> the
> >>> wild. In other words, we could suggest that the middleboxes
> >>> implement [insert your favorite AQM algorithm here]and [insert
> your
> >>> pick of ECN, PCN, or maybe even Conex, etc] but the hosts still
> need
> >>> to deal with [tail drop, RED, WRED, etc].
> >>>
> >>> Stated another way, the algorithm is going to get a variety of
> >>> congestion signals. When running on networks with primitive buffer
> >>> management algorithms, one of those signals is going to be
> delay. On
> >>> more modern systems, we can hope that the middleboxes' buffer
> >>> management algorithms do not introduce persistent delay.
> >>>
> >>> So, the RMCAT work will have to consider delay, packet loss and
> >>> explicit packet markings. In a perfect world, the network will
> never
> >>> give us persistent delay - but the world is rarely perfect.
> >>>
> >>> Bill VerSteeg
> >>>
> >>> -----Original Message-----
> >>> From: rtp-congestion-bounces at alvestrand.no
> >>> [mailto:rtp-congestion-bounces at alvestrand.no ] On Behalf Of John
> Leslie
> >>> Sent: Friday, July 06, 2012 11:38 AM
> >>> To: Bob Briscoe
> >>> Cc: rtp-congestion at alvestrand.no; Michael Welzl
> >>> Subject: Re: [R-C] BoF approved
> >>>
> >>> Bob Briscoe <bob.briscoe at bt.com> wrote:
> >>>> At 11:41 06/07/2012, Michael Welzl wrote:
> >>>>> On 6/26/12 4:05 PM, Wesley Eddy wrote:
> >>>>>> The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
> >>>
> >>> From http://trac.tools.ietf.org/bof/trac/ :
> >>> ]
> >>> ] Transport
> >>> ]
> >>> ] RTP Media Congestion Avoidance Techniques (RMCAT)
> >>> ]
> >>> ] Description: WG-forming BoF on RTP congestion control
> >>> ] Responsible AD: Wesley Eddy
> >>> ] BoF Chairs: Michael Welzl and Colin Perkins
> >>> ] Number of people expected to attend: 100
> >>> ] Length of session: 2 hours
> >>> ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC,
> TSVWG,
> >>> TCPM,
> >>> ] CONEX, PCN, MPTCP, IPPM, CORE
> >>> ] Webex: not sure
> >>> ] Meetecho: not sure
> >>> ] Mailing list: rtp-congestion at alvestrand.no
> >>> ] I-Ds:
> >>> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-
> congestion/
> >>> ]
> >>> http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/
> >>> ] Draft charter:
> >>> ]
> >>> http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html
> >>> ] Status: APPROVED
> >>>
> >>>>>> When it was discussed by the IESG and IAB, one topic that
> really
> >>>>>> needs to be clarified by/within the group is the scope of the
> >>>>>> mechanisms being developed. For instance, it needs to be more
> >>>>>> clear what stack the group wants to be chartered to operate on.
> >>>>>> Whether the group would be doing a mechanism that works for RTP
> >>>>>> itself, or a new SCTP mechanism will need to be very clear.
> >>>>>
> >>>>> I would like to get a grip on exactly *what* really *is* decided
> >>>>> regarding the way the stack looks. Which protocol over which
> >>>>> protocol(s) for which type of data.
> >>>>> ...
> >>>>
> >>>> Michael,
> >>>>
> >>>> Recall at the Paris ICCRG I asked the wider question of whether
> >>>> changes to the network are in scope.
> >>
> >> Personally, for the sake of keeping focus, I would say it's out of
> >> scope.
> >>
> >>
> >>> This is Transport area, with Wes the expected Responsible AD.
> >>>
> >>> That means Network-Layer isn't expected to be in-scope for the
> WG.
> >>>
> >>> I would hope, however, that discussion of potential Network-
> Layer
> >>> work which would be helpful would be in-scope for the BoF.
> >>>
> >>>> I know those proposing this believe the scope is v definitely e2e
> >>>> protocols only (at least, if not specified down to a specific e2e
> >>>> protocol), but the scope determines very greatly how much of the
> >>>> problem we're going to solve:
> >>>>
> >>>> * If RTP-only, we don't solve TCP harming RTP, only the other way
> >>>> round (which is fine if that's the scope we want)
> >>
> >> I don't understand that.
> >>
> >>
> >>>> * If SCTP-only, I'm not sure what we solve?
> >>
> >> I get the impression that SCTP-only is not an option.
> >>
> >>
> >>>> * If we allow network to be in scope, we might be able to address
> >>>> bufferbloat-style issues, or perhaps good policer designs to
> protect
> >>>> apps from each other.
> >>
> >> Good policer designs that work well with rtcweb would be cool to
> have,
> >> but why can't that be done e.g. in ICCRG?
> >>
> >>
> >>> I expect to do a rant at the Workshop on Congestion Control for
> >>> Interactive Real-Time Communication July 28th, to the effect
> that this
> >>> can't be solved at the Transport Layer only.
> >>>
> >>> It looks as if enough of us will be there to discuss Bob's
> question.
> >>
> >> I agree, but I think we should try to get consensus on some key
> issues
> >> earlier than that.
> >>
> >>
> >>>
> >>>> My personal opinion is that this w-g should be trying to solve
> the
> >>>> problem. And the problem has three halves:
> >>>> * RTP harming elastic
> >>>> * elastic harming RTP
> >>>> * network arbitrating between the two
> >>>
> >>> Clearly the first needs to be in-scope for the WG.
> >>>
> >>> IMHO the other two halves need to be discussed at the BoF.
> >>
> >> If I understood it correctly, Matt Mathis argued that neither the
> >> first nor the second should be in scope. I'd like to hear some more
> >> views on that.
> >>
> >> Having read RFC5434, I think a general goal, and the role of
> Colin and
> >> me, is to try to maximize consensus and minimize the amount of
> >> discussion-at-the-BOF beforehand.
> >> So naturally I disagree, for now, that these things need to be
> >> discussed there. Let's try to agree on as much as possible before
> it.
> >>
> >> Cheers,
> >> Michael
> >
> > ________________________________________________________________
> > Bob Briscoe, BT Innovate & Design
> > _______________________________________________
> > Rtp-congestion mailing list
> > Rtp-congestion at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
More information about the Rtp-congestion
mailing list