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

From: "Jerry Chu" <[email-masked]>
Date: Tue, 14 Nov 2006 14:38:20 -0800

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).

FYI,

Jerry

>Injong Rhee wrote:
>
>    The typical internal flows, in my understanding, use
>    64KB as the limit. So if the fairness is an issue because
>    of use of bandwidth in the Internet, then it should be tested with this constraint.
>
>
>It's highly likely this fact will change in the near future. The
linux kernel by default is now >shipping with a max of 4MB, and Vista
is rumored to have a similar behavior.
>   -John

---

From: Sally Floyd <[email-masked]>
Date: Tue, 14 Nov 2006 15:32:46 -0800

> bandwidth. This seems to happen regardless of RTT.

I am assuming that by Reno you actually mean NewReno or SACK?
It would be useful to see how they did in scenarios with a little bit of
reverse-path traffic and web traffic, to avoid phase effects.

And if both flows were using NewReno or SACK, how would they do,
making use of the available bandwidth?   That is, is this scenario BIC
trampling Standard TCP, or BIC making use of available bandwidth
that TCP couldn't use?  (Both scenarios are quite possible with BIC,
as I understand, but the addition of web traffic and reverse path 
traffic
should make things look a little better for BIC, I would think.  By 
adding
the more realistic traffic mix that also makes it harder for Standard 
TCP
to maintain very high congestion windows.)

> for a much longer while (30 minutes).

- Sally
http://www.icir.org/floyd/

---

From: "Injong Rhee" <[email-masked]>
Date: Tue, 14 Nov 2006 18:52:08 -0500

Here is the test we have done with background traffic (and with reverse path 
traffic).
This link is a test of TCP friendliness (one flow TCP-SACK without 64KB 
limit,
the other flow with a TCP variant) using Linux 2.6 emulation testbed.
http://netsrv.csc.ncsu.edu/highspeed/1200/bk/tcp_friendliness/tcp_friendliness.htm

The link capacity is 400Mbps. For more extensive description of test 
results,
have a look at 
http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/asteppaper.htm.

I will post the results with 64KB limit on in a few days when we are done 
with that
test. In that test, we will run some Internet like traffic (as background) 
purely
made up with TCP-NewReno (or SACK) flows and see the effect of TCP variants 
on
these Internet traffic.

----- Original Message ----- 
From: "Sally Floyd" <[email-masked]>
To: "Jerry Chu" <[email-masked]>
Cc: "John Heffner" <[email-masked]>; "Injong Rhee" <[email-masked]>; 
"tsvwg" <[email-masked]>
Sent: Tuesday, November 14, 2006 6:32 PM
Subject: Re: [Tsvwg] Comments on Sally and Mark's slides

> as I understand, but the addition of web traffic and reverse path traffic
> should make things look a little better for BIC, I would think.  By adding
> the more realistic traffic mix that also makes it harder for Standard TCP

---

From: "Jerry Chu" <[email-masked]>
Date: Tue, 14 Nov 2006 17:34:51 -0800

> I am assuming that by Reno you actually mean NewReno or SACK?

I'm using the latest Linux 2.6.18 kernel, which includes a slew of
congestion avoidance algorithms to choose from. I've been assuming
the default "reno" is really NewReno (and will be really surprised if it
isn't). All the rest goodies (SACK, TS...) are on.

> reverse-path traffic and web traffic, to avoid phase effects.

I did a quick test of adding one reverse iperf flow and it doesn't seem to
make much difference. But again my test is by no means extensive.
Will take a look at Injong's paper.

> making use of the available bandwidth?

This depends on the RTT. We know that once a NewReno flow gets
stuck with a low ssthresh, with a large RTT it will take a while for it to grow
cwnd linearly. But they do eventually get out of that hole, unlike with
competing BIC flows.

>That is, is this scenario BIC

Agreed. One algorithm's aggressiveness can equally be attributed to the
other algorithm's incompetence :) We are just a bit concerned about
the effects of running both BIC and NewReno in our network.

Jerry

---

From: Sally Floyd <[email-masked]>
Date: Tue, 14 Nov 2006 18:42:16 -0800

Jerry -

> other algorithm's incompetence :)

Yep.  But in a specific scenario, you can check which it is.  That is,
if the BIC flow uses Standard TCP instead, does that change
the bandwidth received by the second TCP flow?  Or not?

> We are just a bit concerned about

I agree.

- Sally

---

From: Erblichs <[email-masked]>
Date: Wed, 15 Nov 2006 10:24:50 -0800

Group,

	Don't you need a section on how to behave when
	a flow has zero awareness of any CC method like
	UDP?

	Second, is it fair or unfairness if a CC alg
	delays the awareness of inpending CC by
	ie:  increasing the number of DUPACKs before
	     a fast rexmit?
	or ...

	In our normal network layering methods, we
	can have what was already agreed as the
	appropriate path bandwidth metrics. Should
	we be forced to use only a fraction of what
	was agreed upon? By implementing multiplicative
	decrease (MD).
	ie: TCP with LDP/MPLS where a path bandwidth
	    was set.

	Is it EXPECTED even the same CC algor
	differently tuned to have the same level of
	FAINESS?

	Why is fairness so important? Is it a
	locally controlled (LAN) or a WAN issue
	that is more effected by the ISP or the
	local admin? Maybe the type of audience
	should be specified???

	If TWO competing flows have diff CC algors
	collide because ONE-OF-THEM always does
	additive increase until congestion? Should
	the other CC algor that achieved STASIS
	be forced to decrease its achieved bandwidth?

	Lastly, sorry, it SEEMS that a number of
	different NON-IETF CC TCP alg already exist
	outside of the R&D envs. Is it REASONABLE
	to expect that those implementations request
	IETF approval and ALL versions everywhere
	change depending on IETF feedback?

	Mitchell Erblich
	---------------------