Subject: Re: Trading off R and B for TBs

From: [email-masked] (Noel Chiappa)
Date: Thu, 18 Aug 94 09:27:40 -0400

From: [email-masked] (Curtis Villamizar)

    I meant better utilizes the total available bandwidth at a bottleneck
    under conditions of congestion.  Few people that have experience with TCP
    and understand it dispute that TCP does this better than at least the
    bandwidth sharing now offered by ATM.

I will accept this statement if by "TCP" you mean "a TCP with VJCC like
congestion sensing and handling mechanisms". Old TCP's *did not* have this
property.

    TCP is generally fair but not always

A bunch of similar VJCC TCP's will share bandwidth evenly at a choke point,
but my understanding (and please correct me if I'm wrong, I'm something of an
onlooker in all this resource reservation stuff) is that if you introduce a
"nasty" TCP it will steal bandwidth from the others. That's why you need
enforcement in the network fabric. (So far most TCP's are either broken or
nice; I don't know of a deliberate attempt to deploy a TCP which tries to
get more than an even share of bandwidth, but I imagine that too will appear
one day.)

	Noel

---

From: [email-masked] (Curtis Villamizar)
Date: Thu, 18 Aug 94 15:03:10 +0000

> congestion sensing and handling mechanisms". Old TCP's *did not* have this

Implied.  Pre slow-start TCP is a thing of the past (I hope).  (Though
perhaps I don't have enough experience with PCs and MACs or something).

> get more than an even share of bandwidth, but I imagine that too will appear

What I meant was:  Post 1988 TCP (VJ, Karels, et al congestion control)
shares nicely if the RTTs of the flows are similar.  If the RTTs are
different low RTTs are favored unless you are doing RED, in which case
it is still fair.  Unless you have multiple congestion points in which
case flows with less congestion points are favored.

For the purpose of the discussion at hand (we are way off topic now)
the statement "TCP is generally fair but not always" was sufficient,
though as you point out, broken TCPs may not be fair either.

The rest of the sentence was "and fair isn't always what you want
anyway" (or something like that).  But disecting that part of the
sentence would take us further from the topic of how to specify
reservations and implement them.

Curtis