Anyway, the fascinating thing here isn't that this problem exists... or
in exactly what the explanation is... but rather, that everyone
responding has a different answer (there are at least five completely
different explanations for this effect). In this context its easy to
understand the need for network diagnostic and management tools.
- Stefan
-----Original Message-----
From: Neal Cardwell [mailto:cardwell@cs.washington.edu]
Sent: Monday, September 28, 1998 9:16 AM
To: syn@cs
Subject: Boosterware? (fwd)
yet another TCP accelerator.
---------- Forwarded message ----------
Date: Mon, 28 Sep 1998 15:16:44 +0200 (CEST)
From: Sean Doran <smd@ebone.net>
To: end2end-interest@ISI.EDU
Subject: Boosterware?
I got an interesting UCE, the tail part of which is below.
Does anyone know anything about this?
Sean. (although rampant speculation can be fun too... :) )
- --
Come check us out at http://www.flash-networks.com !!
Brief Summary of Boosterware technology
Architecture and concept: Our software installs as a client/server pair,
on both sides of a path or link (for example on servers at both ends of
a fiber or satellite link). Existing servers see our applications as
their proxy (or parent-proxy to an existing proxy). The technology is
completely transparent to end users.
Our software accepts incoming TCP connections, and transforms them into
our own protocol, called BoosterWare, and at the far end back into TCP.
This protocol is actually UDP with 8 more bytes of data that make up our
patent-pending protocol, encapsulated in IP, so to the outside world it
is an IP packet.
The point for the entire exercise is that TCP is inefficient for many
long haul links, and our protocol fixes these inefficiencies, while
preserving transparency and the reliability of TCP connections.
Gains to be expected: These depend on the link handled. Typical gains
are about:
* around 250%-400% for a satellite based connection.
* around 100% for a fiber optic cable connection.
How is this done?
1. Our protocol is tuned to the specific link/path used, rather than
trying to find out each time a connection is started, as in TCP. The
result is an immediate ramp up to full speed.
2. Our Window management (Transmit windows and Acknowledgment windows)
is specifically suited to long-haul paths, satellite delays etc.
3. Our Acknowledgment mechanism is far better than TCP, allowing
positive, selective and negative Acks. Bandwidth is utilized for more
data and less acks.
4. Our protocol can allow for efficient use of asymmetrical paths (say 2
MBPS in one direction, and a dial-up as the return path)
Please note all traffic remains as IP packets and is data-independent,
so you could use compression and/or encryption as well as our
application, for cumulative gains. The same applies to caching and
firewalls.
Installation is straightforward for both client and server, taking 5
minutes. Testing is possible by using a free 90 day evaluation
version.