[e2e] Reasons not to deply TCP BIC/Cubic
neil.davies at pnsol.com
Wed Nov 30 06:43:07 PST 2011
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
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.
More information about the end2end-interest