[e2e] TCP Cubic

[Yan Cai]

A few thoughts on comparison between TCP Cubic and Newreno.

1. Newreno like TCP is additive increase and multiplicative decrease 
(AIMD) while Cubic is one of MIMD TCP's.

2. To me, the most significant reason for adopting an MIMD TCP is due to 
the incapability of AIMD TCP's grabbing bandwidth in a large 
bandwidth-delay link: AIMD TCP takes very long time to make the pipe 
"congested."

3. Goodput/throughput vs link utilization.
Goodput/throughput can be used to characterize both a TCP session and a 
bottleneck link while link utilization is mainly for the bottleneck 
link. However, both of them are heavily impacted by the buffer size at 
the bottleneck link. In the case of TCP newreno, the rule of thumb, that 
is, buffer size = RTT * bandwidth, has been proven to provide a 100% 
link utilization for the bottleneck link while achieving the smallest 
average RTT for the TCP session. A bigger buffer leads to larger RTTs 
(overbuffer) while a smaller one makes the link utilization lower than 
100% (underbuffer).

It seems that the (MIMD) TCP performance is not only determined by the 
congestion avoidance algorithm, but also affected by the network 
topology and parameters. A detailed description on the experiment setup 
will help understand the experimental results better.

Many thanks,
Yan

On 12/4/2011 1:22 PM, Daniel Havey wrote:
> This is interesting.  Could you please elaborate on why you think your experiments show these results?
>
> 1. a larger RTT?
> Why?  Because of queuing?  It doesn't seem like queuing delay would add very much to the RTT.  A full 1000 segment queue will be drained by a 1 Gbps router in (1500 bytes * 8 bits)÷1 Gbps * 1000 packets =  0.012 seconds.
>
> What kind of RTTs are we talking about here?  If the average RTT is 200ms then 12ms is not a big deal.  It the average RTT is 10ms then it is a big deal.
>
> I think this result may be caused by something other than queuing delay.
>
>
> 2. A larger number of retransmissions?
> Why did this happen?  How many more retransmissions?  A lot more?  Like an order of magnitude or just a little?  I think I have a theory as to how this could happen.
>
> All TCPs act in the same general manner.  Bring the bottleneck queue to 100% utilization, lose a few packets, backoff.  Repeat ad infinitum.
>
> TCP Cubic in particular differs from NewReno because it has an exponential increase until the previous CWND, then a linear (TCP friendly) phase, and finally a second exponential phase.  I think you called it "probing".  Good term ;^)
>
> So the only possible source of additional retransmissions is after we have reached 100% queue utilization and we are losing a "few" packets before the congestion event causes the sender to backoff the CWND.
>
> It seems unlikely that this would occur during the first exponential phase of the Cubic algorithm because a congestion event just occurred and the queue at the bottleneck router has just been drained.  If it occurs during the linear increase phase then this is the same as NewReno.  If it occurs during the last exponential phase of the algorithm then your Cubic TCP may be out of tune.
>
> The congestion event is supposed to occur within the linear phase of the Cubic algorithm.  If the congestion event occurs during the probing phase of Cubic this indicates the CWND was a much lower value than the available space in the bottleneck router queue.
>
> This is very scenario dependent.  I have a graph of the queuing behavior of a Cubic TCP operating over a 10 Mbps link with an RTT of ~200 ms.
>
> In my experiments the Cubic TCP does congest the queue during the probing phase, however, I still get plenty of goodput (~8-10 Mbps).
>
> This is because I have a large RTT (TCP Cubic is probably not tuned for 200 ms).  The high goodput is probably because I have a low speed link (10 Mbps).
>
> ...Daniel
>
>
>
> 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+.
>
>
>
>