[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for IP Peer protocol

To: Stephen.Waters@cabletron.com
Subject: Re: Proposal for IP Peer protocol
From: John Shriver <jas@shiva.com>
Date: Wed, 9 Jun 1999 12:12:06 -0400
CC: pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com, Stephen.Waters@cabletron.com
In-reply-to: <29752A74B6C5D211A4920090273CA3DC4BBCE8@new-exc1.ctron.com>(Stephen.Waters@cabletron.com)
Sender: owner-ipsec@lists.tislabs.com

The Van Jacobsen header compression relies on two things that PPP
provides and IPsec "tunnels" don't provide:

1. Freedom from reordering of packets.  (The anti-replay field is not
normally used to prevent reordering.)

2. The receiver gets information about lost (bad CRC) frames.  (This
is more of a hint, but still important.)

Thus, the VJ compression relies very strongly on these characteristics
of PPP.  By the time you provide the same QoS in IPsec, you will be
close to re-inventing TCP.

Follow-Ups:

Re: Proposal for IP Peer protocol

From: Gabriel Montenegro <gab@Eng.Sun.Com>

References:

RE: Proposal for IP Peer protocol

From: "Waters, Stephen" <Stephen.Waters@cabletron.com>

Prev by Date: Re: can ISAKMP cookies be zero?
Next by Date: RE: Proposal for IP Peer protocol
Prev by thread: RE: Proposal for IP Peer protocol
Next by thread: Re: Proposal for IP Peer protocol
Index(es):
- Main
- Thread