- Rtp-congestion - alvestrand.no

Modular Congestion Control in rtcweb
by Luca De Cicco 29 Mar '12

29 Mar '12

Dear all, this mail follows a thread I've recently started at rtcweb(a)ietf.org. and moved to this mailing list following Harald's suggestion. Since congestion control is a fundamental building block for a multimedia communication framework such as webrtc, I think it makes sense to design the framework to allow using different congestion control algorithms such as it is done with audio/video codecs. Are there any plans to make the congestion control algorithm modular for multimedia transmission via PeerConnections? This would require the peers to select a particular congestion control algorithm at the establishment of the PeerConnection similarly to how the DCCP [1] protocol does at kernel level. Best regards, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 Refs. [1] Datagram Congestion Control Protocol (DCCP), RFC 4340, http://tools.ietf.org/html/rfc4340

13 35

MulTFRC
by Michael Welzl 27 Mar '12

27 Mar '12

Hi, Since the TCP equation seems to be used in several places by this effort and there was some discussion about TFRC today, I thought I should remind people of the existence of MulTFRC. We have made an equation that gives you the throughput of N flows (where N can also be 0.3 or 2.9 or whatever...), and we plugged that into TFRC, leading to what we call MulTFRC. This has been published in a SIGCOMM poster, ACM CCR, a Ph.D. thesis, and now also in IEEE/ACM ToN. Everything about MulTFRC is collected here: http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html The draft: http://tools.ietf.org/html/draft-irtf-iccrg-multfrc has been reviewed by 3 reviewers, who all gave their okay, except for one reviewer who (quite rightfully!) insisted on us developing a fixed- point version of the mechanism. This has turned out to be much harder than we thought, and the draft has been dormant since. We're still on the case, and hope to be able to update it soon. MulTFRC doesn't make TFRC any more delay-friendly and hence probably won't solve any of the problems that people now seems to have with TFRC, but I felt that it could be worthwhile for this crowd to know that this equation, and this mechanism, exist. Cheers, Michael

1 0

A simple comment about draft-perkins-avtcore-rtp-circuit-breakers
by Michael Welzl 27 Mar '12

27 Mar '12

So this is supposed to be for severe situations only, i.e. we want to avoid a false positive... the draft says: The congestion circuit breaker is therefore: when RTCP RR packets are received, estimate the TCP throughput using the above equation and the measured R, p (approximated by the loss fraction), and s. Compare this with the actual sending rate. If the actual sending rate has been more than an order of magnitude greater than the throughput equation estimate for two or more RTCP reporting intervals, stop transmitting. (where "the above equation" is the TCP throughput equation) but in the presentation today, a statement about reacting when you have reached 10 * that value was made. This means that the stream would stop sending when it's as aggressive as 10 TCP flows... on a host where there can easily be many more flows than that active in parallel with the RTP stream, I wouldn't judge that as a "circuit breaker" condition. My simple suggestion is to pick a much higher value, say 100? Cheers, Michael

1 0

Re: [R-C] Slides for the ICCRG session
by Harald Alvestrand 23 Mar '12

23 Mar '12

On 03/23/2012 07:57 PM, Jim Gettys wrote: > There is a problem with delay sensitive congestion control algorithms: if you have an effective AQM in place, the delays vanish, and they cease to be effective... So the premise that such an algorithm (if it is only sensitive to delay) will keep itself out of the way of other traffic seems flawed to me.... I expect Stefan to talk about that. Of course, if AQM succeeds in keeping the delays low, that part of our mission is a success :-) > Jim > > > On Mar 23, 2012, at 2:50 PM, Harald Alvestrand<harald(a)alvestrand.no> wrote: > >> My slides for the ICCRG session, all in one PDF - as of Friday night. >> Will send them to the ICCRG chairs by Sunday morning at the latest. >> >> Comments welcome; those who wish to comment on the Google Docs document can go to >> >> https://docs.google.com/a/google.com/presentation/d/1OfBO_UyxdFaey8R_cwd5Vo… >> >> and request access. >> >> Harald >> >> <IETF83ICCRGRTPCongestion.pdf> >> _______________________________________________ >> Rtp-congestion mailing list >> Rtp-congestion(a)alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtp-congestion

1 0

Fwd: Questions about the video rate control and QoS in webrtc
by Fu Jiantao 15 Mar '12

15 Mar '12

Hi Randell, I've follow your directions, seems webrtc is using TFRC to give an estimation of the bandwidth, I've read chapter 10 of "*RTP: Audio and Video for the Internet" *written by Colin Perkins<http://www.informit.com/safari/author_bio.asp@ISBN=0672322498>, according to the description on this, "*This seems to be a simple matter, but in practice there are issues to be resolved. The most critical matter is how the loss rate is measured and averaged, but there are secondary issues with packet sizing, slow start, and noncontinuous transmission*", I've got no hands-on TFRC yet, and wondering how well it works. Another question is about "Google disclosed an algorithm for doing "predictive" bottleneck-buffer queue-length sensing based on packet arrival times compared to RTP timestamps." you mentioned, I've searched but no found of the relating publication. As for the queue-length, as far as i know, there are some ISPs are using policing instead of shaping, so delay-based congestion control should not work. I've test on Skype, seems it does well in the rate control, it reacts on the bandwidth changes well, in both shaping and policing links( I use linux traffic control toolset to emulate different network environments), and it has done QoS control over different kinds of applications(In shaping network, when during video call, start a file transfer will not hurt the quality of video, the rtt is control around 90ms(2ms when no congestion), and when cancel the video call, the delay ramps up to about 120ms to make full use of the bandwidth. However, the video quality will affected in policing link when the congestion control probe for more bandwidth due to packet loss even there maybe FEC. Another difficult problem when coordinate interactive app and data app is how to identify the shared bottleneck, in shaping network, using the correlation of queuing delay seems work fine, but I've no idea how to do this in policing link. And I'm not very sure the congestion occurs at the access network. We're going to gather network statistics in the real network, in intrusive way currently. The metrics including RTT, Qdelay, Loss, Bandwidth, Lossy link information, protocol used, route etc. And I hope these can be used to improve the congestion control algorithm.(For example, as you suggested, using the user history bandwidth as a hint as the initial value) I've got numerous questions remains, listed above is some what messy. Very appreciate to your insights on these. Thanks, Jeromy 2012/3/9 Fu Jiantao <fuji246(a)gmail.com> > Thanks Randell for giving me the direction, it's extremely helpful for me. > > 2012/3/9 Randell Jesup <randell1(a)jesup.org> > >> On 3/8/2012 12:42 AM, Fu Jiantao wrote: >> >>> Hi all, >>> >>> Does anybody know how video rate control is done in webrtc? How did >>> it adjust the rate according to the bandwidth available? I haven't found >>> the relating code of congestion control, however i've seem some code to >>> do QoS, which set the DSCP in the packet. >>> >>> I'm really curious about how webrtc coordinate between different >>> kinds of applications, for example, when there's file transfer and video >>> call. I've familiar with libjingle code, and seems it lack of thus QoS >>> and traffic control logic. >>> >> >> See src/modules/rtp_rtcp/source/**bandwidth_management.cc, and related >> files and uses of REMB rtcp messages. >> >> This is an ongoing discussion on the rtp-congestion IETF mailing list, >> which was spun out of the rtcweb (IETF side of webrtc) mailing list. We're >> presenting some I-D's at IETF paris, and if you read the archives of the >> list, we have proposals for how to congestion-control multiple streams and >> also we hope to include the data-channels in the congestion regime. >> libsctp includes a congestion module that provides low-delay, and Cx-TCP >> is based on the same research and provides low-delay when possible and >> switches to higher-delay, loss-based functionality if it finds it can't >> stay in low-delay mode (fighting a saturating TCP connection(s)). >> >> >> -- >> Randell Jesup >> randell-ietf(a)jesup.org >> > >

3 3

RTP congestion meeting hosted by ICCRG in Paris
by Harald Alvestrand 07 Mar '12

07 Mar '12

This should be of interest to several of the participants. Note that the time slot for ICCRG conflicts with AVTEXT (first half) and SIPCORE (second half); we chose the SIPCORE conflict as the lesser evil. Please keep discussion of the technology on the rtp-congestion list, if you have to pick one. Harald -------- Original Message -------- Subject: [Iccrg] Preliminary agenda for ICCRG meeting @ IETF 83 Date: Wed, 07 Mar 2012 16:10:23 +0100 From: Michael Welzl <michawe(a)ifi.uio.no> To: iccrg(a)cs.ucl.ac.uk Ladies and gentlemen, Let me present to you the preliminary agenda for the ICCRG meeting at the upcoming Paris IETF, which is scheduled on Tuesday afternoon, in the 15:20-17:00 and 17:10-18:10 time slots. The second time slot is dedicated to congestion control for RTP-carried real-time media; this is an effort that comes out of rtcweb, with its own mailing list, see: http://www.alvestrand.no/mailman/listinfo/rtp-congestion The group is considering formation of a new WG, and that's why there is an item called "a possible WG charter" in the agenda - however, note that this meeting is not meant as a surrogate for a BoF (which is clearly not what a RG could or should "host"), so this will be just informational, not a time slot for wordsmithing. Content-wise, congestion control for RTP seems to be clearly in scope of ICCRG, and so I expect this to be an interesting session for all of us. Time slot 1, 15:20-17:00 * Agenda bashing and update - Michael Welzl (5 min) * Congestion Control and Notification over Longer Time Scales and at Higher Layers - Dave McDysan (20 min) draft-mcdysan-iccrg-usecases-00 * On the Fairness of Transport Protocols in a Multi-Path Environment - Hakim Adhari (15 min) (based on an upcoming ICC 2012 paper) * Caching with TCP - Pasi Sarolahti (15 min) * End-to-End Transmission Control through Inference about the Network - Keith Winstein (30 min) (based on: http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf) Time slot 2, 17:10-18:10 Topic chair: Harald Alvestrand * Introduction: The RTCWEB effort, and the traffic we expect to generate - Harald (10 min) o Doc: draft-ietf-rtcweb-overview-02 o Doc: draft-jesup-rtp-congestion-reqs-00 * Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (10 min) o Doc: draft-perkins-avtcore-rtp-circuit-breakers-00 * A delay based congestion control candidate - Stefan Holmer (15 min) o Doc: draft-alvestrand-rtcweb-congetstion-01 * Feedback mechanisms that might be useful - Harald Alvestrand (5 min) o Doc: draft-alvestrand-rmcat-remb-00 * A possible WG charter: RMCAT (15 min) o Doc: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt * Summary, conclusions, next steps (5 min) The times in slot 1 are based on what the presenters requested, but I'd think that not everyone has planned for the normal (long) duration of discussions at IETF meetings, and so it's nice to have some headroom. This being said, I think we can still squeeze a presentation in there if need be. Cheers, Michael _______________________________________________ Iccrg mailing list Iccrg(a)cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

1 0

Fwd: [AVTCORE] Request to publish draft-ietf-avtcore-ecn-for-rtp-06
by Harald Alvestrand 07 Mar '12

07 Mar '12

I'm sure most of us know about this already. I suspect this means we can regard it as relatively stable, so it might be worth including in our considerations. Harald -------- Original Message -------- Subject: [AVTCORE] Request to publish draft-ietf-avtcore-ecn-for-rtp-06 Date: Wed, 7 Mar 2012 11:28:33 +0200 From: Roni Even <ron.even.tlv(a)gmail.com> To: <iesg-secretary(a)ietf.org>, "'Robert Sparks'" <rjsparks(a)nostrum.com> CC: 'Magnus Westerlund' <magnus.westerlund(a)ericsson.com>, draft-ietf-avtcore-ecn-for-rtp.all(a)tools.ietf.org, avt(a)ietf.org Hi Robert, I'd like to request that draft-ietf-avtcore-ecn-for-rtp-06, Explicit Congestion Notification (ECN) for RTP over UDP, be published as Standard Track RFC. I've reviewed the draft in detail, and the AVTCore working group was given the opportunity to comment. The draft doesn't conflict with other work in AVTCore. Accordingly, please consider it for publication. Thanks, Roni Even (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is the result of an effort done by key WG members. It went through Working Group last call and people had enough time to review it. The document shepherd feels comfortable with the review it got. Note that the document started at AVT before it was moved to the new AVTCore WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns. No IPR disclosure related to this document or the previous individual draft and AVT version was filed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has strong consensus the members of the AVTCore WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist </id-info/checklist.html> and idnits <http://tools.ietf.org/tools/idnits/>).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There is one warning that is relevant: == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 5735 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. They are intentional as we have an SDP example of an end-point that is NATed with the address 10.0.1.4. Both the o= and the ICE candidate list thus contains such an 10.0.1.4 address. Thus I don't see an issue of using private address ranges in the example. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split. There are no normative references to documents which are not in RFC state (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document shepherd verified that the SDP signaling examples in section 12 are correct. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There were no controversy about the proposed solution and there was consensus on all discussion points Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document shepherd is not aware of current implementations. There was interest in this work by other standard bodies like 3GPP and ITU-T SG16 who need to reference it. The SDP attributes and ICE options defined in the document were sent to review in MMUSIC on September 30, 2011

1 0

Planning for Paris, and calling an urgent sync-up
by Harald Alvestrand 06 Mar '12

06 Mar '12

Hi folks, I put together a short agenda for our 1-hour slot in Paris here: https://docs.google.com/a/google.com/document/d/1vGWk3pu_w7NmSPHbcxZoUEgVb-… Please request access as appropriate, and make comments there - on this thread. Text below. Since we're (by my count) missing 2 I-Ds, and the deadline for -00 drafts is the coming Monday, I think we need to sync up *soon* for making sure we all know who's doing what - I'll open a Google Hangout at 1900 CET TODAY (Thursday, March 1) (1000 Pacific, 1800 GMT) and see who is able to get in / attend. I'm free this evening, so if someone can do it a bit later, I can accomodate, but Friday is much harder - and Monday's too late for this. Sorry to rush things like this! Harald *IETF 83 - RTP Congestion Control agenda Date, time: ICCRG meeting, one hour out of Tuesday 1520-1810 Topic chair: Harald Alvestrand (unless other volunteer found) * Introducttion: The RTCWEB effort, and the traffic we expect it to generate - XX (5 min) o Doc: draft-??-requirements-00 * Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (15 min) o Doc: draft-??-circuit-breakers-00 * A delay based congestion control candidate - Stefan Holmer (15 min) o Doc: draft-alvestrand-rtcweb-congetstion-01 * Feedback mechanisms that might be useful - Harald Alvestrand (5 min) o Doc: draft-alvestrand-rmcat-remb-00 * A possible WG charter: RMCAT (15 min) o Doc: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt * Summary, conclusions, next steps (5 min) Goals of session (priority order, please change) 1. Stimulate interest in the work among people who know the area 2. Gather feedback on requirements 3. Gather feedback on the idea of delay-based algorithms: Caveats, tests needed 4. Gather feedback on charter proposal Things that need doing before the meeting * Write a requirements document (March 7). Volunteer: XX * Write the circuit breakers document (March 7). Volunteers: Colin and Varun * More? *

4 7

Schedule conflict with AVTEXT
by Ali C. Begen (abegen) 05 Mar '12

05 Mar '12

https://datatracker.ietf.org/meeting/83/agenda.html ICCRG seems to overlap with AVTEXT where bunch of RTP people have to be. It may not be easy to move the RAI sessions around but I certainly want to avoid any conflict with AVT* sessions. -acbegen

1 0

Re: [R-C] Congestion control requirements - I-D format, -01a version
by Harald Alvestrand 05 Mar '12

05 Mar '12

On 03/05/2012 03:32 PM, Bill Ver Steeg (versteb) wrote: > We do need to get some clarity on the scope of this work. > > When I reviewed some of the earlier RTP/RTCP/ECN congestion work, I had > some concerns about its applicability to high-fan-out deployment models. > If we can find mechanisms that satisfy both the unicast and multicast > use cases, that would be great. If we are explicitly excluding multicast > from this design, we need to be very clear in the document. > > IMHO, the RTP multicast case is very important and should be in scope. > There are some techniques that can be used to aggregate and/or suppress > RTCP feedback implosions, and we can map these techniques onto ECN. > These mechanisms are in common use for error recovery in IPTV > deployments, so there is some precedent for their use. To be clear: I am not at all objecting to work on RTP multicast. What I'm saying is that *for the RTCWEB scenario*, RTP multicast is irrelevant. Given that RTCWEB is expecting to deploy on a very fast schedule, delaying work that RTCWEB may depend on in order to address the multicast scenarios is not a good option. In other words: I would like multicast to remain out of scope *for this requirement set*. > bvs > > > -----Original Message----- > From: rtp-congestion-bounces(a)alvestrand.no > [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald > Alvestrand > Sent: Sunday, March 04, 2012 5:49 AM > To: Fred Baker (fred) > Cc: Randell Jesup; Ali C. Begen (abegen); rtp-congestion(a)alvestrand.no > Subject: Re: [R-C] Congestion control requirements - I-D format, -01a > version > > On 03/04/2012 11:42 AM, Fred Baker wrote: >> You realize that this mechanism, whatever it turns out to be, has one > of the problems of reliable multicast; if the RTP service is one to > many, the RTCP service is many to one, and that can be a lot for the > one. You find yourself wanting to find some way to collude with it. >> If for example it is built on conex, it will collect CE flags in the > outbound path, and you will want some way of reporting the fact back. > Imagine it's 1:1000000, CE gets set on the first hop out, and a million > receivers decide to reply... > Yep, I regard the multicast case as a distraction for RTCWEB, however, > since it seems that trying to solve both multicast and unicast at the > same time usually results in either no solution or no deployment. > > Another thing to make clear in the introduction - that this is solving > for the unicast case.... > > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion(a)alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion >

2 1