[e2e] Reasons not to deply TCP BIC/Cubic

[Neil Davies]

Saverio

Do you have an idea of the sensitivity of the implementation to burst  
loss? Is this something that you captured/measured? Is this a  
condition that this implementation of TCP exacerbates?

The reason I ask this is that we have experience of measuring large  
scale networks in some detail (down to the contribution to the loss  
and delay at different components in the system) and we are observing  
that there burst loss is occurring - under some circumstances the loss  
can be a complete window size (which then appears to cause the sender  
to wait for a timeout).

I could understand that more aggression would lead to greater RTT (and  
greater RTT leads to longer recover times from certain events) - it is  
filling the critical bottleneck with more packets, hence more delay.

Although TCP BIC/Cubic may appear neutral when measuring throughput -  
is it neutral when that TCP session is being used for other purposes  
other than simple bulk data transfer? (e.g. a block transfer of video  
content)

Cheers

Neil
On 30 Nov 2011, at 11:10, mascolo at poliba.it 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.
>