RE: IPCOMP and IPSEC

Eric Dean <edean@gip.net> Sat, 30 May 1998 21:09 UTC

Return-Path: edean@gsl.net
Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08200 for <ippcp-archive-file@ftp-eng.cisco.com>; Sat, 30 May 1998 14:09:34 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA04710 for <ippcp@external.cisco.com>; Sat, 30 May 1998 14:09:28 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA06468 for <ippcp@external.cisco.com>; Sat, 30 May 1998 14:09:28 -0700 (PDT)
Received: from nic.gip.net(204.59.152.195) by proxy3.cisco.com via smap (V2.0) id xma006466; Sat, 30 May 98 21:09:25 GMT
X-SMAP-Received-From: outside
Received: from yaway.gsl.net (yaway.gip.net [204.59.155.59]) by nic.gip.net (8.8.5/8.8.5) with ESMTP id QAA07288; Sat, 30 May 1998 16:49:31 -0400 (EDT)
Received: (from edean@localhost) by yaway.gsl.net (8.8.3/8.7.5) id RAA03694; Sat, 30 May 1998 17:09:51 -0400 (EDT)
Date: Sat, 30 May 1998 17:09:50 -0400
From: Eric Dean <edean@gip.net>
To: Avram Shacham <shacham@cisco.com>
cc: Stephen Waters <Stephen.Waters@digital.com>, ipsec@tis.com, ippcp@external.cisco.com
Subject: RE: IPCOMP and IPSEC
In-Reply-To: <3.0.2.32.19980529133701.006b1dd8@airedale.cisco.com>
Message-ID: <Pine.SOL.3.91.980530165844.3686A-100000@yaway.gsl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

> >comparing different compression algorithms in a stateful environment; 
>                                                  ^^^^^^^^ how comes?

Looking at the queue state of a typical Internet router, there is next to 
no correlation of any packets within the queue.  Therefore, maintaining a 
state (or history) is not of significant value because the patterns are 
random.  For instance, I rarely have two packets belonging to the same 
flow (or session) in my queue at the same time.

Now, if one were to FTP some files, one at a time, and have no other 
concurrent activity, then the queue serving the local segment would 
contain only packets from the single session.  These packets would be 
highly correlated and therefore should compress relatively well (assuming 
that they are not already compressed).

>From a packet compression perspective, the Internet is a stateless 
environment.  Now if one were to build VPN's with IPSEC, then one might 
achieve better compression ratios.

-eric