Subject: Effects of variable RTT: Data compression as another case

From: Daniel Senie <[email-masked]>
Date: Wed, 28 Jul 1999 14:11:31 -0400

With all the talk of ARQ introducing variability in RTT, I wonder why so
little attention is paid to data compression. Users of compression range
from EVERY (or nearly so) dialup modem in use today, to ISDN lines, T1
lines and so forth. Use of compression results in latency being
dependent on the content of the packets (degree of compressability).
This would seem a good thing to work with for studying effects of
variability on TCP.

Tests that I ran some years ago using simple analyzers on routers I was
building showed compression algorithms chewing lots of CPU and providing
very high compression rates on some data (e.g. lots of large packets
full of zeros, like transferring a large file of all the same character)
would result in 10:1 compression or better, but chewed the processors
doing the work. End stations saw highly variable data rates, and it's
not clear that TCP appreciated this at all.

The issue of ARQ affecting throughput due to variability of RTT is
perhaps too specific. The wider question is how does TCP handle
variability in RTT for reasons other than network congestion?

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 28 Jul 1999 19:33:40 +0100 (BST)

On Wed, 28 Jul 1999, Daniel Senie wrote:

> little attention is paid to data compression.

CPU performance scales faster than link capacity. Propagation delay is
an unavoidable fact of life, while CPU and processing overhead for
compression tends to towards the vanishingly small.

> Users of compression range

if you ran similar tests on routers built today, would you see the
same processor delays?

L.

> variability in RTT for reasons other than network congestion?

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Daniel Senie <[email-masked]>
Date: Wed, 28 Jul 1999 14:43:45 -0400

> compression tends to towards the vanishingly small.

Hmmm. Guess I didn't make myself clear enough. CPU loading wasn't the
biggest issue. RTT time is affected by altering the latency of a packet
through a link. Suppose a link is running at 56Kbps (speed chosen just
because the latency numbers are easy to work with). Short packets
through a 56K link (e.g. ping packets) see a RTT of 33ms or so. Adding
in data compression can shorten the packets, resulting in lower
serialization delays. The larger the packet (assuming compressable data)
the greater the variation in serialization times.

Variation between compressable data and incompressable data (which may
actaully result in packets growing) causes lots of variation in
serialization time for the packets. A link can look at one point like
it's able to handle a bandwidth several times actual, and end stations
start cranking more data to take advantage. Then some incompressible
data comes along, and the link can look like it's even smaller than
actual (packet growth from imcompressability, even if it's limited). As
a result, the latency and apparent bandwidth of the links varies with
the content of the data.

Sorry if I got folks thinking the CPU loading was the core issue. It's
not.

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 29 Jul 1999 10:13:41 +0100

N.B. Geo satellite with reliable ARQ introduces RTT variations
of say 2-6 x GEO RTT delay. Even worse, the variability can rise
from zero additional delay to more than x3 delay in one step,
causing RTO expiry.  Much more significant than compression
effects.

It's also worth commenting that comporession at the IP layer 
may (in future?) be provided end-to-end.

Gorry Fairhurst.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 29 Jul 1999 11:56:38 +0100 (BST)

On Thu, 29 Jul 1999, Dr G Fairhurst wrote:

> of say 2-6 x GEO RTT delay.

That would presume that you are e.g. tunnelling IP over AX.25. IMO
this isn't something that IP-over-satellite vendors would countenance;
as part of the Internet; it's simply incredibly suboptimal.

Got any real-world examples of this in use?

> Even worse, the variability can rise

compression is an application-layer function. You can't second-guess
the application well.

L.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 29 Jul 1999 07:40:37 -0400

> causing RTO expiry.  Much more significant than compression

Agreed the scale of the delay can be worse on satellite. With data
compression, the size of data actually transmitted over a layer 2 link
can vary from 1.2x normal size (compression expanded data, STAC at least
limits degree of expansion), to 1/4 original (assuming 4:1 compression).
A 1024 byte ping packet should take 285ms across a 56Kbps link. With
compression this time is reduced for some packets to 33ms. This
represents an 8x variation in time. The actual time involved (wall clock
time) is much less, as the timescales are less.

Part of what I'm trying to convey is that data compression is a good
thing to use in the lab to study the effects of variable bandwidth and
RTT on data flows. It's certainly a cheaper thing to set up than a
satellite link, and does represent a real-world case. Certainly
satellite link issues are an important case, but they are not the only
one.

> may (in future?) be provided end-to-end.

It's even possible today. Some encrypted tunnel solutions offer
compression. SSH offers this as well.

As this occurs, there will be interesting additional problems.
Compressing already compressed traffic, depending on the compression
algorithms chosen, results in data expansion, additional delay or both.

Bringing the focus back to the PILC mission of what a link layer should
look like, the question of whether data compression should be employed
and its implications to IP, TCP and other protocols is issue. These are
items which I feel should be discussed in the PILC drafts, as they do
have an effect.