Subject: Re: [Tsvwg] Comments on Sally and Mark's slides

From: John Heffner <[email-masked]>
Date: Wed, 15 Nov 2006 18:31:23 -0500

Jerry Chu wrote:
> This may be known to many already. I just did a throughput test comparision
> between BIC and Reno using Linux 2.6.18 with the socket buffer 
> autotuning on.
> With two flows competing for the b/w of a 1Gbps bottleneck link, BIC
> will trample
> Reno within a few seconds and gobble up most (> 95%) of the bandwidth. This
> seems to happen regardless of RTT.
> 
> Cubic seems more much "friendly" towards the conservative Reno flows, at 
> least
> for a much longer while (30 minutes).

This is interesting; I don't think generally well known.  It is expected 
with a long RTT because Reno generally isn't able to fill it.  With a 
short RTT, I'm guessing you still have a fairly long bottleneck queue 
(interface queue on linux/gigE usually 1000 pkts).  When competing over 
a 1000 packet aggregate window, I'd expect an unfairness ratio of about 
10-15 with HS-TCP (have you tried HS-TCP).  The analysis isn't so easy 
with BIC, but it's probably a little higher since IIRC it has a more 
aggressive response function.  The larger the bottleneck buffer, the 
more unfair it will be.

If this is not the case, that is, if you have a short queue like a 
switch port with 64k, this level of unfairness would be pretty 
surprising to me.

   -John

---

From: "Jerry Chu" <[email-masked]>
Date: Wed, 15 Nov 2006 20:06:31 -0800

On 11/15/06, John Heffner <[email-masked]> wrote:
> with a long RTT because Reno generally isn't able to fill it.

Nor can NewReno defend whatever share it has got, fair or not.

With a
> aggressive response function.  The larger the bottleneck buffer, the

You may be right. I just found out I may have misunderstood how your
"socket buffer autotuning" work entails in Linux. Thinking autotuning code
will always pick appropriate values for sk_sndbuf/sk_rcvbuf, I neglected to
reset tcp_r/wmem[1], which has been made large (20MB) to accomodate
long RTT. For my local test through a router with < 350us RTT, the large
TCP tunables caused an arbitarily inflated queue to be created between
two TCP endpoints.

When I latter specified 64KB SO_SNDBUF/SO_RCVBUF to iperf,
effectively disabling autotuning (right?) and putting a much lower hard
limit on rcv window size, BIC and NewReno seem to be getting along
much better, each getting half of the 1Gbps b/w.

Jerry

---

From: John Heffner <[email-masked]>
Date: Thu, 16 Nov 2006 00:16:56 -0500

> much better, each getting half of the 1Gbps b/w.

I'm guessing setting txqueuelen down would help as well, but neither of 
these are desirable in general use.

   -John