<br><br><div class="gmail_quote">On Sun, Apr 8, 2012 at 1:59 PM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> Justin replied:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I think we agree - to avoid the exact problems you mention, the plan<br>
has been to replace the SCTP CC module with a CC that is common across<br>
media and data.<br>
</blockquote>
<br>
Oh, cool! I wasn't aware of that - is that documented somewhere? Sorry<br>
if I missed it! I'm a bit new to the whole forest of RTCWEB documents...<br>
</blockquote>
<br>
If you read the early archives of this list (and discussions predating it on rtcweb), you'll find that goal articulated a number of times.<br>
</blockquote>
<br></div>
I think I have seen and heard about the wish to let the user prioritize flows, and somehow avoid that the flows would be totally ignorant about each other - but this is not the same as what I'm suggesting: a *single* congestion control instance for everything.<br>


<br>
Now I'm not sure if I get this right:<br>
1) Justin's statement above means that there is a plan to have one single SCTP CC module for everything in the "data channel", but there will still be different congestion control for RTP/UDP transfer => then this is not what I mean, you still won't get the same efficiency as if you use one CC instance for *everything*, by which I really mean *everything*.<br>


<br>
2) Justin's statement above means what I say here (one CC instance for *everything*) => then I have missed that and misunderstood the discussion, and just think it's good.</blockquote><div><br></div><div>#2 is what I think we've had in mind - given that this is fairly greenfield territory, we should be able to have a mechanism that can handle both media and data. Said mechanism will still have to guess at non-RTP/SCTP flows, of course.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As one of those driving the congestion-control issue and also the data channel design, I've always spoken to wanting to in some manner merge the congestion control regimes of media and data flows, and barring that to at least provide feedback between them.  The last fallback to avoiding problems would be to partially punt the problem up to the application (which also knows the relative priorities of the media and data, and of each data flow), by reporting back to the JS application the current automatic distribution of available bits to the different streams, and allow the application to change the distribution of those bits to the various media and data sub-flows (but not let it increase the total number of bits sent directly; it could decrease it directly or indirectly (by removing flows, such as dropping a video stream, etc)).<br>


<br>
We will very likely be doing that application-level reporting, and probably allowing the application to adjust the distribution. My proposal on the API for that is outstanding in the W3 side of this standardization effort.<br>


<br>
I spoke more directly to this at the rtcweb Interim meeting in Febuary; my slides are at:<br>
<a href="http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-1.pdf" target="_blank">http://www.ietf.org/<u></u>proceedings/interim/2012/01/<u></u>31/rtcweb/slides/rtcweb-1.pdf</a><br>
The relevant slides are 10-13.  While not stated on the slides, this discussion emanates from the goal to in some manner merge them or make them work together (and not fight), and this was I think re-iterated from the podium there.<br>


</blockquote>
<br></div>
I saw that presentation, but I had interpreted it as being only about the SCTP data channel, which would be case 1) above. Even if you extend that to incorporate other streams with cross-reporting as you describe above, it sounds like a complicated vehicle that will, I think, never be as efficient as simply having a single congestion control instance for everything.<br>


<br>
Cheers,<br>
Michael<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</div></div></blockquote></div><br>