My presentation should end: ....<div> suggested to avoid over-think interactions in failure cases, >>and ended with a quote from Andrew McGregor:<< "protecting TCP is unnecessary, it will not return the favour".</div>
<div><br></div><div>Thanks,</div><div>--MM--<br>The best way to predict the future is to create it. - Alan Kay<br><br>
<br><br><div class="gmail_quote">On Thu, Aug 23, 2012 at 7:24 AM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no" target="_blank">michawe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear all,<br>
<br>
Please find below the minutes from the RMCAT BOF, and please let us have any comments / fixes by the end of the week. Thanks!<br>
<br>
Cheers,<br>
Michael<br>
<br>
<br>
<br>
Minutes of the RTP Media Congestion Avoidance Techniques (RMCAT) BoF<br>
<br>
Reported by Colin Perkins<br>
<br>
The RMCAT BoF was held from 13:00-15:00 on 2 August 2012 at the IETF 84<br>
meeting in Vancouver, Canada. The chairs were Michael Welzl (University<br>
of Oslo) and Colin Perkins (University of Glasgow). The BoF grew out of<br>
discussions around the RTCWEB working group, and was coordinated on the<br>
<rtp‐<a href="mailto:congestion@alvestrand.no">congestion@alvestrand.no</a>> mailing list.<br>
<br>
Introduction<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf</a><br>
<br>
The chairs introduced the BoF. The IETF and W3C are currently developing<br>
standards for video conferencing in web browsers, using an RTP-based<br>
media layer. The resulting systems are expected to see wide deployment.<br>
This is potentially problematic, since standards for RTP congestion<br>
control are not well developed. This risks causing congestion collapse in<br>
the Internet in the worst case, and in the short-term may disrupt the<br>
quality of experience due to interactions between flows. The main goal of<br>
this BoF is to understand the problem, and agree on a process for finding<br>
a solution.<br>
<br>
<br>
Problem Statement<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-5.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-5.pdf</a><br>
<br>
Harald Alvestrand gave a more detailed outline of the problem statement.<br>
He noted that the Internet is dominated by TCP traffic, and that real-<br>
time interactive traffic is a niche, comprising mostly low-bandwidth VoIP<br>
and gaming flows, generally running on managed or high capacity networks.<br>
RTCWEB is aiming to change this, deploying interactive and high-bandwidth<br>
video on unmanaged and variable quality networks. Harald re-iterated the<br>
potential for congestion collapse due to these flows, and noted also<br>
that a consequence of the interactive nature of these applications is<br>
that low delay is as important as a sufficient bandwidth allocation. He<br>
also noted that these applications, while being relatively high bandwidth,<br>
have both upper- and lower-bounds on the bandwidth they can consume.<br>
<br>
Several mechanisms exist that might be considered for congestion control<br>
of interactive real-time applications. TCP can be said to deliver obsolete<br>
data reliably, encouraging full queues at bottlenecks, and so cannot meet<br>
the delay bounds. TFRC has smoother behaviour than TCP and is unreliable,<br>
but does not focus on minimizing delay, and has not seen wide deployment<br>
for a range of reasons. There are also proprietary mechanisms, that are<br>
by definition not interoperable. None of these are suitable. What we need<br>
from a future working group is a well-defined problem statement, one (or<br>
more) fully specified mechanisms for solving the congestion problem for<br>
interactive real-time applications, and metrics against which the success<br>
of that mechanism can be evaluated.<br>
<br>
<br>
Context: IAB/IRTF Congestion Control Workshop<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-6.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-6.pdf</a><br>
<br>
Michael Welzl summarised the outcomes of the workshop on congestion<br>
control for interactive real-time applications that was held on 28 July<br>
2012 in Vancouver. The workshop asked 1) if, absent changes to the<br>
network, we can develop a useful congestion control algorithm for<br>
interactive media; 2) if there is work in the area of measurements that<br>
we can use to create incentives to make updates to the network happen;<br>
and 3) if it is useful to develop a congestion control mechanism that<br>
assumes the problem is in the end host only, where there is idle capacity<br>
in the network. The consensus of the workshop participants was to answer<br>
yes to all these questions, but to note a wide range of normal delay<br>
variation in non-congested networks, which will significantly complicate<br>
the problem due to the delay bounds of interactive applications.<br>
<br>
The workshop participants noted that there are both short- and long-term<br>
paths to the solution. In the long-term, we should consider ECN, active<br>
queue management, and ways to segregate non-delay sensitive TCP traffic<br>
from interactive traffic. In the short term, there is potential to avoid<br>
self-inflicted queuing and ensure that e.g. browsers sending interactive<br>
flows don't cause excessive congestion and delay. Properties and limitations<br>
of the media codecs and feedback channel were noted, as was the trade-off<br>
between loss- and delay-based algorithms.<br>
<br>
<br>
Context: Buffer Bloat and AQM<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-4.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-4.pdf</a><br>
<br>
Jim Gettys summarised issues relating to buffer bloat and active queue<br>
management (AQM) in the network. Numerous middleboxes, especially home<br>
gateway devices, and hosts have excess buffering. This can lead to large<br>
standing queues in the presence of TCP traffic, since TCP tries to fill<br>
the pipe, but doesn't try to minimise delay. This is problematic for<br>
interactive media flows that do care about delay. There are numerous<br>
pieces to the solution including reducing buffering in the network,<br>
deploying active queue management (where the new CoDel algorithm has<br>
promise), and developing new congestion control algorithms. None are<br>
likely to solve the problem in the short term, so RMCAT will need to<br>
cope with over-buffered networks when designing a solution.<br>
<br>
<br>
Context: Competing Traffic<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-3.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-3.pdf</a><br>
<br>
Matt Mathis outlined the problems with interactive media flows competing<br>
with TCP traffic ("TCP Friendly is an oxymoron"). The fundamental problem<br>
is that TCP requires queues for correct operation, but interactive media<br>
flows cannot tolerate queueing. Modern TCP stacks are sufficiently well<br>
tuned that they will cause queuing on any network path, if they don't run<br>
out of data to send first. Matt believes the solution is a combination<br>
of traffic segregation, coupled with metrics to expose the problem. For<br>
interactive media congestion control, he recommended the group assume a<br>
(mostly) empty queue, and design the congestion control to avoid causing<br>
self-inflicted queuing delay and to provide "fair" sharing between media<br>
flows. Queuing delay is unavoidable in the presence of TCP cross-traffic,<br>
and a circuit breaker is needed to avoid serious congestion, but he<br>
suggested to avoid over-think interactions in failure cases: "protecting<br>
TCP is unnecessary, it will not return the favour".<br>
<br>
<br>
Outline Proposals for Potential Solutions<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-2.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-2.pdf</a><br>
and <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-0.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-0.pdf</a><br>
<br>
Harald Alvestrand and Piers O'Hanlon presented candidate congestion<br>
control algorithms for interactive media applications. The proposal from<br>
Harald is a delay-based algorithm, based on analysis of filtered packet<br>
inter-arrival times; Piers suggested a variant of the TFRC algorithm that<br>
also includes a delay-based component. Neither algorithm was discussed in<br>
detail.<br>
<br>
<br>
Proposed Charter and Discussion<br>
<br>
Slides: <a href="http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf" target="_blank">http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf</a><br>
<br>
Draft charter: <a href="http://rtp-congestion.alvestrand.com/bof-planning-page/wg-charter---input-to-vancouver" target="_blank">http://rtp-congestion.alvestrand.com/bof-planning-page/wg-charter---input-to-vancouver</a><br>
<br>
The chairs outlined the proposed charter and invited discussion.<br>
The following points were raised:<br>
<br>
- Matt Mathis suggested that a missing item on the charter is defining a<br>
clear metric that can be used to report congestion-related problems to<br>
the users of interactive media applications.<br>
<br>
- Magnus Westerlund asked if congestion control for calls using a mixer<br>
or other application-layer middlebox should be in scope for the group.<br>
It is possible to run a separate control loop on each side of the<br>
middlebox, but this can require media transcoding for rate adaptation<br>
if the two sides of the call achieve different bandwidth allocations.<br>
Passing congestion signals through the middlebox can allow end-to-end<br>
congestion control, avoiding transcoding, so the group should possibly<br>
consider coupled congestion control for this scenario. Cullen Jennings<br>
disagreed, wanting to limit the scope to point-to-point flows only and<br>
to remove anything to do with middleboxes.<br>
<br>
- Stephan Wenger suggested that the discussions have been behind the<br>
state of the art in joint source-channel coding. The group should<br>
consider that not all packets are equal in importance when designing<br>
congestion control algorithms.<br>
<br>
- Toerless Eckert suggested that the group may be too constrained by not<br>
being able to change TCP.<br>
<br>
- Eric Rescorla noted that the pace of browser development is fast, and<br>
would allow us to rapidly roll out new versions of congestion control<br>
provided it is scoped to running in a single application-level process.<br>
This suggests that trying to change operating system or network layer<br>
components should be outside the scope.<br>
<br>
- Harald Alvestrand and Spencer Dawkins agreed to keep the scope small,<br>
and suggested that the Transport Area could consider the wider issues,<br>
possibly creating other working groups if necessary. Limiting the scope<br>
of a possible RMCAT working group should not limit the wider discussion<br>
of the issues.<br>
<br>
- Randell Jesup wanted clarification that AQM is out of scope. The chairs<br>
agreed that defining AQM would be out of scope for RMCAT, but the group<br>
might decide to develop proposals that could use AQM if available.<br>
<br>
- Van Jacobson commented that the problem to be tackled is difficult. He<br>
recalled some of the history of developing TCP congestion control, and<br>
suggested that solving the self-interference problem for interactive<br>
media flows would be a sufficient challenge. Van recommended that the<br>
group consider impact on TCP as a second-order problem.<br>
<br>
- Jonathan Lennox, Spencer Dawkins, and others wondered why the charter<br>
proposed initial publication of the algorithms as experimental RFCs.<br>
The process is unusual, and it is not clear how deploying the<br>
algorithms in browsers with hundreds of millions of users can be<br>
classed as an experiment. Ted Hardie suggested that an important<br>
point is how easily and quickly the algorithm can be updated.<br>
<br>
- On a related note, Lars Eggert noted that defining evaluation criteria<br>
is important: what denotes success for the group? Lars also suggested<br>
that we need to be clearer on how we evaluate candidate algorithms, noting<br>
that we should have experiments that can be replicated, and competing<br>
proposals evaluated against the same criteria to ensure fairness and<br>
clarity in the evaluation. Toerless Eckert echoed these statements.<br>
<br>
- Harald Alvestrand suggested that we need to identify how multiple<br>
flows work, and how flows can be grouped together. To what extent<br>
should congestion control of aggregates of independent flows sharing<br>
a 5-tuple be in scope? Michael Welzl suggested that defined APIs may<br>
be a part of this.<br>
<br>
- Bob Briscoe cautioned the group that congestion control is a difficult<br>
problem, and suggested that we may want to develop a framework, rather<br>
than a single algorithm.<br>
<br>
- ??? suggested that a requirements document is a missing deliverable in<br>
the charter. He also noted that media congestion control is broader<br>
than RTCWEB, and suggested that the group should try to avoid limiting<br>
the applicability of the algorithms developed to just RTCWEB.<br>
<br>
The chairs wrapped-up the discussion by asking three questions:<br>
<br>
- Do you think that the problem is clear, well‐scoped, solvable, and<br>
worth solving? There was a hum in favour.<br>
<br>
- Do you support forming a WG with the charter outlined? There was a<br>
strong hum in favour.<br>
<br>
- Would you be willing to work on one or more of the drafts outlined?<br>
There was a significant constituency of people willing to work on the<br>
drafts.<br>
<br>
The charter will be updated based on the discussion and circulated on the<br>
mailing list for review. The chairs and the area directors will then work<br>
to form a working group.<br>
<br>
- + -<br>
<br>
_______________________________________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
</blockquote></div><br></div>