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

Re: compression and encryption

To: minshall@ipsilon.com
Subject: Re: compression and encryption
From: Phil Karn <karn@qualcomm.com>
Date: Wed, 13 Nov 1996 17:42:07 -0800 (PST)
CC: smb@research.att.com, ipsec@tis.com
In-reply-to: <199611130138.RAA00770@red.ipsilon.com> (message from Greg Minshall on Tue, 12 Nov 1996 17:38:41 -0800)
Sender: owner-ipsec@ex.tis.com

>I think there continue to be protocols (RTP comes to mind) in which the 
>header:payload ratio tends to be too high (even on 28.8 links).  I'm not 
>arguing that we need compression in ipsec; i'm just making the point that 
>*compression* isn't necessarily a dead end, even in today's internet.

In its present form, VJ header compression only works for
TCP/IP. There are some proposals for UDP/IP header compression, but I
don't think they're widely deployed.

The fundamental problem with any real time application over IP is the
hard tradeoff that has to be made between header overhead and
store-and-forward delay. This is a very difficult tradeoff, and
systems where it is really important (like digital cellular) are
designed from the ground up along very different lines.

It may well be that it will never be possible to build one integrated
network that can handle both realtime and nonrealtime traffic with an
acceptable degree of efficiency and delay performance for both.

Phil

References:

Re: compression and encryption

From: Greg Minshall <minshall@ipsilon.com>

Prev by Date: Re-keying RTP streams
Next by Date: Combined ESP transform
Next by thread: Re: proposed IPSEC changes/extensions
Index(es):
- Main
- Thread