NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/cellrel/243

Internet Message Format | 1992-07-25 | 1.6 KB

Path: sparky!uunet!sun-barr!cs.utexas.edu!swrinde!sdd.hp.com!wupost!micro-heart-of-gold.mit.edu!uw-beaver!news.u.washington.edu!nntp.uoregon.edu!nntp.uoregon.edu!jqj
From: [e-mail] (JQ Johnson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: [packet sizes]
Message-ID: <[e-mail]>
Date: 24 Jul 92 19:51:00 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: University of Oregon Network Services
Lines: 23

It's not clear to me that VJ compression is really appropriate for ATM
nets.  VJ compression, as I understand it, gets most of its power by
observing that the path over serial circuits is typically used (mostly)
for a single TCP bidirectional stream at a time. Hence you can predict the
next packet, and encode the whole header essentially as a stream
identifier plus a single bit that says "the next packet is in fact the one
you are expecting", with only a small percentage of your packets missing
the cache of current streams and having to be encoded long-form.  VJ
compression doesn't seem to me to do as much good if the physical channel
is muxing lots of independent packet streams.  For example, it's not of
much use, I don't believe, on a high speed path between two routers busy
with lots of low-speed connections.

I'd be interested in the comments of other people more familiar with
TCP/IP compression schemes than I am.  How good IS the match between
VJ compression and ATM?

--
JQ Johnson
Director of Network Services        Office: 250E Computing Center
Computing Center            Internet: [e-mail]
University of Oregon            voice:    [phone]
Eugene, OR  97403-1212            fax: [phone]