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