IETF Logo Mail Archive

RE: IPCOMP and IPSEC

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

Return-Path: edean@gsl.net
Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08188 for <ippcp-archive-file@ftp-eng.cisco.com>; Sat, 30 May 1998 14:06:58 -0700 (PDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by rhine.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05760 for <extdom.ippcp@aliashost.cisco.com>; Sat, 30 May 1998 14:06:41 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA15796 for <ippcp@external.cisco.com>; Sat, 30 May 1998 14:05:26 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id OAA06310 for <ippcp@external.cisco.com>; Sat, 30 May 1998 14:05:20 -0700 (PDT)
Received: from nic.gip.net(204.59.152.195) by proxy3.cisco.com via smap (V2.0) id xma006308; Sat, 30 May 98 21:05:19 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 QAA07376; Sat, 30 May 1998 16:55:13 -0400 (EDT)
Received: (from edean@localhost) by yaway.gsl.net (8.8.3/8.7.5) id RAA03704; Sat, 30 May 1998 17:15:32 -0400 (EDT)
Date: Sat, 30 May 1998 17:15:32 -0400
From: Eric Dean <edean@gip.net>
To: Stephen Waters <Stephen.Waters@digital.com>
cc: Avram Shacham <shacham@cisco.com>, ipsec@tis.com, ippcp@external.cisco.com
Subject: RE: IPCOMP and IPSEC
In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com>
Message-ID: <Pine.SOL.3.91.980530171111.3686B-100000@yaway.gsl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

> 
> 	I've worked full-time from home for a few years now - using a
> direct dial ISDN link over which the 
> 	average compression seems to stay stubbornly on 2:1.  I'll load
> up the IPPCP image and share the results
> 	once I have a decent sample.  Not a bad case study considering
> the use of IPPCP in the short term -
> 	i.e. remote-access for laptops/SOHOs.
> 

For reasons stated in my previous message, as you move closer to the core 
of the Internet where traffic is highly uncorrelated, you will find 
relatively poor cases for stateful compression.  (I am aware that 
stateless compression is the proposed method for IPPCP.)

As you move far to the edge of the Internet, at the modem layer, you find 
that packets are highly correlated and tend to benefit from current stateful 
compression methodologies.

-eric

v2.23.0 | Report a Bug | By Email