<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 10.8333px; border-collapse: collapse; "><div class="im" style="color: rgb(80, 0, 80); ">
On Tue, Jan 25, 2011 at 6:36 PM, Soo-Hyun Choi<span dir="ltr"><<a href="mailto:soohyun.choi@cl.cam.ac.uk" target="_blank" style="color: rgb(0, 0, 204); ">soohyun.choi@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
So, your first and second paper addressed issues around these problem,<br>respectively:<br><br>(1) limitations of the TCP equation used by TFRC<br></blockquote><div><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-size: 9.16667px; "></span></div>
</div></span></blockquote><div> </div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; border-collapse: collapse; ">we mathematically derive the dynamic rate-based equation corresponding to tcp </span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; border-collapse: collapse; "><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span class="Apple-style-span" style="font-family: arial, sans-serif; border-collapse: collapse; "><div class="im"><div style="color: rgb(80, 0, 80); "><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; color: rgb(80, 0, 80); ">
(2) limitations of being rate-based</blockquote></div></span></blockquote><div><br></div><div> <span class="Apple-style-span" style="font-family: arial, sans-serif; border-collapse: collapse; ">we show how is possible to implement rate-based</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 7.5px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 7.5px; border-collapse: collapse; ">sm</span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This was one of my motivations to develop TFWC (a window-based CC, but<br>
still useful for the real-time video streaming applications) -<br>
<div class="im"><a href="http://tfwc.hackerslab.eu/" target="_blank">http://tfwc.hackerslab.eu/</a>.<br>
<br>
Any comments?<br>
<br>
Cheers,<br>
Soo-Hyun<br>
<br>
<br>
<br>
</div><div class="im">On 1/26/11 2:21 AM, Saverio Mascolo wrote:<br>
> to complete my previous msg, here it is a paper<br>
><br>
> <a href="http://c3lab.poliba.it/images/8/88/ACM04.pdf" target="_blank">http://c3lab.poliba.it/images/8/88/ACM04.pdf</a><br>
><br>
> that describes "a rate based control" that is the**_*real *_rate-based<br>
> counterpart of TCP window based control.<br>
><br>
> It is real because it is a dynamic equation and not a steady state<br>
> equation as TFRC. As a consequence, it responds in real-time respond to<br>
> network conditions, as it does TCP, but in real-time.<br>
><br>
> As any algorithm that computes a rate, it should be implemented using a<br>
> "rate mismatch controller"<br>
><br>
> <a href="http://c3lab.poliba.it/images/d/d9/Icnp09.pdf" target="_blank">http://c3lab.poliba.it/images/d/d9/Icnp09.pdf</a><br>
><br>
> Any comment is very welcome!<br>
><br>
> Thanks for the attention and best regards,<br>
><br>
> saverio<br>
><br>
><br>
> On Tue, Jan 25, 2011 at 4:49 PM, Rosenberg, Jonathan<br>
</div><div class="im">> <<a href="mailto:jonathan.rosenberg@skype.net">jonathan.rosenberg@skype.net</a> <mailto:<a href="mailto:jonathan.rosenberg@skype.net">jonathan.rosenberg@skype.net</a>>> wrote:<br>
><br>
> No debate here. The model I like is that there is something built-in<br>
> to the browser (say, TFRC or some variant), but the hooks are<br>
> available to allow an application to customize it.<br>
><br>
><br>
><br>
> -Jonathan R.<br>
><br>
><br>
><br>
> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen<br>
><br>
> Chief Technology Strategist Mobile: +1 (732) 766-2496<br>
><br>
> Skype SkypeIn: +1 (408) 465-0361<br>
><br>
</div>> <a href="mailto:jdrosen@skype.net">jdrosen@skype.net</a> <mailto:<a href="mailto:jdrosen@skype.net">jdrosen@skype.net</a>><br>
<div class="im">> <a href="http://www.skype.com" target="_blank">http://www.skype.com</a><br>
><br>
> <a href="mailto:jdrosen@jdrosen.net">jdrosen@jdrosen.net</a><br>
</div>> <mailto:<a href="mailto:jdrosen@jdrosen.net">jdrosen@jdrosen.net</a>><br>
<div class="im">> <a href="http://www.jdrosen.net" target="_blank">http://www.jdrosen.net</a><br>
><br>
><br>
><br>
> *From:*Matthew Kaufman [mailto:<a href="mailto:matthew.kaufman@skype.net">matthew.kaufman@skype.net</a><br>
> <mailto:<a href="mailto:matthew.kaufman@skype.net">matthew.kaufman@skype.net</a>>]<br>
> *Sent:* Tuesday, January 25, 2011 7:47 AM<br>
> *To:* Rosenberg, Jonathan<br>
> *Cc:* 'Saverio Mascolo'; 'Stefan Håkansson LK'; 'Cullen Jennings';<br>
</div>> <a href="mailto:tom_harper@logitech.com">tom_harper@logitech.com</a> <mailto:<a href="mailto:tom_harper@logitech.com">tom_harper@logitech.com</a>>; 'Justin<br>
<div class="im">> Uberti'; 'Harald Alvestrand'; <a href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</a><br>
</div>> <mailto:<a href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</a>>; 'Peter Musgrave'<br>
<div><div></div><div class="h5">><br>
> *Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch]<br>
> The charter formerly know as RTC-WEB take 3)<br>
><br>
><br>
><br>
> Agreed, but for the purpose of this discussion I believe that rate<br>
> control of some sort should also be a MUST.<br>
><br>
><br>
><br>
> Web browsers are extremely prevalent, and we hope that RTC use in<br>
> browsers will be high, and so it would be good for the Internet for<br>
> browsers to have sending rate control. Note that this is at the<br>
> protocol level... so send rate must be controlled whether the codec<br>
> can have its rate adjusted downward so as to not require the<br>
> protocol level to enforce or not.<br>
><br>
> For interoperability, it is also required that the feedback<br>
> mechanism from one end to the other be standardized, even if the way<br>
> that feedback is used to control send rate and/or codec selection or<br>
> codec rate selection is proprietary and/or extensions to the<br>
> feedback are also sent for endpoints that understand the (possibly<br>
> proprietary) extension(s).<br>
><br>
> Matthew Kaufman<br>
><br>
> On 1/25/2011 7:38 AM, Rosenberg, Jonathan wrote:<br>
><br>
> It’s a proprietary algorithm of our own design, supported by some<br>
> protocols which exchange feedback in real-time between endpoints.<br>
> We’re constantly tweaking it based on user feedback and technical<br>
> statistics we collect.<br>
><br>
><br>
><br>
> Indeed – as many folks are aware, rate adaptation has always been an<br>
> area of innovation and differentiation. RTP has provided the tools<br>
> for feedback but has allowed implementations to do whatever they<br>
> want. I think it is important that this continues to be the case in<br>
> the web world – that folks designing RTC applications can innovate<br>
> and define their own versions of these algorithms.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Jonathan R.<br>
><br>
><br>
><br>
> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen<br>
><br>
> Chief Technology Strategist Mobile: +1 (732) 766-2496<br>
><br>
> Skype SkypeIn: +1 (408) 465-0361<br>
><br>
</div></div>> <a href="mailto:jdrosen@skype.net">jdrosen@skype.net</a> <mailto:<a href="mailto:jdrosen@skype.net">jdrosen@skype.net</a>><br>
<div class="im">> <a href="http://www.skype.com" target="_blank">http://www.skype.com</a><br>
><br>
> <a href="mailto:jdrosen@jdrosen.net">jdrosen@jdrosen.net</a><br>
</div>> <mailto:<a href="mailto:jdrosen@jdrosen.net">jdrosen@jdrosen.net</a>><br>
<div class="im">> <a href="http://www.jdrosen.net" target="_blank">http://www.jdrosen.net</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Prof. Saverio Mascolo<br>
> Dipartimento di Elettrotecnica ed Elettronica<br>
> Politecnico di Bari<br>
> Via Orabona 4, 70125 Bari Italy<br>
> Tel. +39 080 5963621<br>
> Fax. +39 080 5963410<br>
</div>> <a href="mailto:email%3Amascolo@poliba.it">email:mascolo@poliba.it</a> <mailto:<a href="mailto:email%253Amascolo@poliba.it">email%3Amascolo@poliba.it</a>><br>
<div class="im">><br>
> <a href="http://c3lab.poliba.it" target="_blank">http://c3lab.poliba.it</a><br>
><br>
><br>
> =================================<br>
> This message may contain confidential and/or legally privileged<br>
> information.<br>
> If you are not the intended recipient of the message, please destroy it.<br>
> Any unauthorized dissemination, distribution, or copying of the material in<br>
> this message, and any attachments to the message, is strictly forbidden.<br>
><br>
><br>
><br>
</div><div><div></div><div class="h5">> _______________________________________________<br>
> RTC-Web mailing list<br>
> <a href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
> <a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Prof. Saverio Mascolo<br>Dipartimento di Elettrotecnica ed Elettronica<br>Politecnico di Bari<br>Via Orabona 4, 70125 Bari Italy<br>Tel. +39 080 5963621<br>Fax. +39 080 5963410<br>
<a href="mailto:email%3Amascolo@poliba.it">email:mascolo@poliba.it</a><br> <br><a href="http://c3lab.poliba.it">http://c3lab.poliba.it</a><br><br><br>=================================<br> This message may contain confidential and/or legally privileged information.<br>
If you are not the intended recipient of the message, please destroy it.<br> Any unauthorized dissemination, distribution, or copying of the material in<br> this message, and any attachments to the message, is strictly forbidden.<br>