Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cuae2!ihnp4!ucbvax!FLASH.BELLCORE.COM!karn
From: karn@FLASH.BELLCORE.COM (Phil R. Karn)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Yet more on RTTs
Message-ID: <8611150254.AA04953@flash.bellcore.com>
Date: Fri, 14-Nov-86 21:54:41 EST
Article-I.D.: flash.8611150254.AA04953
Posted: Fri Nov 14 21:54:41 1986
Date-Received: Sun, 16-Nov-86 01:06:06 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa

I feel that the "round trip timing problem" by itself is a red herring.
It's really a symptom of a larger problem.  A TCP with a very simple RTT
algorithm that always errs on the high side would still perform quite well
if the network didn't drop so many packets. The network wouldn't drop so
many packets if it wasn't being swamped by so many badly designed and
mistuned TCPs.

Last summer in Monterey there was a lot of discussion about vendor
certification and how much hard work it takes to test a protocol
implementation. The thing is, we already HAVE a "validation suite"; it's
called "operational use in the ARPA Internet"!  Furthermore, it has already
revealed some serious problems in some very popular implementations, but the
vendors have yet to fix the damn things (including the maker of the
workstation I'm typing this on). I've seen several (object only) releases of
software for this system come and go since RFC-896 came out and they STILL
don't have the Nagle algorithm yet.  Given how popular this system is, it's
no surprise that the Internet is in such trouble.  I think we should
concentrate on fixing known problems before we invent new ones to solve.

Phil