Re: [rmcat] How to handle an increasing send buffer

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Adding to the list of mechanisms for confining local sending buffer depth/delay:

In NADA the further the video codec is notified of a target rates well below the rate calculated from congestion control (R_n) ; likewise the sending rate goes above that specified by congestion control (R_n) by a fair amount. This helps to deplete the queue over time, at the expense of slightly dislodging the congestion control feedback loop over the network.

Note that one can apple this mechanism in conjunction of the other mechanisms (esp. dropping RTP packets or skipping frames).

Before we decide how important this issue is, I think we need to gather some good survey data on how fast a typical modern codec — designed/configured to support live conferencing — reacts to abrupt changes in target rates.

I also fully agree that interaction between the congestion control feedback look over the network and the local encoder rate control is a) tricky business to get right; b) important for the overall performance of the video conferencing application. Just that I think we should decouple this discussion from the core congestion control algorithm (what rate to send given a certain set of network observations).

-Xiaoqing

From: Ingemar Johansson S <[e-mail]<mailto:[e-mail]>>
Date: Sunday, November 9, 2014 at 10:12 PM
To: "rmcat WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Subject: [rmcat] How to handle an increasing send buffer

Hi

Both SCReAM and NADA argues for buffering on the sender side to handle the the difference between the video coder output bitrate and the actual (or estimated) throughput of the transmission path. This is particularly useful esp. in cases where the link thorughput drops dramatically.
The problem with this of course that, while this is very helpful in order to keep the network delay well behaved, the additional queueing of Video RTP packets can in principle cause very high video frame delays unless handled properly.
There are, as I understand it a number of ways to keep the video frame bounded.  Parts of this was aAddnlready discussed at the interim but it could be good to get this discussion on the list as well.


1)      Drop RTP packets in the send buffer: Easy to implement , requires that the codec state is repaired. The good part here is that this is known already on the sender side so there is no need to way an RTT (+ a little extra) for e.g an RFC4585 generic NACK or something. A possible problem is that the codec state may be costly to repair as Full Intra Refresh may be needed.

2)      Frame skipping : Raw video frames are dropped, i.e not forwarded to the video coder. The frame rate is therefore temporarly reduced. The video codec state is preserved but the prediction can may suffer because of a larger difference between the frame. SCReAM limits the number of consequtive frame skips to avoid too large differences. It is however not known hos different video coders will react to this. Another problem is API related

3)      Sender detects a too large buffer, discards entire (or part of) send buffer and generates a Full Intra Refresh or similar, pretty similar to 1)

4)      Receiver sends an RFC4585 PLI, the sender discards entire (or part of) send buffer and generates a Full Intra Refresh or similar.

5)      Other ?

6)      Other 2 ?

7)      Do nothing, the consequence is that it may take time then for the video frame delay to become reasonably low

Perhaps there are more alternatives to the above, the SCReAM draft discuss alternative 1 and 2. This is a somewhat tricky area and one have every reason to argue whether or not this should be a part of the RMCAT charter. As I said at the interim it can be difficult to treat the network congestion control and the video rate control (including the sender buffer buffer control) as two black boxes, at least if one wish to create an optimal solution, so I guess some discussion on API is needed, not sure if RMCAT is the correct venue for this though.

Comments welcome
/Ingemar

=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com

“The difference between stupidity and
genius is that genius has its limits."
Albert Einstein
=================================