[R-C] Simplifying the TCP throughput algorithm

[Michael Welzl]

Hi,

I think that the idea of saying standard TCP as a lower limit is a  
better basis than using CUBIC for that... if you want to be more  
aggressive, you can also just take our equation which mimics a number  
of TCPs. This seems to be a more appropriate basis than an  
experimental mechanism.

Further, I agree with Colin - p is a loss event rate, not a packet  
loss rate. That difference can be significant, and it was probably the  
reason why someone asked whether the losses were random. This is also  
the reason why you don't get the throughput of 10 TCPs by multiplying  
that equation by 10, and why we had to make a new formula for that.  
Figure 2 of our IEEE/ACM ToN paper shows that difference, see:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1

If you have trouble accessing that, a similar figure is also in  
Dragana's Ph.D. thesis, which is a much larger pdf:
http://heim.ifi.uio.no/~michawe/research/projects/multfrc/dragana_thesis.pdf
- figure 3.18 on page 65. That thesis also has a deeper investigation  
of the impact of clustered vs. random losses.

I agree with the simplification of using the packet loss ratio for p  
in the circuit breaker - there, I think it's reasonable, but only there.

BTW, Harald - have you derived a variant of the simpler TCP equation  
that was once derived by a fellow Googler?!  :-)
http://www.psc.edu/networking/papers/model_ccr97.ps

Cheers,
Michael


On Mar 29, 2012, at 1:26 PM, Luca De Cicco wrote:

> That formula was derived for TCP NewReno so it's not working  
> properly for
> TCP Cubic for instance :). That's why I am not a fan of the TFRC  
> approach.
>
> Cheers,
> Luca
>
> On Thu, Mar 29, 2012 at 1:22 PM, Colin Perkins <csp at csperkins.org>  
> wrote:
>> On 29 Mar 2012, at 13:19, Harald Alvestrand wrote:
>>> On 03/29/2012 01:07 PM, Ali C. Begen (abegen) wrote:
>>>> I suppose these were random losses?
>>> This is just putting numbers into the TCP throughput algorithm  
>>> from the TCP-Friendly RFC using its parameter p, and trying to see  
>>> what the implications of the result are.
>>>
>>> I presume that p was assumed to be random in the derivation of the  
>>> formula.
>>
>> It's a loss event rate. The equation gives a conservative value for  
>> the throughput if the loss is bursty.
>>
>> Colin
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion