Subject: [rmcat] Live slide show modeling

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 7 Apr 2016 06:39:02 +0000

Hi

Do you have a reasonably rough idea of how to model the transmission of a
live slide show.

I can, from the discussion on the chat, imagine something like

Frame period : 1s, or 5s, something else ?

Frame size : ? a 1920x1080 jpg compressed image is something like 500+ kB ?

/Ingemar

==================================

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 <mailto:[email-masked]> [email-masked]

www.ericsson.com

           This report, by it´s very length, 

 defends itself against the risk of being read

                       Winston Churchill

==================================

---

From: Stefan Holmer <[email-masked]>
Date: Thu, 07 Apr 2016 08:26:55 +0000

I'd model it as a low framerate (~5 fps) stream, where with some
probability (maybe between 0.005 and 0.05) a frame is large due to a slide
change (say 50-400 packets). In between slide changes the frames can be
compressed to a single packet.

/Stefan

On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S <
[email-masked]> wrote:

> [email-masked]
>
> www.ericsson.com
>
>
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 7 Apr 2016 09:54:31 +0000

Hi

Ok, thanks, I assume that rate adaptation is not really applicable here ?. Instead it is more a task to verify that the congestion control does not transmit more than what fits in the bottleneck, to avoid excess packet drops or delay ?

/Ingemar

From: Stefan Holmer [mailto:[email-masked]] 
Sent: den 7 april 2016 10:27
To: Ingemar Johansson S; Randell Jesup ([email-masked])
Cc: rmcat WG ([email-masked])
Subject: Re: Live slide show modeling

I'd model it as a low framerate (~5 fps) stream, where with some probability (maybe between 0.005 and 0.05) a frame is large due to a slide change (say 50-400 packets). In between slide changes the frames can be compressed to a single packet.

/Stefan

On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S <[email-masked]> wrote:

Hi

Do you have a reasonably rough idea of how to model the transmission of a live slide show.

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 <http://www.ericsson.com> www.ericsson.com

                       Winston Churchill

---

From: Stefan Holmer <[email-masked]>
Date: Thu, 07 Apr 2016 10:58:51 +0000

Right. My experience is that during the periods of static content, the
congestion controller may run into problems due to being rate limited and
network jitter. Once it's time to transmit a huge frame the rate/cwnd is
very low and it takes several seconds to send the frame even though the
connection is typically good.

On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S <
[email-masked]> wrote:

> Hi
>
>
>
> Ok, thanks, I assume that rate adaptation is not really applicable here ?.
> Instead it is more a task to verify that the congestion control does not
> transmit more than what fits in the bottleneck, to avoid excess packet
> drops or delay ?
>
>
>
> /Ingemar
>
>
>
> *From:* Stefan Holmer [mailto:[email-masked]]
> *Sent:* den 7 april 2016 10:27
> *To:* Ingemar Johansson S; Randell Jesup ([email-masked])
> *Cc:* rmcat WG ([email-masked])
> *Subject:* Re: Live slide show modeling
>
>
>

---

From: Sergio Mena <[email-masked]>
Date: Thu, 7 Apr 2016 14:26:33 +0200

Hello,

If someone can provide a set of traces (i.e., sequence of frame sizes) 
for a slide show-type sequence. We can easily incorporate them to 
syncodecs, which will do scaling/interpolation of the frame sizes based 
on the current target bitrate coming from the congestion controller.

Very easy to do... the result being very easy to use :-)

Then, candidate algorithms can use this to make sure they handle the 
bursts properly.

Just let us know,

Sergio

On 07/04/16 11:54, Ingemar Johansson S wrote:
>
> Hi
>
> Ok, thanks, I assume that rate adaptation is not really applicable 
> here ?. Instead it is more a task to verify that the congestion 
> control does not transmit more than what fits in the bottleneck, to 
> avoid excess packet drops or delay ?
>
> /Ingemar
>
> *From:*Stefan Holmer [mailto:[email-masked]]
> probability (maybe between 0.005 and 0.05) a frame is large due to a 
> slide change (say 50-400 packets). In between slide changes the frames 
> can be compressed to a single packet.
>
> /Stefan
>
> On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi
>
>     <mailto:[email-masked]>
>
>     www.ericsson.com <http://www.ericsson.com>
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 7 Apr 2016 12:43:20 +0000

Did a quick shot where I created a frame size trace according to the guidelines below , the probability of a large frame is 0.05.

The bottleneck BW is limited to 500kbps, RTT=100ms

Please see attached png. 

I did not optimize SCReAM for this, there is a possibility that one need to turn off the feature that clears the transmit queue if it becomes too large, this feature can then be defined as optional on a SCReAM-stream level.

Another observation is that CWND is estimated too high between ~12 and 40s. So there is probably room for improvement but at least it does not break down.

I also attached the frame size trace, realize that the 1st frame should probably be large.

/Ingemar 

From: Stefan Holmer [mailto:[email-masked]] 
Sent: den 7 april 2016 12:59
To: Ingemar Johansson S; [email-masked]
Cc: [email-masked]
Subject: Re: Live slide show modeling

Right. My experience is that during the periods of static content, the congestion controller may run into problems due to being rate limited and network jitter. Once it's time to transmit a huge frame the rate/cwnd is very low and it takes several seconds to send the frame even though the connection is typically good.

On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S <[email-masked]> wrote:

Hi

/Ingemar

/Stefan

Hi

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

                       Winston Churchill

---

From: Ingemar Johansson S <[email-masked]>
Date: Sat, 9 Apr 2016 07:43:31 +0000

Hi

I am not sure that I get the question, I assume that the large frames are broken up in MTU sized RTP packets and paced out at a rate that the congestion control allows. I don’t believe that I have misunderstood it but I am never 100% sure of anything J

/Ingemar

From: Xiaoqing Zhu [mailto:[email-masked]] 
Sent: den 7 april 2016 20:51
To: Ingemar Johansson S
Cc: [email-masked]; [email-masked]; [email-masked]; Sergio Mena
Subject: Re: [rmcat] Live slide show modeling

Hi folks,

Catching up on this thread. I understand that the frame size will typically be small when user stays on the same slide; when user switches slide, however, one will need to send a much larger frame. That's the characterization so far for the traffic source.

Given that slide sharing is less delay sensitive than video, can the sender break up the big frame and spread it out a bit when sending it out?  If we can do that then the network won't see any big bursts, right?

Just trying to gauge whether slide sharing poses a real challenge or not for the purpose of congestion control.

Thanks,

Xiaoqing

On Thursday, April 7, 2016, Ingemar Johansson S <[email-masked]> wrote:

Please see attached png. 

/Ingemar 

From: Stefan Holmer [mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> ] 
Sent: den 7 april 2016 12:59
To: Ingemar Johansson S; [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> 
Cc: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> 
Subject: Re: Live slide show modeling

On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> > wrote:

Hi

/Ingemar

From: Stefan Holmer [mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> ] 
Sent: den 7 april 2016 10:27
To: Ingemar Johansson S; Randell Jesup ([email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> )
Cc: rmcat WG ([email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> )
Subject: Re: Live slide show modeling

/Stefan

On Thu, Apr 7, 2016 at 8:39 AM Ingemar Johansson S <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> > wrote:

Hi

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 <javascript:_e(%7B%7D,'cvml',[email-masked]');> [email-masked]

                       Winston Churchill

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Apr 2016 13:07:05 -0400

*From:* Xiaoqing Zhu [mailto:[email-masked]]
>
> *Sent:* den 7 april 2016 20:51
> *To:* Ingemar Johansson S
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> Sergio Mena
> *Subject:* Re: [rmcat] Live slide show modeling
>
> Catching up on this thread. I understand that the frame size will 
> typically be small when user stays on the same slide; when user 
> switches slide, however, one will need to send a much larger frame. 
> That's the characterization so far for the traffic source.
>
> Given that slide sharing is less delay sensitive than video, can the 
> sender break up the big frame and spread it out a bit when sending it 
> out?  If we can do that then the network won't see any big bursts, right?
>
> Just trying to gauge whether slide sharing poses a real challenge or 
> not for the purpose of congestion control.
>

The concern (as Stefan indicated) is the the lack of large traffic 
inbetween slides means the bitrate estimates may either a) decay, 
causing very slow sending of the large slide-changes as it tries to 
adapt up, or b) become out-of-date/too-high, which may lead to 
congestion/delay or loss when sending a large slide-change.

Similar issues can occur (or worse) coming off-mute.  In neither case do 
you want a lot of delay and dropped frames trying to get "back to speed" 
(or to get the slide you're talking about out, especially if it's not a 
cut, but is a wipe - that would be horrible if the send-rate decays like 
Stefan indicated).

Fundamentally, inbetween frames uncertainty about bitrate available 
increases.  Doesn't mean we have less, but our info becomes dated and 
less reliable.  Similarly, a series of smaller-than-available-bandwidth 
frames allows uncertainly to increase, though not as much (you get a 
lower bound).

If I were designing the algorithms ;-), I'd include an uncertainty 
factor/state based on time since we tested/hit an upper limit (and 
something equivalent for lower).  When we don't send for a while, I'd 
assume the upper limit is more uncertain, but would *not* decay our 
estimate.  I would factor this into our reaction to delay or lack of 
delay when we do send - if we're uncertain, and then start pushing and 
see delay, I'd back off faster and further than if we'd been pretty 
certain of the current delay - much like at startup, which is another 
form of "uncertain" (especially if you base the initial bitrate on 
previous initial bitrates).

IMHO.  I think some of the requirements touch on these factors; 
certainly some along the process did.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 13 Apr 2016 18:59:52 +0200

Thanks. Could you try the same thing with TCP cross traffic…?

Mirja

> Am 07.04.2016 um 14:43 schrieb Ingemar Johansson S <[email-masked]>:
> 
> <size.txt>

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 13 Apr 2016 18:19:00 +0000

You mean like the test cases with competing traffic? Can give it a try. The bottleneck BW is of course higher in this cases
Ingemar

Skickat från min iPhone

> 13 apr. 2016 kl. 18:59 skrev Mirja Kühlewind <[email-masked]>:
>

---

From: Miguel París Díaz <[email-masked]>
Date: Wed, 13 Apr 2016 21:36:29 +0200

Hello everybody,
I am happy of seeing that you are working in this case :D.

We worked with a client that wanted to do screensharing with very low frame
rate (1-5 fps) but with very high quality for 4K screen size. With this
requirements we got some huge video frames (typically when screen changed a
lot) that produced peaks of ~1000 RTP packets.
In our case, the Media Server tried to send all packets as soon as
possible, so the packets were lost in the own UDP stack (I think that in
the ring buffer). To fix this a kind of shaping is needed.

Taking into account this experience, I though that this shaping should be
done by the Congestion Control (if there is Congestion Control) or for a
basic shaping mechanism based on heuristics (if there is NOT Congestion
Control). Because of this, I exposed this situation the last week in the
RMCAT meeting of the IETF 95.

I hope this info help you to improve your testbed, although it seems that
the model suggested by Stefan and the graphs showed by Ingemar. are very
similar with the problem that I tell you.

To conclude, will this be taken into account in the GCC algorithm for the
Chrome WebRTC implementation?

Best regards!!

2016-04-13 20:19 GMT+02:00 Ingemar Johansson S <
[email-masked]>:

> You mean like the test cases with competing traffic? Can give it a try.
> The bottleneck BW is of course higher in this cases
> Ingemar
>
> Skickat från min iPhone
>
> >> Did a quick shot where I created a frame size trace according to the
> guidelines below , the probability of a large frame is 0.05.
> >>
> >> I did not optimize SCReAM for this, there is a possibility that one
> need to turn off the feature that clears the transmit queue if it becomes
> too large, this feature can then be defined as optional on a SCReAM-stream
> level.
> >> Another observation is that CWND is estimated too high between ~12 and
> 40s. So there is probably room for improvement but at least it does not
> break down.
> >>
> >> Ok, thanks, I assume that rate adaptation is not really applicable here
> ?. Instead it is more a task to verify that the congestion control does not

-- 
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 14 Apr 2016 06:36:34 +0000

Hi

Attached an example with Test case 5.1 The bottleneck BW is 2Mbps, RTT=100ms.
Not completely a walk in the park, the problem in SCReAM is that the congestion window validation starts to limit the congestion window too much and that leaved me with frames delays of 2seconds for the larger frames. Added a small fix that disables congestion window validation when competing TCP is detected. The result is shown in the attached graph. As one can see it works quite OK.
I believe that the fix can be replaced with something smarter though but need to leave that to later. 

And... thanks Mirja for all the help and input to especially the SCReAM work in your WG chair position.

/Ingemar 

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: den 13 april 2016 19:00
> To: Ingemar Johansson S
> > I did not optimize SCReAM for this, there is a possibility that one need to
> turn off the feature that clears the transmit queue if it becomes too large,
> this feature can then be defined as optional on a SCReAM-stream level.
> 40s. So there is probably room for improvement but at least it does not break
> down.
> >
> network jitter. Once it's time to transmit a huge frame the rate/cwnd is very
> low and it takes several seconds to send the frame even though the
> > On Thu, Apr 7, 2016 at 11:54 AM Ingemar Johansson S
> <[email-masked]> wrote:
> > Hi
> >
> transmit more than what fits in the bottleneck, to avoid excess packet drops
> or delay ?
> >
> > /Ingemar
> >
> <[email-masked]> wrote:
> > Hi
> >            This report, by it´s very length,  defends itself against
> > the risk of being read
> >                        Winston Churchill

---

From: Randell Jesup <[email-masked]>
Date: Thu, 14 Apr 2016 02:43:42 -0400

On 4/11/2016 1:07 PM, Randell Jesup wrote:
> Similar issues can occur (or worse) coming off-mute.  In neither case 
> do you want a lot of delay and dropped frames trying to get "back to 
> speed" (or to get the slide you're talking about out, especially if 
> it's not a cut, but is a wipe - that would be horrible if the 
> send-rate decays like Stefan indicated).
>
> less reliable.  Similarly, a series of 
> smaller-than-available-bandwidth frames allows uncertainly to 
> increase, though not as much (you get a lower bound).

So on a spike (frame-change), we'll see a lot of traffic.  On the first, 
we'll adapt up, though unclear how far before it stops or drops to 
slow/small deltas.  Now uncertainty builds.  a) Physical conditions 
change (link quality, routing, wifi interference, etc) b) cross traffic 
may come - or go.  c) we're not using the bandwidth; other traffic may 
adapt up to take it.

We can a) maintain the last estimate if the actual value can't be known 
(haven't sent, or haven't filled the buckets due to small/slow delta 
frames), b) decay the estimate back down towards 0 (TCP-ish IIRC), or c) 
decay the estimate to a lesser extent, and cut/ramp in start-of-stream 
adjustments when we challenge the limits again.

I.e. if we were sending 4K frames (8Mbit?  12?) at 4Mbps, and then 
dropped to 1 5Kbit frame every second, then send another 4K frame 
(BIG).  We could send at 4Mbps (last estimate), start at the min rate we 
use (fully-decayed), or inbetween (some heuristic about max decay - 1/4 
or 1/3 or 1/2 last rate, perhaps).  Independently, we can (and perhaps 
should) turn on start-of-stream heuristics in cases like this (i.e. 
faster adaptation up (or down), un-learning various aspects (highest 
'good' rate, etc).

The answer might vary depending on the candidate algorithm, but my 
suggestion generally would be to cut to a 1/3 or 1/2 last-known, and do 
start-of-stream fast adaptation (perhaps even faster up to the 'old' 
limit - in a large class of applications, the limit either is a local 
link bottleneck at one end or the other, or it's hitting the max 
data-available rate (i.e. we didn't actually find a limit - think a lan, 
or a slideshare when on FiOS at both ends).   BTW, that might also speak 
to another variable to include when deciding what to do after 
uncertainty - if we never found a top limit before, perhaps don't decay 
(but still turn on fast adaptation).

Fun....

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 14 Apr 2016 11:18:56 +0200

Hi Randell, hi Ingemar,

there is also a TCP mechanism that keeps the window open for rate-limited traffic (e.g. video). Maybe it’s worth to have a look at it:

https://datatracker.ietf.org/doc/rfc7661/

Mirja

> Am 14.04.2016 um 08:43 schrieb Randell Jesup <[email-masked]>:
> 
>> The concern (as Stefan indicated) is the the lack of large traffic inbetween slides means the bitrate estimates may either a) decay, causing very slow sending of the large slide-changes as it tries to adapt up, or b) become out-of-date/too-high, which may lead to congestion/delay or loss when sending a large slide-change.
>> 
>> Similar issues can occur (or worse) coming off-mute.  In neither case do you want a lot of delay and dropped frames trying to get "back to speed" (or to get the slide you're talking about out, especially if it's not a cut, but is a wipe - that would be horrible if the send-rate decays like Stefan indicated).
>> 
>> Fundamentally, inbetween frames uncertainty about bitrate available increases.  Doesn't mean we have less, but our info becomes dated and less reliable.  Similarly, a series of smaller-than-available-bandwidth frames allows uncertainly to increase, though not as much (you get a lower bound).
> 
> So on a spike (frame-change), we'll see a lot of traffic.  On the first, we'll adapt up, though unclear how far before it stops or drops to slow/small deltas.  Now uncertainty builds.  a) Physical conditions change (link quality, routing, wifi interference, etc) b) cross traffic may come - or go.  c) we're not using the bandwidth; other traffic may adapt up to take it.
> 
> We can a) maintain the last estimate if the actual value can't be known (haven't sent, or haven't filled the buckets due to small/slow delta frames), b) decay the estimate back down towards 0 (TCP-ish IIRC), or c) decay the estimate to a lesser extent, and cut/ramp in start-of-stream adjustments when we challenge the limits again.  
> 
> I.e. if we were sending 4K frames (8Mbit?  12?) at 4Mbps, and then dropped to 1 5Kbit frame every second, then send another 4K frame (BIG).  We could send at 4Mbps (last estimate), start at the min rate we use (fully-decayed), or inbetween (some heuristic about max decay - 1/4 or 1/3 or 1/2 last rate, perhaps).  Independently, we can (and perhaps should) turn on start-of-stream heuristics in cases like this (i.e. faster adaptation up (or down), un-learning various     aspects (highest 'good' rate, etc).
> 
> The answer might vary depending on the candidate algorithm, but my suggestion generally would be to cut to a 1/3 or 1/2 last-known, and do start-of-stream fast adaptation (perhaps even faster up to the 'old' limit - in a large class of applications, the limit either is a local link bottleneck at one end or the other, or it's hitting the max data-available rate (i.e. we didn't actually find a limit - think a lan, or a slideshare when on FiOS at both ends).   BTW, that might also speak to another variable to include when deciding what to do after uncertainty - if we never found a top limit before, perhaps don't decay (but still turn on fast adaptation).
> 
> Fun.... 
> 
>> 
>> If I were designing the algorithms ;-), I'd include an uncertainty factor/state based on time since we tested/hit an upper limit (and something equivalent for lower).  When we don't send for a while, I'd assume the upper limit is more uncertain, but would *not* decay our estimate.  I would factor this into our reaction to delay or lack of delay when we do send - if we're uncertain, and then start pushing and see delay, I'd back off faster and further than if we'd been pretty certain of the current delay - much like at startup, which is another form of "uncertain" (especially if you base the initial bitrate on previous initial bitrates).
>> 
>> IMHO.  I think some of the requirements touch on these factors; certainly some along the process did.
> 
> -- 
> Please please please don't email 
> [email-masked]
> !  Way too much spam
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 14 Apr 2016 19:19:44 +0000

Hi Mirja + others
The congestion window validation in SCReAM is actually heavily inspired by RFC7661. The timing is shorter however.
Ingemar

Skickat från min iPhone

> 14 apr. 2016 kl. 11:18 skrev Mirja Kühlewind <[email-masked]>:
> 
> Hi Randell, hi Ingemar,
>