Re: [rmcat] WebRTC should ramp up faster

["Charles Eckel (eckelcu)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 17, 2013 12:59 PM
To: cowwoc <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

    I was directed to this mailing list from [e-mail]<mailto:[e-mail]>. 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