Compression [was Re: applying AES-GCM to secure shell: proposed "tweak"]

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> If I do the "do them all and instrument" thing, I may leave the
>> instrumentation infrastructure in place in the shipped version and
>> provide a way for people to turn it on and collect the data to
>> figure out which form of compression works best for their particular
>> application.
> That'd be interesting data to have.

My own opinion exactly.

> (I think that if people really want to squeeze out every byte, and in
> particular if they're dealing with lots of small packets like the
> keystrokes for this email where the headers are much larger than the
> data, the best option is to use a protocol-aware compressor like
> PPP's header compression, [...]

Agreed.  But that "target market", if you will, is not really what this
was aimed at.  I more had this in mind for bulk data transfer, where
the question is whether the data's statistics match the headers' well
enough for compressing them all together to win over compressing just
the data - or, hm, compressing the headers and data with two different
contexts, come to think of it.

> Without thinking about it too much you could probably get the entire
> header into about 32 bits, including a flag for piggybacked
> window-adjusts to get rid of those as well.

SSH doesn't have piggybacked window-adjusts.  Or were you thinking of
effectively adding them, by giving the compression code special
handling for the (probably common, especially for interactive use) case
of a window adjust with an immediately following small data packet?

> OTOH how many bytes to you really want to save in exchange for this
> protocol redesign?

What protocol redesign?  All this stuff can be done within existing
SSHv2, as compression algorithms.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B