Subject: [rmcat] delay recovery phase

From: "Van Der Auwera, Geert" <[email-masked]>
Date: Fri, 31 Oct 2014 00:37:54 +0000

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.

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.

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.