Re: [rmcat] Data available for probing bandwidth (Re: Review of draft-ietf-rmcat-scream-cc-01)

[Varun Singh <[e-mail]>]

On Sat, Jul 18, 2015 at 10:04 AM, Harald Alvestrand
<[e-mail]> wrote:
>
> Picking up on a sub-point in the scream review thread....
>
> On 07/14/2015 09:34 PM, Ingemar Johansson S wrote:
>>> I didn't say it has to be one control loop but I was wondering if it makes sense
>>> > to two completely independent control loop. I'd have expected that the
>>> > video
>>> > rate control loop takes the target sending rate as in input parameter.
>> [IJ] Could be, I recall that I tried out things like these in the past, need to look in old code and refresh my memory. My conclusion so far is that the video coder needs to be a bit opportunistic and try to push a (tiny) bit more into the transmission scheduler  than what is actually possible to push through the network. This occasionally builds a small RTP queue as the ack clocking prevents too much data in flught. Without that slight overallocation the network congestion controller will have too little data to send and eventually this leads to a higher sensitivity to other competing flows and also problems to grab free capacity.
>>
> I remember that we've also seen the problem that in order to "find"
> extra capacity, one needs to have extra data to send.
>
> In some Google experiments, we've tried with extra padding; in some QUIC
> experiments, I know they've considered using extra FEC frames (if
> sending "too much" causes loss, we will then have the data even if a
> "base" data frame was lost).

The following is mostly anecdotal: After the QUIC presentation in
Vanouver, November 2013, we went back and confirmed our results from
adaptive FEC.


Recently, Google announced Quick UDP Internet Connections (QUIC) [52]
to replace TLS and TCP from HTTP/2.0, it provides multiplexed in-order
reliable stream transport over UDP. Similar to FBRA, it trades
bandwidth for decrease in latency. QUIC too keeps a running-XOR of
some packets and sends at least 1 FEC packet for every 20 packets.
Their initial experiments show that retransmissions are reduced from
18% to 10% and the FEC produced at most 5% overhead [53].

The full paper at: http://www.netlab.tkk.fi/~varun/nagy2014mmsys.pdf

>
> We might want to break this out as a separate topic - "what do we send
> in order to probe for whether there's more bandwidth available".

This is a good discussion topic, and perhaps others have brought this
up at earlier presentations of adaptive-fec. For example, sending
duplicate redundant packets, or spreading (piggybacking) a large
I-frame across several other frames.

Alternatively, I remember this being also discussed at the netvc BoF,
more in comparison to Opus which uses inband-fec, i.e., the codec
produces 1 FEC packet for every fixed number of RTP packets. And if a
feature like the one in opus would appear in netvc's codec.

Cheers,
Varun




>
>
> --
> Surveillance is pervasive. Go Dark.
>



-- 
http://www.callstats.io