Rtp-congestion

Download

rtp-congestion@alvestrand.no

December 2011

3 participants
2 discussions

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

14 Dec '11

[limiting to mailing list and original posters] Henrik, Stefan, do we have measurements we can share? On 12/05/2011 09:21 AM, Saverio Mascolo wrote: > hi all, > > the model could be weak....however before going into "theoretical > questions" can we look at measurements? > > > thanks > saverio > > On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <wes(a)mti-systems.com > <mailto:wes@mti-systems.com>> wrote: > > 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 > > _______________________________________________ > Iccrg mailing list > Iccrg(a)cs.ucl.ac.uk <mailto:Iccrg@cs.ucl.ac.uk> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg > > > > > -- > Prof. Saverio Mascolo > Dipartimento di Elettrotecnica ed Elettronica > Politecnico di Bari > Via Orabona 4, 70125 Bari Italy > Tel. +39 080 5963621 > Fax. +39 080 5963410 > email:mascolo@poliba.it <mailto:email%3Amascolo@poliba.it> > > http://c3lab.poliba.it > > > ================================= > This message may contain confidential and/or legally privileged > information. > If you are not the intended recipient of the message, please destroy it. > Any unauthorized dissemination, distribution, or copying of the > material in > this message, and any attachments to the message, is strictly forbidden.

2 1

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