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

[Harald Alvestrand <[e-mail]>]

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).

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".


-- 
Surveillance is pervasive. Go Dark.