- Rtp-congestion - alvestrand.no

Re: [R-C] Charter update
by Bob Briscoe 15 Aug '12

15 Aug '12

Michael, A few suggestions for minor changes, but otherwise, no big objections: s/ Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols/ / Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, TCP and other congestion control protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves./ s/The work will be guided by the advice laid out in RFC 5405 (UDP usage guidelines) and RFC 2914 (congestion control principles)./ /The work will be guided by the advice laid out in RFC 5405 (UDP usage guidelines), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms)./ s/The following topics are out of scope:/ /The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere:/ Bob At 12:31 13/08/2012, Stefan Holmer wrote: >Sounds good to me. > >/Stefan > >On Mon, Aug 13, 2012 at 9:40 AM, Michael Welzl ><<mailto:michawe@ifi.uio.no>michawe(a)ifi.uio.no> wrote: >Folks, > >I sense a lot of tacit approval ;-) > >Is this now ready to be shipped to the IESG? > > >Okay, I'm trying to be provocative, to get some >feedback... but seriously, I think that there >wasn't a lot of debate (in the sense of >disagreement) about the charter, just >constructive suggestions. I do believe that I >have incorporated most, if not all of them in >this version. So I'd like to try using a >deadline: could we say that I ship this off on >Wednesday 15 August unless I receive suggestions for changes by then? > >Cheers, >Michael > > > >On 10. aug. 2012, at 13:02, Michael Welzl wrote: > > > See below for an update of the charter: > > > > - some minor fixes, e.g. wording in the list of deliverables > > - the most significant change: updated milestone list > > > > Comments? > > > > Cheers, > > Michael > > > > > > > ******************************************************************************************* > > > > > > RTP Media Congestion Avoidance Techniques (rmcat) > > > > Status: Proposed Working Group > > Last Updated: 2012-08-10 > > > > Chair(s): > > TBD > > > > Transport Area Director(s): > > Wesley Eddy <<mailto:wes@mti-systems.com>wes(a)mti-systems.com> > > > > Transport Area Advisor: > > Wesley Eddy <<mailto:wes@mti-systems.com>wes(a)mti-systems.com> > > > > Mailing Lists: TBD (until establishment, we > use <mailto:rtp-congestion@alvestrand.no>rtp-congestion(a)alvestrand.no) > > > > Description of Working Group > > > > In today's current internet, part of the > traffic is delivery of interactive real time > media, often in the form of sets of media flows using RTP over UDP. > > There is no generally accepted congestion > control mechanism for this kind of data flow. > > With the deployment of applications using the > RTCWEB protocol suite, the number of such flows > is likely to increase, especially > non-fixed-rate flows such as video or adaptive > audio. There is therefore some urgency in > specifying one or more congestion control > mechanisms that can find general acceptance. > > > > Congestion control algorithms for interactive > real time media may need to be quite different > from the congestion control of TCP: for > example, some applications can be more tolerant > to loss than delay and jitter. The set of > requirements for such an algorithm includes, but is not limited to: > > Low delay and low jitter for the case > where there is no competing traffic using other algorithms > > Reasonable share of bandwidth when > competing with RMCAT traffic, other real-time > media protocols, and ideally also TCP and other protocols > > Effective use of signals like packet > loss and ECN markings to adapt to congestion > > > > The working group will: > > Develop a clear understanding of the > congestion control requirements for RTP flows, > and document deficiencies of existing > mechanisms such as TFRC with regards to these requirements. > > Define interactions between > applications and RTP flows to enable specifying > requirements such as per-packet priorities. > > Determine if there is an appropriate > means to define standard RTP/RTCP extensions > for carrying congestion control feedback, > similar to how DCCP defines congestion control > mechanisms, and if so, document such extensions as standards-track RFCs. > > Develop techniques to detect, > instrument or diagnose failing to meet RT > schedules due to failures of components outside > of the charter scope, possibly in collaboration with IPPM. > > Develop a mechanism for identifying > and controlling groups of flows. > > Define evaluation criteria for > proposed mechanisms, and publish these as an Informational RFCs. > > Find or develop candidate congestion > control algorithms, verify that these can be > tested on the Internet without significant > risk, and publish one or more of these as Experimental RFCs. > > Publish evaluation criteria and the > result of experimentation with these Experimental algorithms on the Internet > > Once an algorithm has been found or > developed that meets the evaluation criteria, > and has a satisfactory amount of documented > experience on the Internet, publish this > algorithm as a Standards Track RFC. There may be more than one such algorithm. > > > > The work will be guided by the advice laid > out in RFC 5405 (UDP usage guidelines) and RFC > 2914 (congestion control principles). > > > > The following topics are out of scope: > > Circuit-breaker algorithms for > stopping media flows when network conditions > render them useless; this work is done in AVTCORE; > > Media flows for non-interactive > purposes like stored video playback; those are > not as delay sensitive as interactive traffic; > > Defining active queue management; > modifications to TCP of any kind; and > > Multicast congestion control (common > control of multiple unicast flows is in scope). > > Topologies other than point-to-point > connections. Implications on multi-hop > connections will be considered at a later stage. > > > > The working group is expected to work closely > with the RAI area, including the underlying > technologies being worked on in the AVTCORE and > AVTEXT WGs, and the applications/protocol > suites being developed in the CLUE and RTCWEB working groups. > > It will also liaise closely with other > Transport area groups working on congestion > control, and with the Internet Congestion Control Research Group of the IRTF. > > > > Deliverables > > Requirements for congestion control > algorithms for interactive real time media - Informational RFC > > Evaluation criteria for congestion > control algorithms for interactive real time media - Informational RFC > > RTCP extensions for use with > congestion control algorithms - Standards-track RFC > > Interactions between applications and RTP flows - Informational RFC > > Identifying and controlling groups of flows - Standards-track RFC > > Techniques to detect, instrument or > diagnose failing to meet RT schedules - Informational RFC > > Candidate congestion control > algorithm for interactive real time media - > Experimental RFCs (likely more than one) > > Experimentation and evaluation > results for candidate congestion control algorithms - Informational RFC > > A recommended congestion control > algorithm for interactive real time media - Standards-track RFC > > > > Milestones > > NN NNNA: (chartering + 1 month) > Publish first drafts of requirements and evaluation criteria > > NN NNNB: (=A) publish first drafts of > RTCP extensions for use with congestion control > algorithms and interactions between applications and RTP flows > > NN NNNC: Adopt first congestion control candidate as WG draft > > NN NNND: (B + 2 months) Publish first > draft of identifying and controlling groups of flows > > NN NNNE: (A + 4 months) Submit > requirements and evaluation criteria to IESG as Informational > > NN NNNF: (B + 6 months) Submit RTCP > extensions for use with congestion control > algorithms to IESG for Standards-track > publication, and submit interactions between > applications and RTP flows to IESG as Informational > > NN NNNG: (E + 2 months) Submit first > congestion control candidate to IESG for Experimental publication > > NN NNNH: (D + 6 months) Submit > identifying and controlling groups of flows to > IESG for Standards-track publication > > NN NNNI: (G + 3 months) First draft of evaluation results > > NN NNNJ: (=I) First draft of standards-track congestion control > > NN NNNK: (=J) First draft of > techniques to detect, instrument or diagnose failing to meet RT schedules > > NN NNNL: (K + 6 months) Submit > techniques to detect, instrument or diagnose > failing to meet RT schedules to IESG as Informational > > NN NNNM: (J + 8 months) Submit > congestion control to IESG for Proposed Standard > > (time from chartering to end of charter is 18 months) > > > > > > _______________________________________________ > > Rtp-congestion mailing list > > <mailto:Rtp-congestion@alvestrand.no>Rtp-congestion(a)alvestrand.no > > http://www.alvestrand.no/mailman/listinfo/rtp-congestion > >_______________________________________________ >Rtp-congestion mailing list ><mailto:Rtp-congestion@alvestrand.no>Rtp-congestion(a)alvestrand.no >http://www.alvestrand.no/mailman/listinfo/rtp-congestion > > >_______________________________________________ >Rtp-congestion mailing list >Rtp-congestion(a)alvestrand.no >http://www.alvestrand.no/mailman/listinfo/rtp-congestion ________________________________________________________________ Bob Briscoe, BT Innovate & Design

4 4

Fairness of RRTCC and TCP
by Varun Singh 14 Aug '12

14 Aug '12

Hi, Following up on the discussion of fairness between interactive real-time flows and TCP. I've implemented the RRTCC in NS-2 and attached within are the preliminary results. The scenarios that we simulated are: 1. RRTCC flow shares a bottleneck with short TCP. 2. two RRTCC flows share a bottleneck with with short TCP flows. The short TCP flows are modelled as on/off flows. The size of the data is obtained from a uniform distribution between 100KB and 1.5MB, and the idle periods are obtained from an exponential distribution with the mean as 10. The results are available as a short presentation at: http://bit.ly/rrtcc-tcp I would appreciate any comments and/or feedback. Cheers, Varun

5 6

Charter update
by Michael Welzl 13 Aug '12

13 Aug '12

See below for an update of the charter: - some minor fixes, e.g. wording in the list of deliverables - the most significant change: updated milestone list Comments? Cheers, Michael ******************************************************************************************* RTP Media Congestion Avoidance Techniques (rmcat) Status: Proposed Working Group Last Updated: 2012-08-10 Chair(s): TBD Transport Area Director(s): Wesley Eddy <wes(a)mti-systems.com> Transport Area Advisor: Wesley Eddy <wes(a)mti-systems.com> Mailing Lists: TBD (until establishment, we use rtp-congestion(a)alvestrand.no) Description of Working Group In today's current internet, part of the traffic is delivery of interactive real time media, often in the form of sets of media flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non-fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for example, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: • Low delay and low jitter for the case where there is no competing traffic using other algorithms • Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols • Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: • Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. • Define interactions between applications and RTP flows to enable specifying requirements such as per-packet priorities. • Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines congestion control mechanisms, and if so, document such extensions as standards-track RFCs. • Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. • Develop a mechanism for identifying and controlling groups of flows. • Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs. • Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. • Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet • Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. The work will be guided by the advice laid out in RFC 5405 (UDP usage guidelines) and RFC 2914 (congestion control principles). The following topics are out of scope: • Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE; • Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic; • Defining active queue management; modifications to TCP of any kind; and • Multicast congestion control (common control of multiple unicast flows is in scope). • Topologies other than point-to-point connections. Implications on multi-hop connections will be considered at a later stage. The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also liaise closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables • Requirements for congestion control algorithms for interactive real time media - Informational RFC • Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC • RTCP extensions for use with congestion control algorithms - Standards-track RFC • Interactions between applications and RTP flows - Informational RFC • Identifying and controlling groups of flows - Standards-track RFC • Techniques to detect, instrument or diagnose failing to meet RT schedules - Informational RFC • Candidate congestion control algorithm for interactive real time media - Experimental RFCs (likely more than one) • Experimentation and evaluation results for candidate congestion control algorithms - Informational RFC • A recommended congestion control algorithm for interactive real time media - Standards-track RFC Milestones • NN NNNA: (chartering + 1 month) Publish first drafts of requirements and evaluation criteria • NN NNNB: (=A) publish first drafts of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows • NN NNNC: Adopt first congestion control candidate as WG draft • NN NNND: (B + 2 months) Publish first draft of identifying and controlling groups of flows • NN NNNE: (A + 4 months) Submit requirements and evaluation criteria to IESG as Informational • NN NNNF: (B + 6 months) Submit RTCP extensions for use with congestion control algorithms to IESG for Standards-track publication, and submit interactions between applications and RTP flows to IESG as Informational • NN NNNG: (E + 2 months) Submit first congestion control candidate to IESG for Experimental publication • NN NNNH: (D + 6 months) Submit identifying and controlling groups of flows to IESG for Standards-track publication • NN NNNI: (G + 3 months) First draft of evaluation results • NN NNNJ: (=I) First draft of standards-track congestion control • NN NNNK: (=J) First draft of techniques to detect, instrument or diagnose failing to meet RT schedules • NN NNNL: (K + 6 months) Submit techniques to detect, instrument or diagnose failing to meet RT schedules to IESG as Informational • NN NNNM: (J + 8 months) Submit congestion control to IESG for Proposed Standard (time from chartering to end of charter is 18 months)

2 2

RRTCC issues: loss, decrease rate
by Randell Jesup 08 Aug '12

08 Aug '12

This is the first of a few messages on the details of RRTCC I expect to post, based on analysis (not testing) of the algorithm, and my 8-year experience with an algorithm I designed which had very similar theory and underpinnings. This has been used (mostly in residential settings) in hundreds of thousands of devices mostly for peer-to-peer calls. Please feel free to critique! I make no assertions that this analysis is guaranteed correct (and in fact I'm sure it will be pointed out several ways in which it's wrong), but I think it will be a helpful starting point. I also realize there are some simplifications assumed below; I've tried to note them. The first focus is on loss. I'll primarily focus on the impact of tail-drop policies for now. Loss affects a stream in a number of ways: 1) Directly - loss of a packet in the RTP stream 2) Indirectly - loss of a packet for another traffic stream, for this or another destination 3) "Random" loss (non-congestion) Note: Not all channels experience "random" loss, though some "random" loss is momentary congestion of a core router or some type of AQM. Since in this case we're focusing on tail-drop routers (at the bottleneck), we'll assume this category can be modeled as non-congestive random losses. Obviously the more inputs and knowledge of the streams (especially between the two endpoints, via any port, not just the 5-tuple) the better the model can perform. A confounding issue to be discussed later is how differential packet marking affects congestion and bandwidth models. Since RRTCC works from inter-packet-delays (when compared to sending times, either from RTP timestamps of header extensions with closer-to-the-stack sending times), let's look at how these types of loss affect the signals seen by the receiver and the Kalman filter. 1) Direct loss ------------------- In this case, we'll see the loss directly. This is common in access-link self-congestion, where our stream(s) are the only significant user of bandwidth or if there are a very few users, and we've exceeded the capacity of the physical link. The inter-packet delay was likely increasing steadily leading up to the loss. For example, if the other side is sending at 220Kbps at 20ms intervals with an access bottleneck (upstream at their side, or downstream at our side) of 200Kbps, and there's no other traffic on the link, then the packets would have been coming in about 22ms apart instead of 20ms. Let's assume a very short queue depth (no bufferbloat!) of 2 packets (40ms), and look what happens. For whatever reason (packet loss, noisy signal to the filter, long RTT, cross-traffic that just went away, etc) let's assume that the system didn't react before the loss happened. When the packet is lost, there must have been 2 packets in the buffer. The receiver will see packet N, N+1, and then N+3 and N+4. N will have been delayed around 38ms, N+1 around 40ms, N+3 about 22ms, and N+4 around 24ms Pictorially this would look like a sawtooth in the delay profile. If you naively input these into the filter, it will start to move down away from a 10% slope, and might indicate a flat queue-depth profile or perhaps even negative (draining) for a short time, when in fact we've been over-bandwidth the entire time. This would depend on the exact filter type and usage, but this certainly violates some of the assumptions about error in a Kalman filter (for example, Gaussian distribution). At least in this case, a Kalman filter might not be the optimum choice. * Possible modifications: a) drop samples where there's a loss, since losses frequently perturb the delta of the next packet This will reduce the 'noise' in the inputs to the filter, especially in simple cases like above. b) increase the "uncertainty" of the next packet dramatically in the input to the filter This is an attempt to get the Kalman filter to weight the packet much lower, but not ignore it entirely. I don't see this as very useful in practice. c) look at whether there was a significant drop in delay following a loss, and use that as a separate indicator that we're over-bandwidth In my algorithm, I termed these "fishy" losses - they implied a queue suddenly shortened. Too many (more than 1) of these in a short period of time meant I would decrease sending bandwidth by a significant extra amount, since the implication is not just delay, but a full queue, which I really want to get out of fast. This is a form of modification 'c'. If we're not the only stream on the bottleneck, and we just got "unlucky" and had our packet get dropped, similar issues may occur, but the reduction in delay of the next packet may be less or much less, since we're typically metering in our packets at a frame rate. With enough other traffic, the delay of the next packet will be roughly flat (or 40ms in the case above). So this modification (c) is of most use in detecting the bandwidth/queue limit of a relatively idle link, typically an access (especially upstream) link. It therefore may want to be combined with other mechanisms. If we see a direct loss without a significant reduction in delay, we need to assume it's either a congested link (not a physical layer limit we're hitting on an idle link) or it's a "random" loss. Losses on a congested link also indicate a full queue, and so even though the delay stopped increasing (or stayed on=average stable after you've hit the max and started dropped), you still want to decrease sending rate. If it's a "random" loss (and not AQM), this causes a minor under-utilization, but for a truly congested link or if AQM is causing "random" drops, it's a signal we should reduce to try to start the queue draining. To avoid over-reaction and 'hunting', it may be good to use some type of threshold, perhaps averaged or filtered. If the loss rate reached ~5%, I'd make a mild cut in sending rate on top of any filter-suggested cuts, and if it reached ~10% I'd make a strong cut. (to be continued in another post) -- Randell Jesup randell-ietf(a)jesup.org

4 9

Charter
by Michael Welzl 08 Aug '12

08 Aug '12

Hi all, There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/… It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope). Other than that, the charter hasn't changed since the last version that was sent around in May. Cheers, Michael

9 19

Suggesting a "Flow State Exchange" (FSE)
by Michael Welzl 06 Aug '12

06 Aug '12

Hi all, This is a "chair hat taken off and thrown into a corner" message - very much my personal thoughts, and I'm very curious what you all think: Starting point: there is a desire to have priorities between flows, e.g. in rtcweb, but maybe also between other RTP streams. I have been arguing that the right way to do this is to have only a single congestion control entity, and then realize fairness among the flows as a result of scheduling data across them. I still believe that this is the right way to do it (and - Randell please correct me if I'm wrong - it seems that this is the approach already pursued by Mozilla). This thinking led me to propose my all-over-SCTP idea. Now, I don't see how such a thing could be standardized, especially if we don't want to limit ourselves to rtcweb only. HOWEVER: it is clear that flows will need information about other flows - such as: what is their priority? How many are there, that we can assume to traverse the same bottleneck (e.g. because they share the same UDP 5-tuple)? What is their current sending rate? Without having agreed on how to exchange such information, I think it will be hard to implement the above fairness solution or any other good(*) solution in a standard-conformant way. Therefore I propose that we should standardize what I think is the simplest possible, necessary element: a "Flow State Exchange" (FSE). An FSE is a *passive* entity on a host that receives congestion- control-relevant information from RTP flows and provides that information upon request. It resides on a host, and if we define it in the right way it probably doesn't matter at which layer: one could have an FSE inside the browser, and optionally have the browser talk to an additional system-wide FSE in the kernel. Note that this is not the Congestion Manager (RFC3124): the CM was an *active* entity, much more complicated to realize, and much closer to the "single congestion control instance" idea described above. With an FSE, a single congestion control instance could be realized as follows: RTP flows => update the FSE. CC. instance => reads information from the FSE, then controls the sending rate per RTP flow and schedules data across the flows. Alternative implementation (not as good, but simpler, and just to show the flexibility): RTP 1 uses its own CC, RTP 2 uses its own CC, but they feed the priority they got "from above" into the FSE and read each other's priority and total sending rate from there, to adapt their increase/decrease behavior accordingly, leading to the desired total behavior on the wire. It's not hard to imagine that this could be extended in many ways - e.g. the SCTP data channel could access the FSE to also incorporate priorities there... and implementations could provide information about which flows share a bottleneck based on measurements, not only because of the UDP 5-tuple, without requiring to standardize any of that. But the FSE itself would have to be there. What do you all think? Cheers, Michael ----------------------- (*) The only prioritization solution that I can think of which would not require something along the lines of an FSE would be prioritized congestion control, i.e. giving weights to something like MulTCP, MulTFRC ... which means that the fairness you get is essentially what flows produce, as the result of fighting it out on the bottleneck. This will create more delay than any FSE-based solution, working against one main goal of all of us here: reduced delay.

8 13

Follow up to my presentation at RMCAT
by Matt Mathis 05 Aug '12

05 Aug '12

I went back and reviewed my slides. As Van pointed out, I slightly oversold QoS. The really important point was is that it does not work for real time protocols to share queues with TCP (or other throughput maximizing protocol). QoS is just one way to manage segregated queues. There are several simpler alternatives such as Stochastic Fair Queuing and fq_codel(), which can be deployed without any global consensus on DSCP markings. If you missed the presentation, the slides are here: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-3.pdf Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay

1 0

Interesting talk in ICCRG tomorrow
by Michael Welzl 30 Jul '12

30 Jul '12

Hi, I just wanted to inform you all that in the ICCRG session tomorrow, Monday afternoon, there will be a talk by Grenville Armitage entitled "CAIA Delay-Gradient TCP", which could be of interest to this group. I'm sorry that ICCRG overlaps with RTCWEb - this is very unfortunate, and I asked to have it change, but it didn't work out. Maybe some of you folks could still make it... Cheers, Michael

1 0

BoF approved
by Wesley Eddy 25 Jul '12

25 Jul '12

The RMCAT BoF was approved to meet at IETF 84 in Vancouver. BoF chairs will be announced soon. 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. -- Wes Eddy MTI Systems

14 37

Updated agenda available
by Michael Welzl 24 Jul '12

24 Jul '12

Hi folks, The updated agenda for the RMCAT BOF is now available at: http://www.ietf.org/proceedings/84/agenda/agenda-84-rmcat and below. Cheers, Michael --- RMCAT BOF agenda, IETF #84 13:00 Introduction (Chairs) 13:05 Problem statement draft-jesup-rtp-congestion-reqs-00 (Alvestrand/Jesup) 13:25 Context: IAB/IRTF congestion control workshop 13:35 Context: competing traffic 13:45 Context: buffer bloat and AQM (Gettys) 13:55 Outline proposals for potential solutions draft-alvestrand-rtcweb-congestion-02 draft-ohanlon-rmcat-dflow-00 (Holmer/O'Hanlon) 14:05 Proposed charter (Chairs) 14:15 Discussion 14:50 Wrap-up and next steps (Chairs and ADs)

1 0