[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposal for IP Peer protocol
Thanks John, I was expecting some action on this issue :). I've just been
scanning RFC 2507 (IP Header compression. Section 11 seems to suggest that
there is a solution to re-ordering) - you drop some efficiency, but it still
works, apparently. It does not appear to 'still work' host to host though,
since the need to add an extra IP header cancels the advantage of
compressing the payload - a TCP/IP one-byte packet would actually get one
byte bigger (IP2(20)IPCOMP(4)IP1/TCP(17)Data(1))
Comments from the 'Lulea University' authors of IP Header Compression on the
suitability of header compression for the payload of IPSEC tunnels and IP
peer-to-peer across the Internet?
Thanks, Steve.
-----Original Message-----
From: John Shriver [mailto:jas@shiva.com]
Sent: Wednesday, June 09, 1999 5:12 PM
To: Stephen.Waters@cabletron.com
Cc: pkoning@xedia.com; ipsec@lists.tislabs.com;
ippcp@external.cisco.com; Stephen.Waters@cabletron.com
Subject: Re: Proposal for IP Peer protocol
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.