November 2011 - Rtp-congestion

Re: [R-C] [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
by Wesley Eddy 05 Dec '11

05 Dec '11

On 11/1/2011 10:34 AM, Lars Eggert wrote: > This may be of interest to the RG: > http://wiki.tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01 > Here are my comments on this (also copied to the authors and the mailing list for RTCWEB congestion control): (1) I think the model tries to correct for some effects later, but this part only makes sense if all frames are the same size, and none of the timestamps are subject to jitter being introduced by OS scheduling, MAC layer (e.g. wireless) issues, etc: """ We define the (relative) inter-arrival time, d(i) as d(i) = t(i)-t(i-1)-(T(i)-T(i-1)) """ (2) This part doesn't quite make sense to me, but I think it's just in the wording and not in the math: """ Since the time ts to send a frame of size L over a path with a capacity of C is ts = L/C we can model the inter-arrival time as L(i)-L(i-1) d(i) = -------------- + w(i) = dL(i)/C+w(i) C """ That's not a model of the inter-arrival time, it's a model of the difference between the delta timestamps and delta reception times based on difference in packet length. (3) In the definition of w(i), do you also intend to account for other sources of delays in the end systems' software? Why do we think that white noise is the right model? This seems like a big assumption, unless there's actually data that shows it holds under a very wide range of settings. (4) It should probably be understood clearly that the i values are sample numbers, but that the generation of samples comes from the behavior of the plant, and they aren't taken at the filter/controller regularly. This seems to be quite different than when the document says: """ In this document we make the assumption that the rate control subsystem is executed periodically and that this period is constant. """ (5) The algorithm at the receiver side is clueless about packet losses, and seems like it would see them only when the loss period ends (when a packet survives) and then would see them as really long inter-arrival times rather than losses? (or did I miss something really important?) (6) The rules about 2% and 10% in the sender-side algorithm seem ... odd. Unless the report interval is sufficiently long in relation to the frame rate, the percentages may not work well. These parameters have to be balanced, or the algorithm will be fragile. (7) Shouldn't the sender estimate of available bandwidth be able to go lower than the TFRC equation output if the delay has been increasing (though packets are not yet being lost)? (8) Startup is a big topic that isn't yet addressed. -- Wes Eddy MTI Systems

4 3

Re: [R-C] Lunch today: Shanghai Palace, Hyatt 2nd floor
by Harald Alvestrand 18 Nov '11

18 Nov '11

I haven't managed to write up notes from the discussion yet, but I think I remember the conclusions on what needs to be done. My memory of the conclusions: - define the circuit-breaker conditions "stop when you see this" (AVTCORE) - define the feedback messages for receiver bandwidht estimate and timestamps (AVTEXT) - create a working group for publishing the ideas and pushing a long term algorithm standard (TSV area) Others will fill in, I hope!

1 0

Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt
by Harald Alvestrand 16 Nov '11

16 Nov '11

The appendix carries the new extensions for signalling that we have discussed. Hope you like them! Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt Date: Sat, 29 Oct 2011 14:28:10 -0700 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: harald(a)alvestrand.no, holmer(a)google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 01 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2011-10-29 WG ID: Individual Submission Number of pages: 19 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

3 4

Lunch today: Shanghai Palace, Hyatt 2nd floor
by Harald Alvestrand 16 Nov '11

16 Nov '11

Coordinates for lunch today: Hyatt, 2nd floor, Shanghai Palace Reservation in the name of Alvestrand (probably spelled oddly), for 11:45 We have a private room (only way to get a table large enough). let's meet straight there (no rendezvous point). Harald

1 0

Congestion subgroup get-together?
by Harald Alvestrand 10 Nov '11

10 Nov '11

Hello friends, some of us will be in Taipei. It's unfortunate that Randell won't be. Still - it would make sense to take the opportunity to get together, preferably before the last session of RTCWEB (Thursday morning). Can I suggest that we meet for lunch on Wednesday? If anyone has a problem with that, I'll set up a Doodle, and we'll do the usual thing. Harald

3 3

Why not TFRC?
by Piers O'Hanlon 09 Nov '11

09 Nov '11

HI, I thought it would be useful to understand what people consider are the problems with TFRC, and why they mean a new congestion protocol would be better for RTCweb? Clearly TFRC does have some issues though it would be useful for the community to understand why TFRC needs to be superseded? Given that it is probably the most widely cited standard for real-time media flows and appears to have a growing number of 'TFRC based' deployments: e.g. GoogleTalk says it is 'based upon TFRC', Gnome's Empathy IM/videoconf client has recently put TFRC support into their Farsight library, and others (Magor etc) who mentioned their use of it on RTCweb. I guess I can start with a few well known issues with TFRC: - Problems with clocking the packets out for TFRC - Issues with using variable packet sizes - "Very low video bitrates at moderate loss rates" 3GPP tr26.114 - 'Oscillatory behaviour' Once a few of these are clear one would expect the new offering(s) would need to show they can demonstrate improvement in these areas. Piers O'Hanlon

5 10

Some high level requirements and discussion topics in draft-ietf-rtcweb-rtp-usage-01
by Magnus Westerlund 05 Nov '11

05 Nov '11

Hi, We authors decided to put in some text in draft-ietf-rtcweb-rtp-usage-01 around congestion control. See section 8 of https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ We appreciate feedback if we are in error or if it is a good start that can be considered to have WG consensus and be extended upon. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

4 3

REMB message, SSRC list and DiffServ
by Harald Alvestrand 02 Nov '11

02 Nov '11

I just remembered one reason why we put an SSRC list in the REMB message, and I don't think we've mentioned this on the list.... If SSRCs get sent with different DiffServ codepoints, they are going to experience very different congestion states at intermediate routers. It doesn't make sense to give feedback on them jointly or on average. We don't know yet how we should divide those SSRCs into different groups, but it's good to have the ability to do so without changing the signalling. The congestion state on a set of SSRCs should only be applied as a basis for controlling traffic over the set of data that is sent with the same DiffServ markings. (Grammar bad. I beg forgiveness, and hope the meaning carries.) Harald

3 3

Re: [R-C] Congestion Control BOF
by Randell Jesup 01 Nov '11

01 Nov '11

I'm responding to the new list, but CCing people for now until they have a chance to join; if you want to continue in this discussion join the list at http://www.alvestrand.no/mailman/listinfo/rtp-congestion On 10/8/2011 5:13 PM, Harald Alvestrand wrote: > On 10/08/2011 04:53 PM, Randell Jesup wrote: >> On 10/8/2011 7:26 AM, Harald Alvestrand wrote: >>> Randell, this seems like a very good start! >>> >>> Two thoughts from random discussion: >>> >>> - WRT timestamps, there's a header extension proposed in the >>> TFRC-for-RTP draft that would tag each packet at sending time rather >>> than at frame generation time. Could we switch to recommending this >>> timestamp, and using it if it's available? >> >> >> That could mess up A/V sync, I'm afraid. > How? The A/V timestamps would still be available for syncing, but we'd > use the send-time timestamps to compute throughput (and then would have > the ability to measure each packet's transit time individually, rather > than looking at frame generation -> frame arrival timing). Well, I'm probably being overly-worried about processing delays (and in particular differing delays for audio and video). Let's say audio gets sampled at X, and (ignoring other processing steps) takes 1ms to encode. It gets to the wire at X + <other steps> + 1. Lets say video is also sampled at X, and (ignoring other processing steps) takes 10ms to encode. It gets to the wire at X + <other steps> + 10. So we've added a 9ms offset to all our A/V sync, and in this case it's in the "wrong" direction (people are more sensitive to early-audio than early-video). And if "other steps" on each side don't balance (and they may not), it could be worse. I also worry more that in a browser, with no access to true RT_PRI processing, the delays could be significantly variable (we get preempted by some other process/thread for 10 or 20ms, etc). Also, if the receiver isn't careful it could be tricked into skipping frames it should be displaying due to jitter in the packet-to-packet timestamps. So perhaps I'm not being overly-worried. I realize that I'm trading off accuracy in bandwidth estimation (or if you prefer, reaction speed) for ease in getting a consistent framerate and best-possible A/V sync. In a perfect world we'd record the sampling time and the delta until it was submitted to sendto(), so we'd have both. (You could use a header extension to do that). Also... I've been thinking more about my two listed options for feeding the combined Kalman filter. I *think* the first option might not work in practice (treat all the packets as in one stream, and calculate arrival deltas for each packet received against the previous one). Without a hard relationship between the two timestamp clocks (in particular relative offset), you can't calculate inter-packet send times properly. You can choose an arbitrary offset between them and update it periodically, but that will not match reality; it will be offset in one direction or the other. This means that A,B will be biased in one direction, and B,A will be biased in the other - and A,A or B,B won't be biased. This might "balance out" and happen to work, but I'm distrustful without more info about timestamp-synchronization being passed. We should look into it and how well option 1 works with sync sources, because in some cases they are synchronized or could be. Ironically Harald's suggestion above (or the header-extension variant) would help work around this. -- Randell Jesup randell-ietf(a)jesup.org

7 13