Subject: Re: [rmcat] delay recovery phase

From: Randell Jesup <[email-masked]>
Date: Sat, 01 Nov 2014 14:11:13 -0400

On 10/30/2014 8:37 PM, Van Der Auwera, Geert wrote:
>
> Hi all,
>
> I would like to start a discussion about potential sender CC behavior 
> when the link rate suddenly down-switches and as a result there is 
> significant delay buildup due to receiver CC detection delay, feedback 
> message delay, etc. Assuming that the sender receives a TMMBR message 
> (or similar) with the new max target bit rate, in this approach, the 
> sender initiates a delay recovery phase (rate undershoot) to recover 
> the delay of the buffered data as described in more details below. If 
> people think that this topic is of interest, I could provide 
> experimental results during the meeting (5min. presentation). Thanks.
>

This sounds interesting, especially as rate-switching is far more common 
in wireless scenarios, and unlike most (not all!) WiFi usecases, 
3G/4G/etc connections may well be the bottleneck link. (At 
low-signal-strength or high-contention WiFi may also cause this on a 
rate switch, I believe).

> Summary:
>
> At time instant t_0 , the link rate decreases suddenly from R_0 to R_1 
> . Since there is a response delay ΔT at the sender, the sending rate 
> is decreased at time t_1 (t_0 + ΔT). The delay increases fast from D_0 
> to D_1 during ΔT. To reduce the built up delay quickly, the sending 
> rate is decreased to R_u (<R_1 ) at time t_1 for a period of time ΔT_u 
> during which the delay is reduced. After time ΔT_u the rate is 
> increased to R_1 .
>
> The problem is to estimate ΔT at the sender side in order to compute 
> ΔT_u . The receiver sends a minimal compound RTCP packet including the 
> RR and TMMBR message to the sender with the estimated maximum bit rate 
> for the forward link. Typically, the receiver will send this message 
> immediately after congestion is detected. With this information, the 
> sender can make an estimate of ΔT as the time difference between the 
> sending time of the RTCP SR (referenced in the RR by LSR) and the time 
> that the RR+TMMBR is received, assuming that the congestion was 
> detected at the receiver side after this particular SR was received.
>

Note this is similar to a new fixed-rate flow at the bottleneck link 
that uses delta-R bandwidth; the difference would be in packet drops (a 
flow would share in these).  The other part is that the receiver may not 
know the rate changed.  In that case this may collapse to an existing 
somewhat common case - not the same as a new TCP flow, but a new 
non-congestion-controlled flow (such as many existing VoIP flows - but 
perhaps of higher magnitude).

Receiver unable to know of rate change, or unable to know the magnitude 
of it:
X1 = time link changed (one direction?  both directions?) by delta-R
X2 = time receiver recognizes that delay is increasing.  If delta-R is 
large (and that's the interesting case here), this would be relatively 
short (a few inter-frame-reception times), though the actual duration 
will depend on the algorithm being used.
(receiver sends RTCP message)
X3 = time sender receives RTCP that indicates rate change (which depends 
on the current congestion and base one-way delay in the reverse 
direction - note that if both directions downshift (which may be 
common), and media is flowing in both directions (common), then delay 
may be increasing fast in the reverse direction as well!)
X4 = time sender is able to reduce the sending rate (typically at the 
next video frame to be encoded)
X5 = time receiver sees lower sending rate and delay starts to decrease
X6 = time delay is gone
X7 = time receiver notices delay has stopped decreasing & sends 
confirming RTCP
X8 = time sender gets RTCP indicating delay has stabilized

One may presume that the receiver will send additional RTCPs with 
updated info during this, so the sender will have an idea of when the 
receiver started to see improvement and how fast things are improving.

Another interesting question is that even if the receiver knows the raw 
link rate changed from 1Mbps to 500Kbps, what does that map to in 
effective maximum rate?  On wifi, even un-contended, a 1Mbps link rate 
can't get anywhere near 1Mbps throughput of user data.  So a receiver 
(depending what the link is, and what it knows) may need to downrate, 
and it may need to guess at the down-rating.   In addition, if the 
existing link had a max of 1Mbps, and the current congestion control 
estimate is 500Kbps, and the link then drops to 500Kbps - what should 
the sender do? Nothing?  Drop to 250? Preemptively drop "some" and then 
wait for confirmation of delay-rate change via normal CC to estimate the 
rate at which delay spiked, and use that to improve the estimate of 
delay buildup it'll need to remove?

Fun fun fun...

Ignoring the theoretical, and ignoring the "we know the rate" cases, 
we're looking at the X1-8 case above.  In this case, using the magnitude 
of the delay increase rate (slope), time the estimated time from X1 to 
X4 we can estimate the amount of delay "overhang" that has built up, and 
we need to drain.  In the hypothetical above (1Mbps to 500Kbps), and 
with an RTT of 100ms (longish but not that unusual), and an X1-X4 time 
of 100 (X1->X2) + 70 (X2->X3 assuming little congestion in the reverse 
path) + 50 (X3->X4 assuming 10fps and random point in the timeline) = 
220ms before the sender can react.  However, the bottleneck isn't at the 
sender side, it's at the receiver, and so you need to add the 1/2 RTT in 
for the lowered rate to hit the congested access link at the receiver, 
so +50ms = 270ms  (realize these are all rough estimates of a specific 
case).

270ms at 2x the link rate will mean ~270ms of added delay (a lot!), and 
that means 0.27*500Kbps = 130Kb of buffered data in the link. To drain 
that "quickly" requires a major reduction in bitrate. Options include: 
cutting the send rate to ~ 1/2 the link rate:  send at 250Kbps.  Delay 
reduction to 0 added delay would be ~130/250 or ~0.5 seconds to drain.  
The sender could estimate this from the above info, and start raising 
the bitrate (say to 80 or 90% of the expected new bitrate, or just 
ramping up) after a bit more than the estimated time-to-drain, 
anticipating the result.  There will be pluses and minuses to this 
behavior depending on quality of estimate (some of which could be 
factored in) and other traffic on the access link (which might be 
estimated from the pre-change equilibrium if we know the link rate, 
which we may not).

Also, following reports to the initial one can let it refine the 
estimate of the amount of buffering that will occur, and change either 
the send rate or the time-to-start-increasing or both.

The "safe" solution is to not increase until you get info from the 
receiver that the delay has stabilized for "long enough", but that might 
add considerable time.

One other solution (given the non-continuous nature of video) is for 
video streams to skip a frame or two.  Assuming 500Kbps, minus overhead 
and audio (say total 50Kbps) at 10fps = 45Kb per frame.  So 130Kb ~= 3 
frames; a single frame skip will dramatically cut the recovery time; two 
plus a small over-correction may drain it out very fast.  Note also the 
jitter buffer on the receiver side will have adapted, and so rate 
reductions will take time to be seen in an A/V usecase (data will start 
coming in at faster-than-realtime, and the adaptive jitter buffer will 
need to run audio faster to compensate, and it can only do it so fast - 
which may depend on who's talking, etc).  This may recommend in many 
cases to not try to handle it *all* with frameskips or even mostly 
(though if the sender and receiver are matched, the sender may be able 
to anticipate the receiver's reaction and how it handles who's talking, 
and jitter buffer reduction rate).

Knowing the actual link rate (i.e. TMMBR/etc) may let it more accurately 
model some of the estimates in the X1-X8 case, and reduce X1-X2 to a 
small number.

(The comments of a frustrated protocol designer who doesn't have 
anywhere near the time to work on protocols.... :-/ )

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Stefan Holmer <[email-masked]>
Date: Mon, 03 Nov 2014 10:04:53 +0000

Sounds interesting.

In https://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-02#page-10
we go into a HOLD state where the sender should keep its bitrate constant
while waiting for buffers to drain. We don't try to estimate the time
needed to drain the buffers, but instead look at the delay change estimate
m(i); if it's less than zero buffers are likely draining.

On Sat Nov 01 2014 at 7:11:53 PM Randell Jesup <[email-masked]>
wrote:

> I would like to start a discussion about potential sender CC behavior when
> the link rate suddenly down-switches and as a result there is significant
> delay buildup due to receiver CC detection delay, feedback message delay,
> etc. Assuming that the sender receives a TMMBR message (or similar) with
> the new max target bit rate, in this approach, the sender initiates a delay
> recovery phase (rate undershoot) to recover the delay of the buffered data
> as described in more details below. If people think that this topic is of
> interest, I could provide experimental results during the meeting (5min.
> presentation). Thanks.
>
>
> in wireless scenarios, and unlike most (not all!) WiFi usecases, 3G/4G/etc
> connections may well be the bottleneck link.  (At low-signal-strength or
> high-contention WiFi may also cause this on a rate switch, I believe).
>
>
>   Summary:
>
>
>
> At time instant t0, the link rate decreases suddenly from R0 to R1. Since
> there is a response delay ΔT at the sender, the sending rate is decreased
> at time t1 (t0 + ΔT). The delay increases fast from D0 to D1 during ΔT.
> To reduce the built up delay quickly, the sending rate is decreased to Ru
> (<R1) at time t1 for a period of time ΔTu during which the delay is
> reduced. After time ΔTu the rate is increased to R1.
>
>
>
> The problem is to estimate ΔT at the sender side in order to compute ΔTu.
> The receiver sends a minimal compound RTCP packet including the RR and
> TMMBR message to the sender with the estimated maximum bit rate for the
> forward link. Typically, the receiver will send this message immediately
> after congestion is detected. With this information, the sender can make an
> estimate of ΔT as the time difference between the sending time of the RTCP
> SR (referenced in the RR by LSR) and the time that the RR+TMMBR is
> received, assuming that the congestion was detected at the receiver side
> after this particular SR was received.
>
>
> Note this is similar to a new fixed-rate flow at the bottleneck link that
> uses delta-R bandwidth; the difference would be in packet drops (a flow
> would share in these).  The other part is that the receiver may not know
> the rate changed.  In that case this may collapse to an existing somewhat
> common case - not the same as a new TCP flow, but a new
> Receiver unable to know of rate change, or unable to know the magnitude of
> it:
> short (a few inter-frame-reception times), though the actual duration will
> depend on the algorithm being used.
> on the current congestion and base one-way delay in the reverse direction -
> note that if both directions downshift (which may be common), and media is
> flowing in both directions (common), then delay may be increasing fast in
> the reverse direction as well!)
> X4 = time sender is able to reduce the sending rate (typically at the next
> video frame to be encoded)
> X7 = time receiver notices delay has stopped decreasing & sends confirming
> RTCP
> One may presume that the receiver will send additional RTCPs with updated
> info during this, so the sender will have an idea of when the receiver
> started to see improvement and how fast things are improving.
>
> link rate changed from 1Mbps to 500Kbps, what does that map to in effective
> maximum rate?  On wifi, even un-contended, a 1Mbps link rate can't get
> anywhere near 1Mbps throughput of user data.  So a receiver (depending what
> the link is, and what it knows) may need to downrate, and it may need to
> guess at the down-rating.   In addition, if the existing link had a max of
> 1Mbps, and the current congestion control estimate is 500Kbps, and the link
> then drops to 500Kbps - what should the sender do? Nothing?  Drop to 250?
> Preemptively drop "some" and then wait for confirmation of delay-rate
> change via normal CC to estimate the rate at which delay spiked, and use
> that to improve the estimate of delay buildup it'll need to remove?
>
> Fun fun fun...
>
>
> Ignoring the theoretical, and ignoring the "we know the rate" cases, we're
> looking at the X1-8 case above.  In this case, using the magnitude of the
> delay increase rate (slope), time the estimated time from X1 to X4 we can
> estimate the amount of delay "overhang" that has built up, and we need to
> drain.  In the hypothetical above (1Mbps to 500Kbps), and with an RTT of
> 100ms (longish but not that unusual), and an X1-X4 time of 100 (X1->X2) +
> 70 (X2->X3 assuming little congestion in the reverse path) + 50 (X3->X4
> assuming 10fps and random point in the timeline) = 220ms before the sender
> can react.  However, the bottleneck isn't at the sender side, it's at the
> receiver, and so you need to add the 1/2 RTT in for the lowered rate to hit
> the congested access link at the receiver, so +50ms = 270ms  (realize these
> are all rough estimates of a specific case).
>
> reduction to 0 added delay would be ~130/250 or ~0.5 seconds to drain.  The
> sender could estimate this from the above info, and start raising the
> bitrate (say to 80 or 90% of the expected new bitrate, or just ramping up)
> after a bit more than the estimated time-to-drain, anticipating the
> result.  There will be pluses and minuses to this behavior depending on
> quality of estimate (some of which could be factored in) and other traffic
> on the access link (which might be estimated from the pre-change
> equilibrium if we know the link rate, which we may not).
>
> Also, following reports to the initial one can let it refine the estimate
> of the amount of buffering that will occur, and change either the send rate
> or the time-to-start-increasing or both.
>
> One other solution (given the non-continuous nature of video) is for video
> streams to skip a frame or two.  Assuming 500Kbps, minus overhead and audio
> (say total 50Kbps) at 10fps = 45Kb per frame.  So 130Kb ~= 3 frames; a
> single frame skip will dramatically cut the recovery time; two plus a small
> over-correction may drain it out very fast.  Note also the jitter buffer on
> the receiver side will have adapted, and so rate reductions will take time
> to be seen in an A/V usecase (data will start coming in at
> faster-than-realtime, and the adaptive jitter buffer will need to run audio
> faster to compensate, and it can only do it so fast - which may depend on
> who's talking, etc).  This may recommend in many cases to not try to handle
> it *all* with frameskips or even mostly (though if the sender and receiver
> are matched, the sender may be able to anticipate the receiver's reaction
> and how it handles who's talking, and jitter buffer reduction rate).
>
> model some of the estimates in the X1-X8 case, and reduce X1-X2 to a small
> number.
>
> (The comments of a frustrated protocol designer who doesn't have anywhere
> near the time to work on protocols.... :-/ )
>
> --

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 3 Nov 2014 14:20:23 +0100

Hi Geert,

As rmcat chairs we suggest that you approach iccrg and see if they have a
slot for this presentation.

At the same time then we recognize that your presentation is of interest
for people in the rmcat wg and

if we end up with free time in the rmcat session then we would be happy to
accommodate for that you could give your presentation also there.

BR, Karen/RMCAT chairs

*From:* rmcat [mailto:[email-masked]] *On Behalf Of *Van Der
Auwera, Geert
*Sent:* Friday, October 31, 2014 1:38 AM
*To:* [email-masked]
*Subject:* [rmcat] delay recovery phase

Hi all,

Best regards,

Geert

Summary:

At time instant t0, the link rate decreases suddenly from R0 to R1. Since
there is a response delay ΔT at the sender, the sending rate is decreased
at time t1 (t0 + ΔT). The delay increases fast from D0 to D1 during ΔT. To
reduce the built up delay quickly, the sending rate is decreased to Ru (<R1)
at time t1 for a period of time ΔTu during which the delay is reduced.
After time ΔTu the rate is increased to R1.

---

From: John Leslie <[email-masked]>
Date: Mon, 3 Nov 2014 10:33:00 -0500

Stefan Holmer <[email-masked]> wrote:
> while waiting for buffers to drain.

   The first time I read this, I thought you were saying to hold the rate
constant regardless of what was happening to the delay.

   I think it would be good to explicitly state something to the effect
that rmcat will have a target delay, and will not increase sending rate
until that target is achieved.

   (Of course, that target may change if it turns out to not be
achievable...)

> We don't try to estimate the time needed to drain the buffers, but
> instead look at the delay change estimate m(i); if it's less than zero
> buffers are likely draining.

   There must be a better way of saying this...

   We can only track the delay (including rate-of-change): IMHO it's
better not to talk in terms of buffers draining, merely delay.

   (Isn't that the actual goal of rmcat -- to achieve low-enough delay?)

--
John Leslie <[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 03 Nov 2014 12:57:41 -0500

On 11/3/2014 5:04 AM, Stefan Holmer wrote:
> Sounds interesting.
>
> In 
> https://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-02#page-10 
> we go into a HOLD state where the sender should keep its bitrate 
> constant while waiting for buffers to drain. We don't try to estimate 
> the time needed to drain the buffers, but instead look at the delay 
> change estimate m(i); if it's less than zero buffers are likely draining.

Right.  My point was that for large fast changes in available bandwidth 
(due to either link changes as we're talking about here, new 
non-adaptive VoIP flows, or brand-new hungry TCP flows (which due to RTT 
or the other limitations elsewhere don't eat the entire connection), 
it's good to estimate how far behind you've fallen while waiting to 
respond.  The other solution is purposely always overreact downwards 
(though this requires having an idea how much over we may be, which 
Google's algorithm doesn't use, but can be estimated by the slope of the 
delay increase and then confirmed by the slope of the delay decrease 
after lowering send bandwidth).

And per my previous comments, judicious frame drops at the sender can 
drain a queue very fast, though that has to be balanced against 
maintaining framerate for quality.  That's partially out-of-scope for 
RMCAT, but not entirely if it can feed the source not only an "available 
bandwidth" value, but also an "estimated overhang" value (delay in time 
and bits).    The control output of RMCAT to the source does *not* have 
to be a single integer.  Some sources (audio) may not be able to make 
(much) use of it.  Others might - video by dropping frames, audio by 
using comfort noise, both by changing/dropping FEC temporarily, etc.

---

From: "Van Der Auwera, Geert" <[email-masked]>
Date: Mon, 3 Nov 2014 19:12:30 +0000

Hi Randell,

Please see inline response tagged with [GV]. Thanks.

I would like to start a discussion about potential sender CC behavior when the link rate suddenly down-switches and as a result there is significant delay buildup due to receiver CC detection delay, feedback message delay, etc. Assuming that the sender receives a TMMBR message (or similar) with the new max target bit rate, in this approach, the sender initiates a delay recovery phase (rate undershoot) to recover the delay of the buffered data as described in more details below. If people think that this topic is of interest, I could provide experimental results during the meeting (5min. presentation). Thanks.

This sounds interesting, especially as rate-switching is far more common in wireless scenarios, and unlike most (not all!) WiFi usecases, 3G/4G/etc connections may well be the bottleneck link.  (At low-signal-strength or high-contention WiFi may also cause this on a rate switch, I believe).

[GV] This is what we experienced during our testing on wireless. We see delay increases (>400ms) when there are rate drops and these built up delays often decrease slowly.

Summary:

At time instant t0, the link rate decreases suddenly from R0 to R1. Since there is a response delay ΔT at the sender, the sending rate is decreased at time t1 (t0 + ΔT). The delay increases fast from D0 to D1 during ΔT. To reduce the built up delay quickly, the sending rate is decreased to Ru (<R1) at time t1 for a period of time ΔTu during which the delay is reduced. After time ΔTu the rate is increased to R1.

The problem is to estimate ΔT at the sender side in order to compute ΔTu. The receiver sends a minimal compound RTCP packet including the RR and TMMBR message to the sender with the estimated maximum bit rate for the forward link. Typically, the receiver will send this message immediately after congestion is detected. With this information, the sender can make an estimate of ΔT as the time difference between the sending time of the RTCP SR (referenced in the RR by LSR) and the time that the RR+TMMBR is received, assuming that the congestion was detected at the receiver side after this particular SR was received.

Note this is similar to a new fixed-rate flow at the bottleneck link that uses delta-R bandwidth; the difference would be in packet drops (a flow would share in these).  The other part is that the receiver may not know the rate changed.  In that case this may collapse to an existing somewhat common case - not the same as a new TCP flow, but a new non-congestion-controlled flow (such as many existing VoIP flows - but perhaps of higher magnitude).

Receiver unable to know of rate change, or unable to know the magnitude of it:
X1 = time link changed (one direction?  both directions?) by delta-R
X2 = time receiver recognizes that delay is increasing.  If delta-R is large (and that's the interesting case here), this would be relatively short (a few inter-frame-reception times), though the actual duration will depend on the algorithm being used.
(receiver sends RTCP message)
X3 = time sender receives RTCP that indicates rate change (which depends on the current congestion and base one-way delay in the reverse direction - note that if both directions downshift (which may be common), and media is flowing in both directions (common), then delay may be increasing fast in the reverse direction as well!)

[GV] In 3G/4G scenario, it is more likely that the uplink direction is the bottleneck, and congestion happening at both UEs is less likely, although it is a worst case possibility. If congestion happens in both directions, then there may be a huge delay (and likely losses) before the senders receive any RTCP feedback.

X4 = time sender is able to reduce the sending rate (typically at the next video frame to be encoded)
X5 = time receiver sees lower sending rate and delay starts to decrease
X6 = time delay is gone
X7 = time receiver notices delay has stopped decreasing & sends confirming RTCP
X8 = time sender gets RTCP indicating delay has stabilized

One may presume that the receiver will send additional RTCPs with updated info during this, so the sender will have an idea of when the receiver started to see improvement and how fast things are improving.

[GV] In this case the question is how often the receiver should or can send the RTCPs. If the sender uses a good estimate, then it can potentially react faster.

Another interesting question is that even if the receiver knows the raw link rate changed from 1Mbps to 500Kbps, what does that map to in effective maximum rate?  On wifi, even un-contended, a 1Mbps link rate can't get anywhere near 1Mbps throughput of user data.  So a receiver (depending what the link is, and what it knows) may need to downrate, and it may need to guess at the down-rating.   In addition, if the existing link had a max of 1Mbps, and the current congestion control estimate is 500Kbps, and the link then drops to 500Kbps - what should the sender do? Nothing?  Drop to 250?  Preemptively drop "some" and then wait for confirmation of delay-rate change via normal CC to estimate the rate at which delay spiked, and use that to improve the estimate of delay buildup it'll need to remove?

Fun fun fun...

[GV] The receiver could estimate the throughput and use this in its feedback.

Ignoring the theoretical, and ignoring the "we know the rate" cases, we're looking at the X1-8 case above.  In this case, using the magnitude of the delay increase rate (slope), time the estimated time from X1 to X4 we can estimate the amount of delay "overhang" that has built up, and we need to drain.

[GV] Especially the time X2-X3 may be difficult to estimate.

In the hypothetical above (1Mbps to 500Kbps), and with an RTT of 100ms (longish but not that unusual), and an X1-X4 time of 100 (X1->X2) + 70 (X2->X3 assuming little congestion in the reverse path) + 50 (X3->X4 assuming 10fps and random point in the timeline) = 220ms before the sender can react.  However, the bottleneck isn't at the sender side, it's at the receiver, and so you need to add the 1/2 RTT in for the lowered rate to hit the congested access link at the receiver, so +50ms = 270ms  (realize these are all rough estimates of a specific case).

270ms at 2x the link rate will mean ~270ms of added delay (a lot!), and that means 0.27*500Kbps = 130Kb of buffered data in the link.  To drain that "quickly" requires a major reduction in bitrate.  Options include: cutting the send rate to ~ 1/2 the link rate:  send at 250Kbps.  Delay reduction to 0 added delay would be ~130/250 or ~0.5 seconds to drain.  The sender could estimate this from the above info, and start raising the bitrate (say to 80 or 90% of the expected new bitrate, or just ramping up) after a bit more than the estimated time-to-drain, anticipating the result.  There will be pluses and minuses to this behavior depending on quality of estimate (some of which could be factored in) and other traffic on the access link (which might be estimated from the pre-change equilibrium if we know the link rate, which we may not).

Also, following reports to the initial one can let it refine the estimate of the amount of buffering that will occur, and change either the send rate or the time-to-start-increasing or both.

The "safe" solution is to not increase until you get info from the receiver that the delay has stabilized for "long enough", but that might add considerable time.

[GV] In the approach that I am proposing, the sender estimates the time for delay recovery from the time difference between sending the RTCP SR and the time the RTCP RR+TMMBR was received, assuming that the congestion was detected after this particular SR at the receiver side. This is a relatively simple approach that puts control over the delay recovery at the sender, because the sender should know its own reaction times best (rate control). In addition, the sender can also monitor the RTT.

One other solution (given the non-continuous nature of video) is for video streams to skip a frame or two.  Assuming 500Kbps, minus overhead and audio (say total 50Kbps) at 10fps = 45Kb per frame.  So 130Kb ~= 3 frames; a single frame skip will dramatically cut the recovery time; two plus a small over-correction may drain it out very fast.  Note also the jitter buffer on the receiver side will have adapted, and so rate reductions will take time to be seen in an A/V usecase (data will start coming in at faster-than-realtime, and the adaptive jitter buffer will need to run audio faster to compensate, and it can only do it so fast - which may depend on who's talking, etc).  This may recommend in many cases to not try to handle it *all* with frameskips or even mostly (though if the sender and receiver are matched, the sender may be able to anticipate the receiver's reaction and how it handles who's talking, and jitter buffer reduction rate).

Knowing the actual link rate (i.e. TMMBR/etc) may let it more accurately model some of the estimates in the X1-X8 case, and reduce X1-X2 to a small number.

(The comments of a frustrated protocol designer who doesn't have anywhere near the time to work on protocols.... :-/ )

--

---

From: "Van Der Auwera, Geert" <[email-masked]>
Date: Mon, 3 Nov 2014 19:22:36 +0000

Hi Stefan,

Please see [GV] for response. Thanks.

Sounds interesting.

In https://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-02#page-10 we go into a HOLD state where the sender should keep its bitrate constant while waiting for buffers to drain. We don't try to estimate the time needed to drain the buffers, but instead look at the delay change estimate m(i); if it's less than zero buffers are likely draining.
[GV] I think there are two cases to consider. The first one is probing, where the rate is increased slightly step by step until the start of congestion is detected by the receiver. In this case, the delay buildup is likely small and it can be easily recovered. The second case, is a significant rate drop and delay buildup. With the same approach as in the first case, the delay buildup may decrease too slowly and instead a more aggressive delay recovery through much lower sending rate (or frame skipping) is needed.

On Sat Nov 01 2014 at 7:11:53 PM Randell Jesup <[email-masked]<mailto:[email-masked]>> wrote:
On 10/30/2014 8:37 PM, Van Der Auwera, Geert wrote:
Hi all,

Summary:

Fun fun fun...

Ignoring the theoretical, and ignoring the "we know the rate" cases, we're looking at the X1-8 case above.  In this case, using the magnitude of the delay increase rate (slope), time the estimated time from X1 to X4 we can estimate the amount of delay "overhang" that has built up, and we need to drain.  In the hypothetical above (1Mbps to 500Kbps), and with an RTT of 100ms (longish but not that unusual), and an X1-X4 time of 100 (X1->X2) + 70 (X2->X3 assuming little congestion in the reverse path) + 50 (X3->X4 assuming 10fps and random point in the timeline) = 220ms before the sender can react.  However, the bottleneck isn't at the sender side, it's at the receiver, and so you need to add the 1/2 RTT in for the lowered rate to hit the congested access link at the receiver, so +50ms = 270ms  (realize these are all rough estimates of a specific case).

--