Subject: [rmcat] Variable Bitrate Impact on Congestion Control

From: Dan Weber <[email-masked]>
Date: Tue, 28 May 2013 18:41:00 -0600

It's important to note the role that variable bitrate plays in congestion
control.  I know we've discussed this on some level, but in reality, any
decision that's made when the underlying medium continuously changes
characteristics is an unreliable one.  If used with any sort of
instantaneous measure, it can give you unrealistic expectations of
capacity.

Just consider a large file transfer of TCP over the network.  It may
sawtooth up and down a bit, but it usually stabilizes to a certain level.
 Now if you've got a 3/3 mbit link, you have a video call going with a *max
rate* of 1.5mbit/s bidirectionally, and you're uploading or downloading the
latest DVD iso of Ubuntu, your video call may deteriorate somewhat
randomly, and you may see a good bit of bounce in the TCP download
performance.  Your file transfer over TCP is like, "Mmm..  Give me all I
can get."  and your video call is voluntarily leaving food on the table
only consuming what he needs right now.  The TCP guy is baffled by this
behavior, but takes advantage of the food as it becomes available.  Then
when someone walks across the back of the room, the video bitrate spikes,
the video guy is like, "Who just ate my lunch?"

This creates an unnecessary race for available resources, and makes it
difficult for all parties involved including other congestion controlled
streams to make best use of their available resources.

Variable bitrate in real time seems like a good idea in theory, but it
doesn't work in practice for the problem described above.  This is true for
all cases where it has to share itself with other congestion controlled
algorithms.  If it's on a dedicated link or contains special QoS, there's a
fixed number of streams allowed, each with maximum allowable bitrates, then
it can work fine all on its own.  But in that case it doesn't need
congestion control.  It's congestion controlled by design.

But to be clear, I am in no way suggesting that we use average bitrate or
constant bitrate settings from the video encoders.  I used to have this
wonderful demo that demonstrated this.  In the very first demo of my video
conference bridge (~2006), I had all of the participants displayed on to
the screen, and I had the encoder tuned to 768k/s for QVGA.  And when the
first person jump on, he would take up a quarter of the screen leaving
three quarters black.  He looked perfectly sharp, and then another person
joined.  Everything seemed okay.  The third person joins and you start
wondering why everyone started looking fuzzy.  Then when the fourth person
jumps on, it looks like everyone's face is covered in vaseline.  When
you're targeting bitrate, you're ignoring quality.

A few solutions come to mind.  It may not be feasible on anyone's real
network, but you could try using something like RSVP to perform bandwidth
reservations.  You could also fill packets with zeros to target the
bitrate.  And while this solution maybe very CPU efficient, it's not really
doing anything for you.  To me it makes the most sense to use some form of
FEC to fill up the difference.  Variable video bitrate + variable FEC
bitrate = Video Stream Max Bitrate.  Maybe you could even do something
fancy like span it across a bunch of frames or focus on your i-frames.
 Whatever rocks your ride.

On the plus side, in the event you do hit some intermittent packet loss or
you do hit some congestion, you have added resilience to protect your
stream while still having wiggle room to adjust for congestion.

Dan

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 29 May 2013 22:27:52 +0000

Hi Dan,

I would caution against any approach that says VBR leaves available bandwidth on the table for others to eat, so eat it yourself with FEC. When there are many flows, the stat-mux advantages of VBR maximize bandwidth efficiency. FEC should be applied in proportion to expected loss (or more precisely, expected effective post-FEC recovery), not greed or gluttony.

Mo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Weber
Sent: Tuesday, May 28, 2013 8:41 PM
To: [email-masked]
Subject: [rmcat] Variable Bitrate Impact on Congestion Control

It's important to note the role that variable bitrate plays in congestion control.  I know we've discussed this on some level, but in reality, any decision that's made when the underlying medium continuously changes characteristics is an unreliable one.  If used with any sort of instantaneous measure, it can give you unrealistic expectations of capacity.

Just consider a large file transfer of TCP over the network.  It may sawtooth up and down a bit, but it usually stabilizes to a certain level.  Now if you've got a 3/3 mbit link, you have a video call going with a max rate of 1.5mbit/s bidirectionally, and you're uploading or downloading the latest DVD iso of Ubuntu, your video call may deteriorate somewhat randomly, and you may see a good bit of bounce in the TCP download performance.  Your file transfer over TCP is like, "Mmm..  Give me all I can get."  and your video call is voluntarily leaving food on the table only consuming what he needs right now.  The TCP guy is baffled by this behavior, but takes advantage of the food as it becomes available.  Then when someone walks across the back of the room, the video bitrate spikes, the video guy is like, "Who just ate my lunch?"

This creates an unnecessary race for available resources, and makes it difficult for all parties involved including other congestion controlled streams to make best use of their available resources.

Variable bitrate in real time seems like a good idea in theory, but it doesn't work in practice for the problem described above.  This is true for all cases where it has to share itself with other congestion controlled algorithms.  If it's on a dedicated link or contains special QoS, there's a fixed number of streams allowed, each with maximum allowable bitrates, then it can work fine all on its own.  But in that case it doesn't need congestion control.  It's congestion controlled by design.

But to be clear, I am in no way suggesting that we use average bitrate or constant bitrate settings from the video encoders.  I used to have this wonderful demo that demonstrated this.  In the very first demo of my video conference bridge (~2006), I had all of the participants displayed on to the screen, and I had the encoder tuned to 768k/s for QVGA.  And when the first person jump on, he would take up a quarter of the screen leaving three quarters black.  He looked perfectly sharp, and then another person joined.  Everything seemed okay.  The third person joins and you start wondering why everyone started looking fuzzy.  Then when the fourth person jumps on, it looks like everyone's face is covered in vaseline.  When you're targeting bitrate, you're ignoring quality.

A few solutions come to mind.  It may not be feasible on anyone's real network, but you could try using something like RSVP to perform bandwidth reservations.  You could also fill packets with zeros to target the bitrate.  And while this solution maybe very CPU efficient, it's not really doing anything for you.  To me it makes the most sense to use some form of FEC to fill up the difference.  Variable video bitrate + variable FEC bitrate = Video Stream Max Bitrate.  Maybe you could even do something fancy like span it across a bunch of frames or focus on your i-frames.  Whatever rocks your ride.

On the plus side, in the event you do hit some intermittent packet loss or you do hit some congestion, you have added resilience to protect your stream while still having wiggle room to adjust for congestion.

Dan