Subject: Re: [rmcat] Variable Bitrate Impact on Congestion Control

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Jun 2013 18:45:22 +0200

Hi Dan,

I don't see your problem so much. Please not that today's congestion control, 
which you are using for your file transfer, is adaptive. Thus if your video 
congestion control is aggressive enough, you are able to get capacity back 
from the file transfer. In this phase, where the video cause more congestion 
to push away the file transfer (a bit),  you could even use more FEC to 
handle potential losses (if ECN is not available).

Just as a quick side comment: 
Congestion control does have two tasks:
1) avoid network overload
2) provide a certain sharing between competing flow
-> 2 is the the more hard task especially if you have different algorithms 
and/or a distributed system which can have a different measurement of the 
network/congestion state.

Mirja

On Thursday 30 May 2013 00:27:52 Mo Zanaty (mzanaty) wrote:
> 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

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Dan Weber <[email-masked]>
Date: Mon, 3 Jun 2013 11:28:14 -0600

Inlined.
On Mon, Jun 3, 2013 at 10:45 AM, Mirja Kuehlewind <

> handle potential losses (if ECN is not available).
DTM> My issue with this logic is that it depends on a perfect system where
everyone and everything is all knowing.  Video bitrates tend to be rather
unstable, and making congestion decisions off of something that is unstable
seems ludicrous.  Adding to that part, the real time media itself is *not
stored data*.  With stored data, an immediate drop in bandwidth performance
doesn't affect the stream that is produced.  It's the same, but the flow
rate changes.  Using an 'aggressive' congestion control scheme that goes
and acquires additional capacity/bandwidth knows that it needs it after the
fact -- e.g. After the bitstream has already been produced or encoded.
 This leaves your real time media at risk every time it needs to push more
data, and it forces it into a situation where it must be reactive
potentially creating unnecessary races for resources.

> network/congestion state.

DTM> Yes, this is exactly what I'm referring to above.  Seeking general
stream stability requires a more proactive mechanism for acquiring
resources when the underlying media sources can not react in real time.
 Now, Mo's point is valid, and without conserving bandwidth we're not
offering the most effective utilization of resources.  His comments remind
me of a mechanism designed by stock traders to see if a certain commodity
is trading within 'range'.  They're called Bollinger bands which use a
moving average as a basis for calculating the +/- 2 standard deviations
away.  For those who have seen a bell curve or a normal gaussian
distribution, +/- 2 std deviations accounts for 95% of the values.  A
mechanism such as this may provide a nice means to calculating when to step
bitrates (up or down) as well as provide a range to allow FEC to be used
alongside a variable underlying bitstream.

Here's an example for you to look at so you can see how this might work:
http://scharts.co/11zymqx

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 3 Jun 2013 20:54:44 +0000

Hi Dan,

I let this email go by without comment last week, but since others are now commenting on it … well .. let me comment on a few of your statements below (with “MAR:”).

As always, I appreciate your enthusiasm and desire to progress things.

Michael

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.

MAR: I guess you are looking at one of those TCP “speed-o-meters” when you say this.

MAR: If your TCP-based file transfer “stabilizes to a given speed” …it really isn’t …  it is actually modulating cwind (the congestion window field in the TCP header) about a value that would transfer data at that rate.

MAR: That is, when you add up the bits sent since the beginning of the file transfer and divide by the time since the start of TCP … you THINK the transfer is occurring at “a stable rate”. It is not. That TCP flow STATISTICALLY gets “its share” of the losses and the cwnd value will tell you (plot it against time during a long file transfer when it is competing for its share of the link bandwidth) that the instantaneous rate (with a time window of a few RTTs) is about a factor of 2 above and below about the average rate.

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.

MAR: The TCP isn’t baffled by the behavior at all (it doesn’t even think ;-) ). If the ACKs signal no packet loss …. the congestion window keeps increasing and it keeps sending more data … until such time as the ACKs tell a different story (that there were losses) … and then it slows down (by reducing cwnd). If the TCP could speak, it would say that it has been designed to try  to maximize its throughput per RTT – which it does.

Then when someone walks across the back of the room, the video bitrate spikes, the video guy is like, "Who just ate my lunch?"

MAR: If the video guy (any UDP source) is of high-enough BW to cause packet loss .. then the TCP thinks there is congestion (no matter what caused it) … and it will slow down .. but ONLY after it recognizes the loss (via ACKs with non-increasing segment numbers or no ACKs). This takes time (and is dependent on things like fast-retransmit option in TCP). No one told the TCP session that it couldn’t have the BW the video vacated ;-).

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.

MAR: Excluding ECN (and some TCP variants based on delay), the only way TCP “sees congestion” is via loss. It can’t see “underutilization” because underutilization doesn’t cause loss.

MAR: Remember, a given TCP session isn’t smooth and “stable” when competing on a bottleneck link – only the traffic aggregate of the sum of all the TCP flows is (relatively) smooth.

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.

MAR: From here on, I agree with Mo’s commentary.

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: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 3 Jun 2013 21:21:33 +0000

Mirja,

I agree with your basic points; just a comment on the FEC part.

Re: "... if your video congestion control is aggressive enough, you are able to get capacity back from the file transfer. In this phase, where the video cause more congestion to push away the file transfer (a bit),  you could even use more FEC to handle potential losses (if ECN is not available)."

I agree that when we are competing with TCP that we need to accept the losses that TCP will demand for the bottleneck link.

However, the manner of the losses might not be such that FEC can efficiently handle. As you will likely appreciate (I am saying this for some others here), un-correlated losses are best for FEC - as they require the least amount of bits (or interleave time) to protect.

For example, long-distance links spanning multiple continents and multiple service providers typically have isolated losses for a given flow ... as the traffic from a given flow is mixed with many different traffic streams. Those losses are likely effectively dealt with via FEC. In this case, a given RMCAT flow is typically a minority data flow in the aggregate link having the dominant losses.

Another example at the opposite end of the spectrum is a single bottleneck, with few other (TCP) flows. Those links may likely have correlated losses - as congestion effects all the flows traversing it and takes a while to clear.

This is an example where the (video) application developers will need to be smart in deciding what types of error concealment to employ BASED ON what TYPES of losses they are experiencing.

Those decisions are completely outside the scope of the RMCAT protocol. Application developers need to appreciate the transport it is riding on top of. With the RMCAT constraint of having to accommodate competing with TCP - there is nothing RMCAT can do to significantly change the (correlative) characteristic of the loss distribution.

I just didn't want this thread to conclude that FEC can fix all the loss characteristics that we may see in practice.

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
Sent: Monday, June 03, 2013 12:45 PM
To: [email-masked]
Cc: Dan Weber
Subject: Re: [rmcat] Variable Bitrate Impact on Congestion Control

Hi Dan,

I don't see your problem so much. Please not that today's congestion control, which you are using for your file transfer, is adaptive. Thus if your video congestion control is aggressive enough, you are able to get capacity back from the file transfer. In this phase, where the video cause more congestion to push away the file transfer (a bit),  you could even use more FEC to handle potential losses (if ECN is not available).

Just as a quick side comment: 
Congestion control does have two tasks:
1) avoid network overload
2) provide a certain sharing between competing flow
-> 2 is the the more hard task especially if you have different 
-> algorithms
and/or a distributed system which can have a different measurement of the network/congestion state.

Mirja

On Thursday 30 May 2013 00:27:52 Mo Zanaty (mzanaty) wrote:
> 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]
> 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.
>
> 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?"
>
> difficult for all parties involved including other congestion 
> controlled streams to make best use of their available resources.
>
> 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.
>
> 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.
> 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

--
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973