Subject: weakly / strongly bad TCPs

From: Chip Elliott <[email-masked]>
Date: Tue, 15 Nov 94 14:23:44 EST

Noel,

Check out Floyd and Jacobson's 1992 "Traffic Phase Effects"
paper for a clear explanation of how even 4.3 BSD TCP is
"weakly bad" in your sense -- namely, flows with longer
round-trip times get less than their "equal" share of the
bandwidth. They also point out various possible meanings
of the word "fair"...

Very likely folks in the provinces, topologically speaking,
are getting less bandwidth than those of us who sit closer
to the centers of things. I guess that's one of the perks
of being well-connected.

As for making predatory TCP implementations -- it would
be child's play to modify the code to be more aggressive
than the canonical versions. I think we'll start to see
predatory versions fairly soon, since there are incentives
for PC stack suppliers to provide better benchmarks than
their competition, and the easiest and most striking way
to do it is to adjust the backoff and ramp up.

-- Chip

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 16 Nov 94 09:32:45 +0000

>to do it is to adjust the backoff and ramp up.
 
then we must make sure that _all _ benchmarks specifiy that the
conenctions must be run on a congested net, and must compare 
company X TCP with a mix of other TCPs on the congested net, since
anything _except_ van's or related schemes will do worse under those
circumstances.

 jon

---

From: [email-masked]
Date: Wed, 16 Nov 94 10:10:19 -0500

>anything _except_ van's or related schemes will do worse under those

Much lurks in this remark though.  Exponential backoff and slow
start are (as I understand them, anyway) classes of procedures that
each have a parameter (coefficient).  You can tune this coefficient
if you wish, and the qualitative characteristics are maintained over
a large range of values (if you take a sufficiently broad view),
but if different TCPs are using different parameters then I believe
they will end up with different shares.  Also, although we can
characterize the behavior of different parameter settings, the "optimal"
values are indeterminate with respect to fairness (I think they affect
the behavior of the system with respect to time and throughput - 
certainty of maximal throughput vs. certainty of timely throughput -
two thoughtful implementors could arrive at different answers that won't
receive equal shares).

I thought that there were people smarter than me who had more or less
proved this stuff.  But perhaps I misunderstood.

/Bill Barns

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Nov 1994 17:14:54 +0100

>each have a parameter (coefficient).

In fact, VJ's slow start has a couple of non scalar coefficient: the starting
point of the slow start, "one packet", and the fixed increment of the
congestion avoidance, "so many bits per round trip". Dimension-full
coefficients typically depend of the operating conditions, i.e. of the
range of bit rates and delays which is being considered. For example, if all
your lines are in the 300 bps to 9600 bps range, a linear increment of 10000
bits per RTT would be a tad too large. It would on the contrary be way to small
if you lines are in the Gbps range - would imply 100.000 RTTs before ramp up
is complete!

Which makes me think that we have not seen the end of history in this
particular field.

Christian Huitema

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 16 Nov 94 16:38:54 +0000

>they will end up with different shares.  

yes & if they have different b/w*delay paths they get different
dynamics on converging on fairness (if ever reaching it etc)

but 'doing better' is still all in the realms of imagination, unless
you have explicit information about network conditions

 >proved this stuff.  
 
yes- that is partly what int-serv is about - asking the net to set more
explicit condsitions so we can do better fairness (as well as distinguising
flows that need and deserve different deals.
 jon

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 16 Nov 1994 14:11:13 -0500

Lets try to get back on a constructive track.  :-)

> bandwidth. They also point out various possible meanings

Check out Floyd and Jacobson's 1994 "Random Early Detection Gateways
for Congestion Avoidance" (RED) to see what routers can do to reduce
or eliminate phase effects, and synchronization of TCP flows, and
reduce delay and improve fairness.  I've played with a RED
implementation and observed improved link utilization and total
goodput as well (see ftp://ftp.ans.net/pub/papers/tcp-performance.ps,
"High Performance TCP in ANSNET").

> to the centers of things. I guess that's one of the perks

The bias topward lower RTTs at a bottleneck is also reduced with RED,
if that is what you are referring to.

> to do it is to adjust the backoff and ramp up.

It is easy to make predatory TCP implementations.  It alsways has
been.  Whether we will start to see them is spaculation on your part.
The potential has always existed and so far there have not been
problems.  Most end users do not have source for their TCP and no
vendor is likely to do this.

None the less, I agree that routers and/or switches should try to
improve fairness in response to predatory TCP implementations.

If we believe that a heterogeneous network will be in place,
algorithms which do not require end to end deployment are the only
solutions which will work.  

Here are some examples of things that do work.  At any given
bottleneck:

  1) less than 1 delay bandwidth product (D*BW) in queueing will
     reduce the ability of TCP to fully utilize the bottleneck.  More
     than 2 * D*BW increases delay (unless RED is in use) with little
     or no further improvement in goodput.
  2) implementation of RED at the bottleneck only (nowhere else in the
     network) will reduce delay, improve fairness if individual RTTs
     differ, and further improve link utilization and goodput given
     the same amount of queueing.  RED also avoids some degenerate
     collapse situations due to misconfigured very high speed flows.
  3) implementation of a fair queueing scheme (ie: WFQ if integrated
     with a packet classifier and configured for link sharing, or
     using RSVP to make reservations for elastic traffic, SFQ if there
     is no means to make reservations).  RED can be applied to
     individual queues.

Empirical evidence, including evidence in "High Performance TCP in
ANSNET" supports 1) and 2) above.

The above are examples of algorithms.  The WG has stated that they do
not want to be dictating algorithms.  AS a WG, int-serv needs to:

  1) clearly state the requirements.  May I suggest:
	- must work in a heterogeneous network
	- elastic traffic must be supported, TCP in particular must be
	  supported 
		- high bottleneck utilization and high goodput for
		  elastic traffic is a goal
		- reducing delay for elastic traffic is a goal
		  (secondary to high goodput)
		- improving fairness for unreserved elastic traffic is
		  a goal (secondary to high goodput - it make little
		  sense to acheive a low percentage of possible
		  utilization at the expense of being very fair)
	- better support for real time traffic is a goal
		- low loss (or lossless) service of reservations is a
		  goal 
		- minimizing delay is a goal
		- reducing or bounding delay variation is a goal
		- policing is a secondary goal
     These are goals that are intended to spark constructive exchange.
     If we can agree on this in principle, we can then try to state
     the requirements.

  2) offer possible solutions, or at least existance proof that the
     requirements are achievable.  (Sorry if I tried to do this above
     before requirements were agreed upon).

Please - let us set aside the bashing of protocols or technologies and
get down to stating what requirements we are looking for.

Curtis