Re: TO COMPRESS OR NOT TO CMPRS (please reply)

Michael Richardson <mcr@sandelman.ottawa.on.ca> Thu, 20 February 1997 11:03 UTC

Received: from cnri by ietf.org id aa28399; 20 Feb 97 6:03 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa07050; 20 Feb 97 6:03 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA01462 for ipsec-outgoing; Thu, 20 Feb 1997 05:52:58 -0500 (EST)
Message-Id: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca>
To: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Wed, 19 Feb 1997 13:12:59 PST." <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
Date: Thu, 20 Feb 1997 01:01:55 +0200
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

>>>>> "Dennis" == Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us> writes:
    Dennis> The yes-compress/no-compression discussion is akin to
    Dennis> comparing Pepsi and Coke. Let's put a framework in place
    Dennis> and make it optional and negotiated. Let empirical data
    Dennis> determine its usefulness.

  As long as it is negotiated, I see no reason why one needs
a flag to indicate compression. One simply negotiates two SPIs. One
SPI is compressed, the other is not. If the data doesn't compress (or
is too short to even bother trying: a TCP ACK, or telnet keystroke
data) then you use the SPI that didn't have compression negotiated.

  My reading of the literature on high performance (parallelizing)
networking says that the sooner you can categorize the packets the
better you do. For TCP/UDP this means sorting by port number and
*then* worrying those other things like options, fragments, etc..

  For IPsec, the SPI is what I'd sort by. 

]   Temporarily located in balmy Helsinki, Finland              | one quark   [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON     | two quark   [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [