From: [email-masked]
Date: Wed, 16 Nov 94 12:53 EST

From the comments on my posting, it looks like people generally agree that:

1) Without reservations and class based scheduling, unregulated realtime 
   traffic will back off VJCC traffic (All).
2) Therefore we should have reservations and class based scheduling (Curtis).
3) In the interim, route unregulated realtime traffic to go only over 
   class-based scheduling routers (Noel).
4) Unless there exists such a path between end-systems, any congested FIFO 
   gateway will blow away VJCC end points.

Thus, I feel that there is likely to be a period of chaos in the
near future with predatory TCPs and unregulated point-to-point 
video preferentially getting bandwidth over well-behaved TCPs. 
We need to move full speed ahead on Fair Queueing or some other type 
of segregation (protection). This message should reach vendors as soon 
as possible.

In regard to several of Jon Crowcroft's claims regarding VJCC:

1) The 'subtle meta-game theory' ("if everyone was trying to
choose an algorithm to achieve this same goal, then what should I choose 
[being like them] to get the best for me") is standard 
non-cooperative game theory, first studied by John Nash, who won the
Nobel Prize this year for this work. The equilibrium so achieved is called
the Nash equilibrium [J. Nash, "Non-Cooperative Games", Annals of Mathematics,
V54, 2, September 1951, pp 286-295). 

2) VJCC is not a Nash equilibrium strategy. This is because if everyone else
is doing VJCC, I _DO NOT_ have an incentive to do VJCC - I should instead
send as fast as possible for one RTT, backing off the rest of the
connections, then send my data on the empty net. 

3) Even if one could come up with a Nash strategy for FIFO (I don't
know what it is), it is not guaranteed to be fair or converge to 
equilibrium (Shenker, Sigcomm '94). 

4) Slow start is responsible for VJCC's poor performance on long-haul
links (each RTT is a long time). We need a better slow start. This 
can be achieved with explicit rate information (as in ATM ABR) or
with packet-pair probing (if everyone does FQ).

So, I disagree with the claim that VJCC is the best and only possible
congestion control algorithm. It does a splendid job under the constraints
under which it operates (FIFO gateways, implicit feedback). If you
change the rules of the game (and I argue above that you need to do this)
then it is also appropriate to rethink VJCC. For more details, please
see my recent paper in ftp.research.att.com:dist/qos/pp.ps.Z that
describes in excrutiating detail a flow control scheme for FQ networks.

keshav

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Nov 94 08:58:48 +0000

>V54, 2, September 1951, pp 286-295). 
 
the hofstadter iterated prisoners delimma is NOT nash equilibrium, i'm
afraid.

 >connections, then send my data on the empty net. 

sure - but if there are N of you bad guys, and you all try this
you will get apalling throughput unless you know N and the bottleneck
bandwidth. - you don't otherwise the dynamic routing/fifo is a wrong
assumption. you lose. qed.

 >equilibrium (Shenker, Sigcomm '94). 
true - but as i've said, iterated prisoners delimma is a social reason
(i.e. out of band/telepathy) for peopel to choose a strategy,  not 
one based in exchange of inband or implcit detected (even covert
signaling)) so this is not relevant
 
 >with packet-pair probing (if everyone does FQ).

yes, obviously. thats the point of the int-serv group - choose the
new net model -  either tell the net 'i want x' thru rsvp, or try x
and get told, no: only y is avaialble

this latter stage is something missing (an unsolicited RSVP
renegotiation from the downstream routers would suffice...)
 
 >congestion control algorithm. 

i didn;t claim that.

 jon

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 17 Nov 1994 10:00:52 -0500

In message <[email-masked]>, [email-masked] write
>    gateway will blow away VJCC end points.

This is a good start.  Please note that I disagree with 3), since
generally underutilized links may also be used even if they provide
pure FIFO queueing.  In 3), reservations and class based scheduling
are be preferred.  Also note that in any real time routing that
follows unicast routes, there is not choice.

> video preferentially getting bandwidth over well-behaved TCPs. 

There is no basis for this statement and it is inflamitory.  The
strongest statement you can make is that the possibility exists to
write a predatory TCP, though no one has proposed to do so.  For
example, I'm sure that if TCP Vegas were shown to only acheive better
bandwidth solely due to being more aggresive, it's authors would do
the responsible thing and withdraw it from consideration, at least
pending further research.

> of segregation (protection). This message should reach vendors as soon 

I agree.

> In regard to several of Jon Crowcroft's claims regarding VJCC:

It is counterproductive to continue this discussion.  Let us not worry
about how "good" or "bad" or "desirable" or "undesirable" TCP is.  Let
us simple state that it is the defacto standard that we have to deal
with and a mimimum requirement is that TCP be well supported.

That said.  Please ignore the rest.  ;-)



*** IGNORE THIS ***

> connections, then send my data on the empty net. 

If you don't know the capacity of the empty net, you don't know what
to back off to.  Sending one RTT at full FDDI rate won't do much good
if the other end is behind a T1 with modest buffer capacity.  You
still need VJCC to find the optimal bandwidth and those pesky other
TCPs will still keep slow starting.  You make actually synchronize
many of them and make matters worse if the bottleneck has too little
queueing.  You can try to simulate two TCPs by cutting ssthreash to
3/4 of cwnd and increasing 2 segments per RTT (or three, or ...) but
you can't do much better and if you get too aggresive could kick
yourself into a timeout and slow start by losing multiple packets in a
short interval and not knowing which packets in the prior window need
to be retransmitted.

> equilibrium (Shenker, Sigcomm '94). 

Yes.  I agree.  So we reccommend doing something better than FIFO.  To
predict the eminent collapse of the Internet into chaos if we don't
immediately do away with FIFO is nothing but inflamatory.  This is
reminiscent of the argument to drop IP and adopt OSI because the IP
address space is about to run out any day now.

> with packet-pair probing (if everyone does FQ).

Please read ftp://ftp.ans.net/pub/papers/tcp-performance.ps.  We
acheived 95+% goodput on 70 msec DS3 paths with single TCP flows and
multiple TCP flows sharing a bottleneck.  The paper aregues that these
(1,4,8 flows) with dientical RTTs are much more difficult cases to
handle than very large numbers of flows with a mix of RTTs.

Any advantage of ABR ER in an all ATM net has yet to be proven.  It
strongly feel that it will prove substantially inferior in a
heterogeneous network.  Unless you or I can prove this one way or the
other, we should drop this discussion now and not make any claims.

> describes in excrutiating detail a flow control scheme for FQ networks.

Sorry Keshav.  The rules are heterogeneous networks and TCP.  If you
have a better protocol than TCP for a heterogeneous network, take that
matter to the end2end-interest mailing list.  Changing the rules to a
restart from scratch is a different game.  If a particular solution
doesn't perform well in a heterogeneous environment, it is not a good
solution.  The wholesale replacement of the entire global Internet
(every campus FDDI and ethernet in every university, corporation,
library, high school, etc and every T1, 56k and PPP link, etc) is not
under consideration.

Curtis