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
- Re: IPCOMP and IPSEC Daniel Harkins
- IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Naganand Doraswamy
- Re: IPCOMP and IPSEC Saroop Mathur
- Re: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Marc Hasson
- RE: IPCOMP and IPSEC Avram Shacham
- FW: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Avram Shacham
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Stephen Kent
- RE: IPCOMP and IPSEC Robert Moskowitz
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Paul Koning