Re: [R-C] [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
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
Please, see comments inline, labeled [HL]. Sincerely, /Henrik On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <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<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)) """
[HL] This is not a model, it's a definition of a measure at the receiver side. You can always calculate d(i) for each received frame, regardless of its size, or the sources of delay that it has seen along the way.
(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.
[HL] That is true.
(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.
[HL] I'm quite sure that additive Gaussian white noise it *not* the right model. However, as usual in signal processing, there are two reasons to make the AWGN assumption: (1) we do not know any better model, and (2) it results in tractable formulas. Formally, you would have to re-derive the Kalman filter equations based on a new noise assumption. If we are not in the business of re-deriving the Kalman filter, the assumption has no practical meaning, since we'll apply the same filter equations anyway.
(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. """
[HL] The filter is updated with each incoming sample (frame), and the timing is governed by the pace at which they arrive at the receiver. The quite refers to the rate control part of the receive-side algorithm, which makes use of the output from the filter and the over-use detector. This rate control can still be executed on a steady clock, in particular during the periods when "all is clear" and the rate control will slowly increase the rate.
(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?)
[HL] Yes, you cannot detect a packet loss until you see the gap in between two other packets. (Not even then you can be sure it's a loss; it may be a re-ordering.) If a frame is lost, the Kalman filter will be updated with the inter-arrival time and timestamp delta between the frames that actually did arrive. In that respect, the filter does not discriminate between losses and frames willfully dropped by the sender before encoding.
(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.
[HL] Quite likely, yes.
(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)?
[HL] "In words: The sender-side estimate will never be larger than the receiver-side estimate, and will never be lower than the estimate from the TFRC formula." I see now that this wording is *wrong*. It should say something like: "The sender-side estimate will never be larger than the receiver-side estimate. A reduction of the sender-side estimate triggered by loss and RTT reports will never result in an estimate lower than that from the TFRC formula." We expect the receiver-side to be much faster in response time -- simply because it is delay sensing, and not loss sensing as the sender-side -- and therefore the receive-side estimate will limit the send-side estimate in most cases. The send-side can be seen as a slave in that case. The send-side estimate is mostly there to provide a fall-back option in the case of no feedback from the receiver.
(8) Startup is a big topic that isn't yet addressed.
[HL] Yes, it is, but I'm not sure it should be stipulated in this document. The application will probably have a lot to say about this. For instance, it can know something about previous calls, and it can also implement some kind of pre-probing algorithm.
-- Wes Eddy MTI Systems ______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
On 11/8/2011 5:38 AM, Henrik Lundin wrote:
On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <wes@mti-systems.com <mailto:wes@mti-systems.com>> wrote:
On 11/1/2011 10:34 AM, Lars Eggert wrote: (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.
[HL] I'm quite sure that additive Gaussian white noise it *not* the right model. However, as usual in signal processing, there are two reasons to make the AWGN assumption: (1) we do not know any better model, and (2) it results in tractable formulas. Formally, you would have to re-derive the Kalman filter equations based on a new noise assumption. If we are not in the business of re-deriving the Kalman filter, the assumption has no practical meaning, since we'll apply the same filter equations anyway.
Right - it's very likely closer to a power-law tail than a Gaussian one, and I'm sure it's also somewhat nodal/discrete and not fully smooth, depending on the source. All of which is of relatively minor importance in practice, I believe.
(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?)
[HL] Yes, you cannot detect a packet loss until you see the gap in between two other packets. (Not even then you can be sure it's a loss; it may be a re-ordering.) If a frame is lost, the Kalman filter will be updated with the inter-arrival time and timestamp delta between the frames that actually did arrive. In that respect, the filter does not discriminate between losses and frames willfully dropped by the sender before encoding.
Right - packet losses should be dealt with separately in the algorithm. Normally you can't tell if a loss is a congestion loss, or (for example) a WiFi-induced loss, or simply a very late packet. Note that for filter updates we may want to update it with data from packets too late to be played (jitter buffer underflowed), but still arrived within X of when they "should" have arrived.
(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.
[HL] Quite likely, yes.
At minimum we need to define what 2% and 10% are measured over, and how the sender knows (RR reports I assume). I gave some detailed comments about some of this earlier; check the archives of the R-C list.
(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)?
[HL] "In words: The sender-side estimate will never be larger than the receiver-side estimate, and will never be lower than the estimate from the TFRC formula." I see now that this wording is *wrong*. It should say something like: "The sender-side estimate will never be larger than the receiver-side estimate. A reduction of the sender-side estimate triggered by loss and RTT reports will never result in an estimate lower than that from the TFRC formula." We expect the receiver-side to be much faster in response time -- simply because it is delay sensing, and not loss sensing as the sender-side -- and therefore the receive-side estimate will limit the send-side estimate in most cases. The send-side can be seen as a slave in that case. The send-side estimate is mostly there to provide a fall-back option in the case of no feedback from the receiver.
We may not need a fallback for webrtc when talking to another webrtc client. When talking to non-webrtc, we might need one.
(8) Startup is a big topic that isn't yet addressed.
[HL] Yes, it is, but I'm not sure it should be stipulated in this document. The application will probably have a lot to say about this. For instance, it can know something about previous calls, and it can also implement some kind of pre-probing algorithm.
Agreed - the algorithm should adapt no matter the starting point (and really must) - though we can recommend practices to avoid slow convergence (up or down). -- Randell Jesup randell-ietf@jesup.org
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@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<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@cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/**mailman/listinfo/iccrg<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 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.
participants (4)
-
Henrik Lundin -
Randell Jesup -
Saverio Mascolo -
Wesley Eddy