Subject: [rmcat] Scenarios as input for new feedback format design

From: Stefan Holmer <[email-masked]>
Date: Tue, 23 Aug 2016 15:09:32 +0000

Hi,

As was requested in Berlin, here are a set of scenarios where we (Google)
are of interested in using the feedback format
<https://tools.ietf.org/html/draft-dt-rmcat-feedback-message-00>. It would
be great to analyze what would be needed to achieve this and discuss how we
can improve the current design to possibly accommodate these scenarios.

*Very low bitrate, audio only*
If a mobile connection becomes really bad for a period of time, we'd like
to be able to gracefully degrade to audio only at a low bitrate. This is an
extreme, but valid if the connection degrades to 2G for a while.
- Uplink: 20 kbps
- Downlink: 20 kbps
- Audio packet rate: 17 packets/second

*Low bitrate audio and video*
- Uplink: 70-100 kbps
- Downlink: 70-100 kbps
- Audio packet rate: 50 packets/second
- Video framerate: 7-15 fps

*ADSL conference, 10 small thumbnail streams, 1 main stream*
- Uplink: 500 kbps
    - Audio packet rate: 50 packets/second
    - Video framerate: 30 fps
- Downlink: 8000 kbps
    - Thumbnail streams: 15 x 7 fps
    - Main stream: 30 fps

/Stefan

---

From: Randell Jesup <[email-masked]>
Date: Tue, 23 Aug 2016 17:25:19 -0400

On 8/23/2016 11:09 AM, Stefan Holmer wrote:
> Hi,
>
> As was requested in Berlin, here are a set of scenarios where we 
> (Google) are of interested in using thefeedback format 
> <https://tools.ietf.org/html/draft-dt-rmcat-feedback-message-00>. It 
> would be great to analyze what would be needed to achieve this and 
> discuss how we can improve the current design to possibly accommodate 
> these scenarios.
>
> If a mobile connection becomes really bad for a period of time, we'd 
> like to be able to gracefully degrade to audio only at a low bitrate. 
> This is an extreme, but valid if the connection degrades to 2G for a 
> while.
> - Uplink: 20 kbps
> - Downlink: 20 kbps

These scenarios look good.  I'll add a few which may or may not be 
covered already:

* Audio-only, variable bandwidth (perhaps in place of the above)
- Uplink 16Kbps to 500Kbps (assumes 8Kbps codec @ 40ms with no SRTP auth 
tag (unencrypted or at least unauthenticated; encrypted would be ~18Kbps)
- Downlink 16Kbps to 500Kbps
- Audio packet rate: 26 to 110(?) (assumes max ptime of 40ms)

I include unencrypted  because this isn't just a webrtc spec. Bandwidth 
includes RTP/UDP/IP overhead.

* Screensharing (likely understood already)
- uplink 100Kbps to 10Mbps
- Downlink 70Kbps to 2Mbps
- Audio packet rate 50 packets/s (audio may be optional in some cases)
- Video framerate: <1fps to 30fps (variable, depending on content - may 
be regular or very bursty)
This is especially nasty as the output rate is VERY bursty in some 
low-fps cases, and even in high-fps cases the bitrate will still be very 
bursty (screen transitions or window changes, alternating with small 
changes or animations).  Lack of content means the algorithm can't 
maintain an estimate easily, and may need time to push others to give it 
a fair share.

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Aug 2016 16:54:33 +0100

Hi,

Thanks for sending this! Some questions below, to make sure I understand, and we end up with realistic scenarios to evaluate.

> On 23 Aug 2016, at 16:09, Stefan Holmer <[email-masked]> wrote:
> As was requested in Berlin, here are a set of scenarios where we (Google) are of interested in using the feedback format. It would be great to analyze what would be needed to achieve this and discuss how we can improve the current design to possibly accommodate these scenarios.
> 
> Very low bitrate, audio only
> If a mobile connection becomes really bad for a period of time, we'd like to be able to gracefully degrade to audio only at a low bitrate. This is an extreme, but valid if the connection degrades to 2G for a while.
> - Uplink: 20 kbps
> - Downlink: 20 kbps

This is presumably Opus at 8kbps with 60ms frames? 

RTP/UDP/IPv4 header of 12 + 8 + 20 = 40 octets, plus 60 octets per packet Opus payload when coding 60ms frames at 8kbps CBR, gives a bit rate of 13333bps with no RTP header extensions and no RTCP. 

With 8 octets per packet for an RTP header extension (e.g., a short mid tag), this is 14400bps. Are there any other header extensions used?

It’s also presumably SRTP, so is there any extra padding, authentication tags, etc?

> Low bitrate audio and video
> - Uplink: 70-100 kbps
> - Downlink: 70-100 kbps
> ADSL conference, 10 small thumbnail streams, 1 main stream
> - Uplink: 500 kbps

For the video streams, what’s a typical pattern of packets-per-frame and octets-per-packet for the codecs used in these scenarios (the 30fps stream is presumably not 30 identically sized RTP packets sent evenly spaced, for example)? 

If you have packet traces, that’d be very helpful. 

Also, if it’s easier, we can schedule a call to talk through the details, and I can summarise. 

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/