Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
From: [email-masked] (Yuchung Cheng)
Date: Wed Nov 30 21:56:26 2011

It would be nice to see real-world large-scale measurements in addition to
modelings. AFAIK, most short Web transactions finish within slow-start, and
video transfers over TCP often implement user-level rate limiting.

Any good technical papers people recommend?

On Wed, Nov 30, 2011 at 1:31 PM, Murari Sridharan <[email-masked]>wrote:

> NIST did a very comprehensive study along these lines comparing and
> documenting different congestion algorithms.
> http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm
>
> Thanks
> Murari
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of sannikov
> Sent: Wednesday, November 30, 2011 6:56 AM
> To: Saverio Mascolo
> Cc: iccrg; end2end-interest
> Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
>
> Hello.
>
> I'm not so familiar with CUBIC, but it is really aggressive.
> And as far as I know Linux implementation is little bit differ from the
> original.
> Did have original version same problems?
>
> --
> With best regards, Alexander Sannikov.
>
> On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <
> [email-masked]> wrote:
> > yes!
> >
> > On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
> >  This should really go to ICCRG, I'd say (added to recipients). May I
> ask
> > to continue this (interesting!) discussion there?
> >
> >  On 11/30/11 12:10 PM, [email-masked] [2] wrote:
> >   Dear all,
> >
> >  we know that TCP BIC/Cubic is default in Linux and as a consequence
> > 50% of servers employs TCP BIC/Cubic.
> >
> >  Our measurements say that there could be reasons not to deploy TCP
> > BIC/Cubic. These reasons  are in our opinion rooted in its more
> > aggressive probing phase. In particular, in common network conditions,
> > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
> TCP
> > Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
> TCP
> > Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or
> > Westwood+.
> >
> >  In other terms, it seems that its more aggressive probing increases
> both
> > throughput and retransmissions but leaving unchanged the goodput. This
> is
> >  neutral for the users but negative for the network.
> >
> >  I appreciate your views.
> >
> >  Thanks for the attention and best regards,
> >
> >  Saverio Mascolo
> >
> >  ----------------------------------------------------------------
> >  This message was sent using IMP, the Internet Messaging Program.
> >
> >  _______________________________________________
> >  Iccrg mailing list
> >  [email-masked] [3]
> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111130/0cc0d1c4/attachment.html
>From [email-masked]  Wed Nov 30 23:11:15 2011
From: [email-masked] (Luca De Cicco)
Date: Wed Nov 30 23:07:20 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <CAK6E8=[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

Vedi per esempio questo parla di video transfer.

Luca

On Wed, Nov 30, 2011 at 11:00 PM, Yuchung Cheng <[email-masked]> wrote:

> It would be nice to see real-world large-scale measurements in addition to
> modelings. AFAIK, most short Web transactions finish within slow-start, and
> video transfers over TCP often implement user-level rate limiting.
>
> Any good technical papers people recommend?
>
> On Wed, Nov 30, 2011 at 1:31 PM, Murari Sridharan <[email-masked]>wrote:
>
>> NIST did a very comprehensive study along these lines comparing and
>> documenting different congestion algorithms.
>> http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm
>>
>> Thanks
>> Murari
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of sannikov
>> Sent: Wednesday, November 30, 2011 6:56 AM
>> To: Saverio Mascolo
>> Cc: iccrg; end2end-interest
>> Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
>>
>> Hello.
>>
>> I'm not so familiar with CUBIC, but it is really aggressive.
>> And as far as I know Linux implementation is little bit differ from the
>> original.
>> Did have original version same problems?
>>
>> --
>> With best regards, Alexander Sannikov.
>>
>> On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <
>> [email-masked]> wrote:
>> > yes!
>> >
>> > On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
>> >  This should really go to ICCRG, I'd say (added to recipients). May I
>> ask
>> > to continue this (interesting!) discussion there?
>> >
>> >  On 11/30/11 12:10 PM, [email-masked] [2] wrote:
>> >   Dear all,
>> >
>> >  we know that TCP BIC/Cubic is default in Linux and as a consequence
>> > 50% of servers employs TCP BIC/Cubic.
>> >
>> >  Our measurements say that there could be reasons not to deploy TCP
>> > BIC/Cubic. These reasons  are in our opinion rooted in its more
>> > aggressive probing phase. In particular, in common network conditions,
>> > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
>> TCP
>> > Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
>> TCP
>> > Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or
>> > Westwood+.
>> >
>> >  In other terms, it seems that its more aggressive probing increases
>> both
>> > throughput and retransmissions but leaving unchanged the goodput. This
>> is
>> >  neutral for the users but negative for the network.
>> >
>> >  I appreciate your views.
>> >
>> >  Thanks for the attention and best regards,
>> >
>> >  Saverio Mascolo
>> >
>> >  ----------------------------------------------------------------
>> >  This message was sent using IMP, the Internet Messaging Program.
>> >
>> >  _______________________________________________
>> >  Iccrg mailing list
>> >  [email-masked] [3]
>> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111201/3eb81894/attachment-0001.html
>From [email-masked]  Wed Nov 30 23:12:04 2011
From: [email-masked] (Luca De Cicco)
Date: Wed Nov 30 23:08:17 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<CAK6E8=[email-masked]>
	<[email-masked]>
Message-ID: <CACHLvecCja6AxM9KiNG9Aa30HNvQT-j=[email-masked]>

Sorry please disregard the previous message.

LDC

On Thu, Dec 1, 2011 at 12:11 AM, Luca De Cicco <[email-masked]> wrote:

> Vedi per esempio questo parla di video transfer.
>
> Luca
>
>
> On Wed, Nov 30, 2011 at 11:00 PM, Yuchung Cheng <[email-masked]> wrote:
>
>> It would be nice to see real-world large-scale measurements in addition
>> to modelings. AFAIK, most short Web transactions finish within slow-start,
>> and video transfers over TCP often implement user-level rate limiting.
>>
>> Any good technical papers people recommend?
>>
>> On Wed, Nov 30, 2011 at 1:31 PM, Murari Sridharan <[email-masked]>wrote:
>>
>>> NIST did a very comprehensive study along these lines comparing and
>>> documenting different congestion algorithms.
>>> http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm
>>>
>>> Thanks
>>> Murari
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of sannikov
>>> Sent: Wednesday, November 30, 2011 6:56 AM
>>> To: Saverio Mascolo
>>> Cc: iccrg; end2end-interest
>>> Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
>>>
>>> Hello.
>>>
>>> I'm not so familiar with CUBIC, but it is really aggressive.
>>> And as far as I know Linux implementation is little bit differ from the
>>> original.
>>> Did have original version same problems?
>>>
>>> --
>>> With best regards, Alexander Sannikov.
>>>
>>> On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <
>>> [email-masked]> wrote:
>>> > yes!
>>> >
>>> > On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
>>> >  This should really go to ICCRG, I'd say (added to recipients). May I
>>> ask
>>> > to continue this (interesting!) discussion there?
>>> >
>>> >  On 11/30/11 12:10 PM, [email-masked] [2] wrote:
>>> >   Dear all,
>>> >
>>> >  we know that TCP BIC/Cubic is default in Linux and as a consequence
>>> > 50% of servers employs TCP BIC/Cubic.
>>> >
>>> >  Our measurements say that there could be reasons not to deploy TCP
>>> > BIC/Cubic. These reasons  are in our opinion rooted in its more
>>> > aggressive probing phase. In particular, in common network conditions,
>>> > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
>>> TCP
>>> > Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
>>> TCP
>>> > Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or
>>> > Westwood+.
>>> >
>>> >  In other terms, it seems that its more aggressive probing increases
>>> both
>>> > throughput and retransmissions but leaving unchanged the goodput. This
>>> is
>>> >  neutral for the users but negative for the network.
>>> >
>>> >  I appreciate your views.
>>> >
>>> >  Thanks for the attention and best regards,
>>> >
>>> >  Saverio Mascolo
>>> >
>>> >  ----------------------------------------------------------------
>>> >  This message was sent using IMP, the Internet Messaging Program.
>>> >
>>> >  _______________________________________________
>>> >  Iccrg mailing list
>>> >  [email-masked] [3]
>>> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>
>>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111201/a656b099/attachment.html

From: [email-masked] (Murari Sridharan)
Date: Wed Nov 30 21:28:29 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

NIST did a very comprehensive study along these lines comparing and documenting different congestion algorithms. 
http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm

Thanks
Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of sannikov
Sent: Wednesday, November 30, 2011 6:56 AM
To: Saverio Mascolo
Cc: iccrg; end2end-interest
Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic

Hello. 

I'm not so familiar with CUBIC, but it is really aggressive.
And as far as I know Linux implementation is little bit differ from the original.
Did have original version same problems?

--
With best regards, Alexander Sannikov.

On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <[email-masked]> wrote:
> yes!
> 
> On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
>  This should really go to ICCRG, I'd say (added to recipients). May I
ask
> to continue this (interesting!) discussion there?
> 
>  On 11/30/11 12:10 PM, [email-masked] [2] wrote:
>   Dear all,
> 
>  we know that TCP BIC/Cubic is default in Linux and as a consequence 
> 50% of servers employs TCP BIC/Cubic.
> 
>  Our measurements say that there could be reasons not to deploy TCP 
> BIC/Cubic. These reasons ?are in our opinion rooted in its more 
> aggressive probing phase. In particular, in common network conditions, 
> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
TCP
> Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
TCP
> Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or 
> Westwood+.
> 
>  In other terms, it seems that its more aggressive probing increases
both
> throughput and retransmissions but leaving unchanged the goodput. This
is
> ?neutral for the users but negative for the network.
> 
>  I appreciate your views.
> 
>  Thanks for the attention and best regards,
> 
>  Saverio Mascolo
> 
>  ----------------------------------------------------------------
>  This message was sent using IMP, the Internet Messaging Program.
> 
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked] [3]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Saverio Mascolo)
Date: Wed Nov 30 12:04:30 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

yes!

On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl <[email-masked]> wrote:

> This should really go to ICCRG, I'd say (added to recipients). May I ask
> to continue this (interesting!) discussion there?
>
>
>
> On 11/30/11 12:10 PM, [email-masked] wrote:
>
>> Dear all,
>>
>> we know that TCP BIC/Cubic is default in Linux and as a consequence 50%
>> of servers employs TCP BIC/Cubic.
>>
>> Our measurements say that there could be reasons not to deploy TCP
>> BIC/Cubic. These reasons  are in our opinion rooted in its more aggressive
>> probing phase. In particular, in common network conditions, TCP BIC/CUBIC
>> exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a
>> larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3
>> larger throughput but same goodput wrt to TCP NewReno or Westwood+.
>>
>> In other terms, it seems that its more aggressive probing increases both
>> throughput and retransmissions but leaving unchanged the goodput. This is
>>  neutral for the users but negative for the network.
>>
>> I appreciate your views.
>>
>> Thanks for the attention and best regards,
>>
>> Saverio Mascolo
>>
>> ------------------------------**------------------------------**----
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>
> ______________________________**_________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/**mailman/listinfo/iccrg<http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked]

http://c3lab.poliba.it

=================================
 This message may contain confidential and/or legally privileged
information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111130/9cb54f23/attachment.html
>From [email-masked]  Wed Nov 30 14:55:59 2011
From: [email-masked] (sannikov)
Date: Wed Nov 30 14:53:03 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hello. 

I'm not so familiar with CUBIC, but it is really aggressive.
And as far as I know Linux implementation is little bit differ from the
original.
Did have original version same problems?

--
With best regards, Alexander Sannikov.

On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo
<[email-masked]> wrote:
> yes!
> 
> On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
>  This should really go to ICCRG, I'd say (added to recipients). May I
ask
> to continue this (interesting!) discussion there?
> 
>  On 11/30/11 12:10 PM, [email-masked] [2] wrote:
>   Dear all,
> 
>  we know that TCP BIC/Cubic is default in Linux and as a consequence 50%
> of servers employs TCP BIC/Cubic.
> 
>  Our measurements say that there could be reasons not to deploy TCP
> BIC/Cubic. These reasons ?are in our opinion rooted in its more
> aggressive probing phase. In particular, in common network conditions,
> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
TCP
> Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
TCP
> Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or
> Westwood+.
> 
>  In other terms, it seems that its more aggressive probing increases
both
> throughput and retransmissions but leaving unchanged the goodput. This
is
> ?neutral for the users but negative for the network.
> 
>  I appreciate your views.
> 
>  Thanks for the attention and best regards,
> 
>  Saverio Mascolo
> 
>  ----------------------------------------------------------------
>  This message was sent using IMP, the Internet Messaging Program.
> 
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked] [3]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]

From: [email-masked] (Michael Welzl)
Date: Wed Nov 30 11:52:57 2011
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This should really go to ICCRG, I'd say (added to recipients). May I ask 
to continue this (interesting!) discussion there?

On 11/30/11 12:10 PM, [email-masked] wrote:
> Dear all,
>
> we know that TCP BIC/Cubic is default in Linux and as a consequence 
> 50% of servers employs TCP BIC/Cubic.
>
> Our measurements say that there could be reasons not to deploy TCP 
> BIC/Cubic. These reasons  are in our opinion rooted in its more 
> aggressive probing phase. In particular, in common network conditions, 
> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or 
> TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno 
> or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP 
> NewReno or Westwood+.
>
> In other terms, it seems that its more aggressive probing increases 
> both throughput and retransmissions but leaving unchanged the goodput. 
> This is  neutral for the users but negative for the network.
>
> I appreciate your views.
>
> Thanks for the attention and best regards,
>
> Saverio Mascolo
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>

From: [email-masked] (Lars Eggert)
Date: Tue Nov  1 14:35:24 2011
Subject: [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
Message-ID: <[email-masked]>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111101/43a1b585/smime.bin
>From [email-masked]  Mon Nov  7 01:58:45 2011
From: [email-masked] (Wesley Eddy)
Date: Mon Nov  7 01:58:05 2011
Subject: [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google 
	Congestion Control Algorithm for Real-Time Communication on the World 
	Wide Web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 11/1/2011 10:34 AM, Lars Eggert wrote:
> This may be of interest to the RG:
> http://wiki.tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01
>

Here are my comments on this (also copied to the authors and the
mailing list for RTCWEB congestion control):

(1)
I think the model tries to correct for some effects later, but this
part only makes sense if all frames are the same size, and none of
the timestamps are subject to jitter being introduced by OS scheduling,
MAC layer (e.g. wireless) issues, etc:
"""
    We define the (relative) inter-arrival time, d(i) as

      d(i) = t(i)-t(i-1)-(T(i)-T(i-1))
"""

(2)

This part doesn't quite make sense to me, but I think it's just in
the wording and not in the math:
"""
    Since the time ts to send a frame of size L over a path with a
    capacity of C is

      ts = L/C

    we can model the inter-arrival time as

               L(i)-L(i-1)
      d(i) = -------------- + w(i) = dL(i)/C+w(i)
                   C
"""
That's not a model of the inter-arrival time, it's a model of the
difference between the delta timestamps and delta reception times
based on difference in packet length.

(3)
In the definition of w(i), do you also intend to account for other
sources of delays in the end systems' software?  Why do we think that
white noise is the right model?  This seems like a big assumption,
unless there's actually data that shows it holds under a very wide
range of settings.

(4)
It should probably be understood clearly that the i values are sample
numbers, but that the generation of samples comes from the behavior of
the plant, and they aren't taken at the filter/controller regularly.
This seems to be quite different than when the document says:
"""
    In this document we make the assumption that the rate control
    subsystem is executed periodically and that this period is constant.
"""

(5)
The algorithm at the receiver side is clueless about packet losses,
and seems like it would see them only when the loss period ends (when
a packet survives) and then would see them as really long inter-arrival
times rather than losses?  (or did I miss something really important?)

(6)
The rules about 2% and 10% in the sender-side algorithm seem ... odd.
Unless the report interval is sufficiently long in relation to the frame
rate, the percentages may not work well.  These parameters have to be
balanced, or the algorithm will be fragile.

(7)
Shouldn't the sender estimate of available bandwidth be able to go lower
than the TFRC equation output if the delay has been increasing (though
packets are not yet being lost)?

(8)
Startup is a big topic that isn't yet addressed.

-- 
Wes Eddy
MTI Systems