Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!CS.UCL.AC.UK!jon
From: jon@CS.UCL.AC.UK.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: network horror stories
Message-ID: <8703251140.AA24968@ucbvax.Berkeley.EDU>
Date: Wed, 25-Mar-87 06:41:07 EST
Article-I.D.: ucbvax.8703251140.AA24968
Posted: Wed Mar 25 06:41:07 1987
Date-Received: Fri, 27-Mar-87 00:53:12 EST
References: <8703241852.AA20403@flash.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 29
Approved: tcp-ip@sri-nic.arpa


Exactly my point. TCP can be made to work fine. IP can be made
to work fine, but currently has no (workable) mechanism for
congestion control. If the internet is overengineered in terms
of bandwidth, this works OK. If some congestion control
mechanism is put in the gateways, it can be made to work better.
Just fixing everyone's TCP does not fix things, because they
can not make optimal use of the paths.

X.25 networks give you a (one particular kind of) handle
to control the hop by hop congestion
control if you implement it right, whilst TP4/TCP (especially with
selacks) buys you efficient end to end control. JANET happens
to do this, which is why it  works well.

The resource reservation explicit in X.25 means you don't get
hit by misbehaving end points - it's fair. A DTE that floods
the DCE with CALL REQUEST packets just gets ignored by any
reasonable DCE, and does not impinge on the network at all,
after all X.25 is an interface spec more than a protocol.

Asking people to certify TCPs before attaching to a research
network like the internet is like asking your friend to certify
that the car he's selling you cheap is going to run trouble
free.

We can't prove programs yet.

jon