C More aggressive compression
Connected: An Internet Encyclopedia
C More aggressive compression
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1144
Prev: B.2 Backwards compatible SLIP servers
Next: D Security Considerations
C More aggressive compression
C More aggressive compression
As noted in sec. 3.2.2, easily detected patterns exist in the stream of
compressed headers, indicating that more compression could be done.
Would this be worthwhile?
The average compressed datagram has only seven bits of header./50/ The
framing must be at least one bit (to encode the `type') and will
probably be more like two to three bytes. In most interesting cases
there will be at least one byte of data. Finally, the end-to-end
check---the TCP checksum---must be passed through unmodified./51/
The framing, data and checksum will remain even if the header is
completely compressed out so the change in average packet size is, at
best, four bytes down to three bytes and one bit --- roughly a 25%
improvement in delay./52/ While this may seem significant, on a 2400
bps line it means that typing echo response takes 25 rather than 29 ms.
At the present stage of human evolution, this difference is not
detectable.
However, the author sheepishly admits to perverting this compression
scheme for a very special case data-acquisition problem: We had an
instrument and control package floating at 200KV, communicating with
ground level via a telemetry system. For many reasons (multiplexed
communication, pipelining, error recovery, availability of well tested
implementations, etc.), it was convenient to talk to the package using
TCP/IP. However, since the primary use of the telemetry link was data
acquisition, it was designed with an uplink channel capacity <0.5% the
downlink's. To meet application delay budgets, data packets were 100
bytes and, since TCP acks every other packet, the relative uplink
bandwidth for acks is a/200 where `a' is the total size of ack packets.
Using the scheme in this paper, the smallest ack is four bytes which
would imply an uplink bandwidth 2% of the downlink. This wasn't
possible so we used the scheme described in footnote 15: If the first
bit of the frame was one, it meant `same compressed header as last
time'. Otherwise the next two bits gave one of the types described in
sec. 3.2. Since the link had excellent forward error correction and
traffic made only a single hop, the TCP checksum was compressed out
(blush!) of the `same header' packet types/53/ so the total header size
for these packets was one bit. Over several months of operation, more
than 99% of the 40 byte TCP/IP headers were compressed down to one
bit./54/
Next: D Security Considerations
Connected: An Internet Encyclopedia
C More aggressive compression
|