Subject: Re: [rmcat] Live slide show modeling

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 15 Jun 2016 03:14:51 +0000

Hi,

I would like to propose one default parameter change for the simple content sharing codec.

Currently the size of a large frame follows a uniform distribution between 40 and 500KB. As I understand this was based on the suggestions from this thread.

It might make sense to tune down the maximum frame size from 500KB to something like, say 200KB. My suggestion is based on the following observations of sample intra-coded frame sizes from the trace files of the two animation-type content shared via Syncodec:

* In Elephant Dreams, @1080p and target rate of 1.5Mbps, the first I frame is 22195 bytes (encoded with avg. QP=25 and resulting in frame PSNR=46.05 dB);

* In ​Big Buck Bunny @1080p and target rate of 1.5Mbps, the first I frame is 78754 bytes (encoded with avg. QP=31.13 and resulting in frame PSNR=37.89dB).

Note also that for sending a large burst frame of 200KB over a 1Mbps link (the typical bottleneck BW we've been testing so far for RMCAT), it will take at least 1.6 second to get through, and probably more (if the sender spaces out transmission of that frame to avoid congestion-induced losses over a not-so-deep queue).

Given all the above considerations, capping the burst frame size at 200KB seems less of an exaggeration than 500KB. ​​

Further thoughts and comments are welcome.

Thanks,

Xiaoqing

________________________________
From: rmcat <[email-masked]> on behalf of Sergio Mena de la Cruz (semena)
Sent: Tuesday, May 24, 2016 11:35 PM
To: Ingemar Johansson S; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [rmcat] Live slide show modeling

All,

We would like to announce to the list that we have implemented a new synthetic codec C++ class (SimpleContentSharingCodec), which follows the guidelines that Stefan and Ingemar described in this email thread.

You can find it in the latest version of our repo: https://github.com/cisco/syncodecs

Let me know if you have questions on how to use it.

Regards,

Sergio

On 07/04/16 14:43, Ingemar Johansson S wrote:
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]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[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]<mailto:[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:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
Sent: den 7 april 2016 10:27
To: Ingemar Johansson S; Randell Jesup ([email-masked]<mailto:[email-masked]>)
Cc: rmcat WG (<mailto:[email-masked]>[email-masked]<mailto:[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]<mailto:[email-masked]>> wrote:
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
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

           This report, by it´s very length,
 defends itself against the risk of being read
                       Winston Churchill
==================================

---

From: Sergio Mena <[email-masked]>
Date: Mon, 20 Jun 2016 10:36:58 +0200

Hello,

We just modified the default values for the simple content sharing codec in

https://github.com/cisco/syncodecs

The new default values reflect Xiaoqing's proposal to the list.

Thanks,

Sergio

On 15/06/16 05:14, Xiaoqing Zhu (xiaoqzhu) wrote:
> Currently the size of a large frame follows a uniform distribution 
> between 40 and 500KB. As I understand this was based on the 
> suggestions from this thread.
>
>
> It might make sense to tune down the maximum frame size from 500KB to 
> something like, say 200KB. My suggestion is based on the following 
> observations of sample intra-coded frame sizes from the trace files of 
> the two animation-type content shared via Syncodec:
>
>
> * In Elephant Dreams, @1080p and target rate of 1.5Mbps, the first I 
> frame is 22195 bytes (encoded with avg. QP=25 and resulting in frame 
> PSNR=46.05 dB);
>
> * In ​Big Buck Bunny @1080p and target rate of 1.5Mbps, the first I 
> frame is 78754 bytes (encoded with avg. QP=31.13 and resulting 
> in frame PSNR=37.89dB).
>
>
> Note also that for sending a large burst frame of 200KB over a 1Mbps 
> link (the typical bottleneck BW we've been testing so far for RMCAT), 
> it will take at least 1.6 second to get through, and probably more (if 
> the sender spaces out transmission of that frame to avoid 
> congestion-induced losses over a not-so-deep queue).
>
>
> Given all the above considerations, capping the burst frame size at 
> 200KB seems less of an exaggeration than 500KB. ​​
>
>
> ------------------------------------------------------------------------
> *From:* rmcat <[email-masked]> on behalf of Sergio Mena de la 
> Cruz (semena)
> *Sent:* Tuesday, May 24, 2016 11:35 PM
> *To:* Ingemar Johansson S; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [rmcat] Live slide show modeling
>
> All,
>
> We would like to announce to the list that we have implemented a new 
> synthetic codec C++ class (SimpleContentSharingCodec), which follows 
> the guidelines that Stefan and Ingemar described in this email thread.
>
>> 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.
>>
>> I also attached the frame size trace, realize that the 1^st 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] 
>> <mailto:[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]
>>     <mailto:[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]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi
>>
>>         [email-masked]
>>         <mailto:[email-masked]>
>>
>>         www.ericsson.com <http://www.ericsson.com>
>>