- Rtp-congestion - example.com

Fwd: [AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
by Harald Alvestrand 23 May '12

23 May '12

I assume that most people will be aware of this, but it never hurts to make sure. Harald -------- Original Message -------- Subject: [AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt) Date: Wed, 16 May 2012 14:25:58 -0700 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> CC: avtcore chair <avtcore-chairs(a)tools.ietf.org>, avtcore mailing list <avt(a)ietf.org>, RFC Editor <rfc-editor(a)rfc-editor.org> The IESG has approved the following document: - 'Explicit Congestion Notification (ECN) for RTP over UDP' (draft-ietf-avtcore-ecn-for-rtp-08.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ Technical Summary 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 There were no controversy about the proposed solution and there was consensus on all discussion points Document Quality There is at least one research implementation and there is fairly strong commercial interest. 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 Personnel Roni Even is the document shepherd. Robert Sparks is the responsible area director. _______________________________________________ Audio/Video Transport Core Maintenance avt(a)ietf.org https://www.ietf.org/mailman/listinfo/avt

1 0

Hold the date: Trying to get a workshop on congestion control for real time interactive media together....
by Harald Alvestrand 19 May '12

19 May '12

FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work. This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF. The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement.... Harald

1 0

Another draft charter for the RMCAT WG
by Harald Alvestrand 18 May '12

18 May '12

I tried for a more concise and "pointy" version of the description of what we need to get done. The text below came out. Is this something we can use as a starting point? What needs to change? This is a charter based on the one suggested in December 2011, but substantially rewritten. It is an input document. Draft is here: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/… RTP Media Congestion Avoidance Techniques (rmcat) Status: Proposed Working Group Last Updated: 2012-05-08 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. The set of requirements for such an algorithm includes, but is not limited to: * Low delay for the case where there is no competing traffic using other algorithms * Fair share of bandwidth when there is competing traffic using other algorithms * 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 * Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. * 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 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. * Modifications to TCP of any kind. The working group is expected to work closely with the RAI area, including the AVTCORE, AVTEXT and RTCWEB working group. 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 * Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC * RTCP extensions for use with congestion control algorithms - Standards-track 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 - still missing

3 3

BOF agenda for Vancouver
by Harald Alvestrand 11 May '12

11 May '12

It's time to get our act together for Vancouver if we wish to maintain "full speed ahead" with getting protocol documents suitable for real-time interactive media worked on and published. Here's a proposed BOF agenda - a way to spend 2 hours on figuring out what the right work is to do. BOF agenda, RMCAT BOF - Vancouver IETF The following is a draft agenda, subject to modifications. Names are tentative. * Intro (Chairs - 5 min) * Problem statement (Harald/Randell) - 25 min Covers existing protocols and their effect on low-delay streams * Context setting: BufferBloat & AQM (10 min) (?Gettys?) * RRTCC draft (10 min) (Stefan?) Describes existing proposal, Covering areas for improvement * Alternative Solution (10 min) (?) * Modified Cx-TCP?? Modified TFRC??? * Charter presentation, discussion (50 min) * Next steps/conclusion (10 min) Total timeslot: 2 hours.

3 3

Packet loss response - but how?
by Harald Alvestrand 04 May '12

04 May '12

Now that the LEDBAT discussion has died down.... it's clear to me that we've got two scenarios where we HAVE to consider packet loss as an indicator that a congestion control algorithm based on delay will "have to do something": - Packet loss because of queues filled by TCP (high delay, but no way to reduce it) - Packet loss because of AQM-handled congestion (low delay, but packets go AWOL anyway) We also have a third category of loss that we should NOT consider, if we can avoid it: - Packet loss due to stochastic events like wireless drops. (aside: ECN lets you see the difference between the first group and the second: ECN markings are unambiguously in the first group. But we can't assume that ECN is universally deployed any time soon.) Now - the question is HOW the receiver responds when it sees packet loss. Some special considerations: - Due to our interactive target, there is no difference between a massively out of order packet and a lost packet. So we can regard anything that comes ~100 ms later than it "should" as lost. - Due to the metronome-beat nature of most RTP packet streams, and the notion of at least partial unreliability, the "last packet before a pause is lost" scenario of TCP can probably be safely ignored. We can always detect packet loss by looking at the next packet. Thoughts? Harald

5 7

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 30 Apr '12

30 Apr '12

On 4/26/2012 11:49 AM, Nicholas Weaver wrote: > On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote: >>> http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf >>> >>> It seems like AQM causes LEDBAT to promote to behavior similar to TCP, >>> but with low delay. Since it still seems fair, this is ok, but it's no >>> longer a background or scavenger flow, and applications using it need >>> to be aware they can impact "foreground" flows if AQM is in play. >>> Perhaps applications need to be given awareness when LEDBAT detects >>> active AQM (if it can), and there's no "scavenger" CC algorithm for AQM >>> that I know of. >> And the document makes that clear and I am not sure LEDBAT actually can detect AQM. > One thought: Active Queue management will be either ECN or early drop. Which is a signal separate to the delay signal used which is "friendlier than TCP". > > In either case, the scavenger flow property might be, well, not fully maintained but at least encouraged by backing off more than conventional TCP would to the same signal. Correct, and that's a reasonable way to proceed - though it might complicate slightly (and certainly change) the LEDBAT competing with LEDBAT case. In my delay-sensitive CC algorithm, I detected drops, and in particular "fishy" drops where the end-to-end delay in the following packet was lower by roughly the normal arrival interval, and would take those as an indication that we should drop more substantially than 'normal'. This was targeted at tail-drop detection, especially congestion spikes, but for a scavenger protocol the same idea could apply to make it more responsive to AQM. Basically, for a scavenger protocol any drop is a warning that either you or someone else has pushed a queue up to tail-drop levels, or that AQM is in play. In either case you should back off, and if you back off more than TCP would, that that allows TCP to retain it's foreground advantage while not hurting scavenger performance (much?) when it competes with itself. It may want to use drops to develop an estimate of the bottleneck queue depth (if less than the target value), to help avoid triggering tail-drops when not competing with TCP. (I.e. a target of 100ms doesn't make sense if the bottleneck queue is 50ms deep - and you can consider AQM really the equivalent of a minimal-depth queue at the bottleneck.) Such an estimate (which would be near 0 for AQM) might let it properly handle AQM, which is an idea which might help in RRTCC as well. For those looking for the "RRTCC" (horrible name :-) draft, here's the latest: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02 From: harald(a)alvestrand.no This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt Date: Wed, 25 Apr 2012 05:03:35 -0700 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: holmer(a)google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 02 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-04-25 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. -- Randell Jesup randell-ietf(a)jesup.org

2 3

Slides for the ICCRG session
by Harald Alvestrand 25 Apr '12

25 Apr '12

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

3 2

Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt
by Harald Alvestrand 25 Apr '12

25 Apr '12

This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt Date: Wed, 25 Apr 2012 05:03:35 -0700 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: holmer(a)google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 02 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-04-25 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. The IETF Secretariat

1 0

Admin: Old mail
by Harald Alvestrand 25 Apr '12

25 Apr '12

I've been remiss in cleaning out the spam filter on this list, and it had collected some defintely non-spam messages from non-subscribers. Apologies for the onslaught of old mail. Harald

1 0

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 25 Apr '12

25 Apr '12

On 4/24/2012 4:35 PM, Rolf Winter wrote: >> We know when faced with deep buffers and large loss-based flow, a delay >> flow will lose or have to transition to loss-based and live with delay >> (see Cx-TCP). We also know that in practice, the (residential) >> bottleneck links are almost always the access link (DSL, fiber, etc) or >> sometimes the WiFi connection. Corporate/educational can be a bit >> different, but there's a better chance of AQM or service-based traffic >> shaping there. >> >> We can deal (mostly) with fighting with TCP and expected it. We didn't >> expect scavenger protocols to be pumping the queues up when TCP is idle >> or bursty. > Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth. Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, b) use a 'fair' share of bandwidth (all available if the other flows don't use all the available bandwidth). Low delay generally takes precedence over bandwidth, though eventually we hit a wall and can't reasonably reduce bandwidth more. The design goals are not identical to LEDBAT; but these protocols need to share the network "well" with each other and TCP (and inflexible UDP flows like classic VoIP). TCP is a given (unfortunately), and drop-tail routers with deep buffers are also a given (very unfortunately, especially with TCP). We can't stop TCP from grabbing all buffers; though there may be limited ability to "knock TCP back" some periodically when there are a small number of competing TCP flows, at the costs of delay bursts - but that probably isn't practical (a usable experience) for users. >> I note that LEDBAT is now in Linux and MacOS, so it's not just in >> application code anymore, and app developers (even OS developers) may >> assume it's safe to blindly use without user involvement. (And even if >> informed, assuming users understand the interaction of protocols is ... >> a stretch.) > And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success". Millions != experiments. This is wide-scale deployment, and implying it isn't is misleading (as will deployment of WebRTC). And implementation in core OS/X and Linux one assumes will lead to use by OS functions and applications such as cloud file backup, app update, etc. So if this "breaks" the network, we have a problem. >> Note that no routers are likely to recognize rtcweb traffic as VoIP >> since the signaling is opaque and application-dependant, so ALGs and >> the like have nothing to work against. It would have to 'guess' that >> the packet stream leading byte pattern and STUN/ICE traffic signified >> use of the port for VoIP. Eventually they may learn, but it will take >> years. >> >> I stand by the contention this is a real, significant problem which >> could get far worse if non-user-centric services start using LEDBAT. > Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would. I think this is a false dichotomy, in that there are other choices for such applications, such as TFRC, RRTCC (which we're defining), TCP-Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to loss-based fair sharing when faced with TCP - modifying it can probably lead to it dropping to low BW when competing) and for that matter LEDBAT itself (or a variant thereof) with different tunings. I believe RRTCC could cover a fair amount of of the goals of LEDBAT with alternate tunings, for example. Let me be clear: *if* widespread LEDBAT use, especially by "background"/non-user-visible apps will cause major disruption of VoIP flows on the net (and in particular for flows from within the same residence or enterprise), then there's a real problem with encouraging deployment. If it does not, then the issue is minor. I also believe that we do not know the answer to this question currently, though I believe the answer it is that it will cause significant delay and quality loss, and we have some evidence to that effect. Also (and I haven't checked this yet): how does LEDBAT respond to AQM? From telecom-paristech.fr: The experimental work in [ITC22] exploits instead a own implementation and points that LEDBAT may not work as expected (and actually might be needed) in case active queue management techniques AQM are applied in user modems (the study also suggests AQM to become a default practice in set-top-box devices) http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf It seems like AQM causes LEDBAT to promote to behavior similar to TCP, but with low delay. Since it still seems fair, this is ok, but it's no longer a background or scavenger flow, and applications using it need to be aware they can impact "foreground" flows if AQM is in play. Perhaps applications need to be given awareness when LEDBAT detects active AQM (if it can), and there's no "scavenger" CC algorithm for AQM that I know of. -- Randell Jesup randell-ietf(a)jesup.org

2 2