That's what I thought so. I believe I understood correctly (or I think I
did)
Thx
Thomas
----- Original Message -----
From: "Goodwin, Dustin T [IT]" <dustin.t.goodwin@ssmb.com>
To: "'Thomas Kernen'" <tkernen@deckpoint.ch>;
<cisco-nsp@puck.nether.net>
Sent: Monday, March 04, 2002 4:33 PM
Subject: RE: [nsp] Frame relay and tcp/rtp header compression
> The routers on either end of frame relay pvc perform the header
> compression/decompression. The frame switches in between are not
involved.
> The compression is hop by hop, meaning the header may go through the
> compress decompress cycle multiple times depending on the number of
wan
> links in the path that have header compression enabled. The
compression
> process is lossless so multiple compress decompress cycles do not hurt
data
> integrity. But the header compression process is costly CPU-wise and
can
> introduce extra delay and jitter into the traffic stream.
>
> -----Original Message-----
> From: Thomas Kernen [mailto:tkernen@deckpoint.ch]
> Sent: Monday, March 04, 2002 4:20 PM
> To: cisco-nsp@puck.nether.net
> Subject: [nsp] Frame relay and tcp/rtp header compression
>
>
>
> I've been debating rtp and tcp header compression over frame-relay
> interfaces. The way I understand this is that the a frame-relay
network
> built on Cisco boxes that are acting as the frame relay network
switches
> simply look into the frame header for routing the packet and the
actual
> tcp/rtp header is not taken into account therefore allowing one to run
> tcp/rtp header compression on PtP links accross such as network
without
> enabling tcp/rtp header compression on each path.
>
> Is this correct or am I missing something?
>
> Thomas
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:35 EDT