Subject: Re: status of T/TCP

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Sep 1998 16:10:26 -0600 (MDT)

> From: [email-masked] (Jim Gettys)

> ...
> > BTW - some of this latency is the modem being too clever about
> > buffering and compressing. Shutting it down might decrease the latency.
> > Another part is the use of large packets - it might be better to have
> > smaller packets with additional overhead. The overall transaction latency
> > would increase, but the time to first portion of response would decrease.
>
> Sure.  The right thing to do (if HTTP did not have such verbose request
> response headers) would be to turn off all modem compression, and
> send the HTML content compressed.  Deflate compression does very
> much better than anything in modems.

Modems tend to use LZW, always (I trust) with at least 10-bit and at least
sometimes more.  Judging from what Paul Mackerras has told me of his
comparisons between BSD Compress (RFC 1977) and Deflate (RFC 1979) in his
widely used `pppd`, the difference between Deflate and your typical modem
on the data that is compressed should be about the difference you see
between `compress` and `gzip`, or around a 10% improvement in compression
ratio but at a ~2X cost in CPU cycles, and mostly on the side that does
not have cycles to waste, the HTTP server.

Since most ISP's do not run hardware that supports VJ header compression,
a modem using 12 or 14-bit LZW will be able to good things to those
45-byte TCP/IP/PPP headers, which will probably almost always excede what
the modem loses by using LZW over the application-data.

In other words, I bet that if you measure things, you'll find that
turning off v.42+v.42bis improves latencies (and only when the link
is mostly idle, as with `ping`) but always hurts throughput, even
when moving pre-compressed application-data.

> ...
> TCP connection vs. T/TCP.  Conventional TCP takes two...  I want to
> get one of them back...

If you get it back, then how do you deal with the modified form of SYN
attack?  As has been said repeatedly recently, an extra intial RTT paid
by someone before the server commits any significant resources to the
request seems necessary to defend against that attack.
I've claimed that random-drop in the application would help, but people
tend to not like random ideas.  Besides, even I admit it would help only
when the ratio of good to bad connection attempts is small.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Jim Gettys)
Date: Fri, 18 Sep 1998 07:13:46 -0700

> Sender: [email-masked]
> From: Vernon Schryver <[email-masked]>
> Date: Wed, 16 Sep 1998 16:10:26 -0600 (MDT)
> To: [email-masked]
> Subject: Re: status of T/TCP
> -----

The server can cache the compressed object, and only compress it once.

Our measurements show a much greater effect of compression than 10%;
see: http://www.w3.org/Protocols/HTTP/Performance/#Compression

This are measurements over real modems.
				- Jim