Subject: [rmcat] WebRTC should ramp up faster

From: cowwoc <[email-masked]>
Date: Tue, 17 Sep 2013 15:28:57 -0400

Hi,

     I was directed to this mailing list from [email-masked]. I 
would like to bring a high-level issue to your attention in the hopes of 
discussing possible solutions on this list.

     Chrome's implementation of WebRTC takes 1-5 minutes to ramp up to 
1080p 30fps. The reason given was the need to avoid network congestion. 
I think it is safe to say that we can ramp up faster without risking 
network congestion, but in order to do this we will need to get a little 
bit more concrete.

     My goal is for WebRTC to ramp up to 1080p within 3-10 seconds. I'm 
unable to champion the actual technical details but I wanted to bring 
this to your attention so whoever is technically knowledgeable in this 
area can then discuss it on the list and evaluate possible solutions.

     On a side-note, this topic falls under the Requirement #10 found at 
http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/?include_text=1

     Where do we go from here?

Thank you,
Gili

---

From: Dan Weber <[email-masked]>
Date: Tue, 17 Sep 2013 13:59:28 -0600

HI Gili,

I can attest that the HD experience in Chrome is quite poor, and that there
are issues with ramp up, plus other lipsync and latency issues.  For
instance, in libjingle, they're pulling in video frames in YUV rather than
in MJPEG which yields much lower frame rate performance from most cameras,
and causes lots of lag as the data has to go across the CPU with each
interrupt.  And I digress.

To answer your question, this group exists to find an effective congestion
control algorithm.  Many people actively participating on this list have
their own implementations which they're proposing for standardization.  All
the solutions I have read about seek to provide faster responsiveness than
what is currently in Chrome.  However, much more work needs to be completed
on this to find an effective solution that works well across the board.

We're always interested in finding effective ways of solving these
problems, and I'm sure many of us will be at IETF 88 in Vancouver.  Feel
free to join us for the working group meetings we schedule.

Thanks,
Dan

On Tue, Sep 17, 2013 at 1:28 PM, cowwoc <[email-masked]> wrote:

> 1080p 30fps. The reason given was the need to avoid network congestion. I
> think it is safe to say that we can ramp up faster without risking network
> congestion, but in order to do this we will need to get a little bit more
> concrete.
>
> unable to champion the actual technical details but I wanted to bring this
> to your attention so whoever is technically knowledgeable in this area can
> then discuss it on the list and evaluate possible solutions.
>
> http://datatracker.ietf.org/**doc/draft-ietf-rmcat-cc-**
> requirements/?include_text=1<http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/?include_text=1>
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 30 Sep 2013 13:00:16 +0000

This is one of the use cases we envisioned when we submitted draft-eckert-intarea-flow-metadata-framework (http://tools.ietf.org/id/draft-eckert-intarea-flow-metadata-framework-01.txt). In particular, the advisory model described in section 3.1.3.2 could help with this. For example, an application could indicate the media flows it plans to initiate, and the desired bandwidth for each. The network could signal back the bandwidth the application is likely to be granted. This exchange between the application and the network could help the application do a better job determining an appropriate starting bandwidth, as well as provide additional information as the application tries to ramp up its bandwidth usage.

Please have a look and share your thoughts. For the time being, the intarea group is where we have submitted the draft, so that is likely the most appropriate list for your comments. You may also want to have a look at the associated drafts describing how the concepts described in the framework could be mapped to STUN (http://tools.ietf.org/id/draft-martinsen-mmusic-malice-00.txt) and PCP (http://tools.ietf.org/id/draft-wing-pcp-flowdata-00.txt) as potential transport protocols.

Cheers,
Charles

From: Dan Weber <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 17, 2013 12:59 PM
To: cowwoc <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rmcat] WebRTC should ramp up faster

HI Gili,

I can attest that the HD experience in Chrome is quite poor, and that there are issues with ramp up, plus other lipsync and latency issues.  For instance, in libjingle, they're pulling in video frames in YUV rather than in MJPEG which yields much lower frame rate performance from most cameras, and causes lots of lag as the data has to go across the CPU with each interrupt.  And I digress.

To answer your question, this group exists to find an effective congestion control algorithm.  Many people actively participating on this list have their own implementations which they're proposing for standardization.  All the solutions I have read about seek to provide faster responsiveness than what is currently in Chrome.  However, much more work needs to be completed on this to find an effective solution that works well across the board.

We're always interested in finding effective ways of solving these problems, and I'm sure many of us will be at IETF 88 in Vancouver.  Feel free to join us for the working group meetings we schedule.

Thanks,
Dan

On Tue, Sep 17, 2013 at 1:28 PM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

    I was directed to this mailing list from [email-masked]<mailto:[email-masked]>. I would like to bring a high-level issue to your attention in the hopes of discussing possible solutions on this list.

    Chrome's implementation of WebRTC takes 1-5 minutes to ramp up to 1080p 30fps. The reason given was the need to avoid network congestion. I think it is safe to say that we can ramp up faster without risking network congestion, but in order to do this we will need to get a little bit more concrete.

    My goal is for WebRTC to ramp up to 1080p within 3-10 seconds. I'm unable to champion the actual technical details but I wanted to bring this to your attention so whoever is technically knowledgeable in this area can then discuss it on the list and evaluate possible solutions.

    On a side-note, this topic falls under the Requirement #10 found at http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/?include_text=1

Thank you,
Gili