From owner-freebsd-hackers  Sat Sep 30 04:47:56 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id EAA28359
          for hackers-outgoing; Sat, 30 Sep 1995 04:47:56 -0700
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA28353
          for <hackers@freebsd.org>; Sat, 30 Sep 1995 04:47:51 -0700
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA20709; Sat, 30 Sep 1995 12:54:27 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199509301154.MAA20709@labinfo.iet.unipi.it>
Subject: Unreliable networks...
To: hackers@freebsd.org
Date: Sat, 30 Sep 1995 12:54:27 +0100 (MET)
Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2164      
Sender: owner-hackers@freebsd.org
Precedence: bulk

Hi,
the growth of the internet in the last year, possibly together with
some management problems somewhere, has caused the quality of the
connection between Europe and the US (at least as seen from our
site) to decay dramatically.  In the last few months, it is common
to see a packet loss in the range 10..50% when pinging a host
overseas (things go much better for hosts in France or UK).
This means that the connection is there, it's simply overloaded (or
misconfigured: at times we regularly loose every second or third
packet!)

Such a large loss rate almost completely defeats the algorithms
used by TCP to determine the RTT, to the point that ftp-ing a file
larger than 100K takes a huge amount of time if it succeeds at all.

While it is clear that this behaviour lies in the configuration or
management of routers, there is not much I can do to improve the
situation.

So I start to feel the need for countermeasures which allow a
connection to stay up and perform reasonably even in presence of large
packet losses. One idea might be to tunnel the TCP connection using a
couple of processes in the sender and the receiver. The processes could
negotiate the expected bandwidth, transfer length and have an idea of
the packet loss, and send packets using UDP. On the receiving side,
incoming packets are buffered (possibly using a large enough buffer),
requests are sent for missing packets, and the collected data are sent
up to the receiving process via TCP. This is probably something that
must be tailored to the specific application (e.g. FTP), but would
have, IMHO, some advantages for the servers because it would avoid
many many failed connections.

Any ideas on such an approach, or on something that already exist to
solve this problem ?

	Thanks
	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================