home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 248 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.7 KB
  1. Path: sparky!uunet!olivea!decwrl!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Re: [packet sizes]
  5. Message-ID: <nodr79s@rhyolite.wpd.sgi.com>
  6. Date: 25 Jul 92 19:15:26 GMT
  7. References: <2796@ucl-cs.uucp> <1992Jul24.195100.20475@nntp.uoregon.edu>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 45
  10.  
  11. In article <1992Jul24.195100.20475@nntp.uoregon.edu>, jqj@duff.uoregon.edu (JQ Johnson) writes:
  12. > It's not clear to me that VJ compression is really appropriate for ATM
  13. > nets.  VJ compression, as I understand it, gets most of its power by
  14. > observing that the path over serial circuits is typically used (mostly)
  15. > for a single TCP bidirectional stream at a time. Hence you can predict the
  16. > next packet, and encode the whole header essentially as a stream
  17. > identifier plus a single bit that says "the next packet is in fact the one
  18. > you are expecting", with only a small percentage of your packets missing
  19. > the cache of current streams and having to be encoded long-form.  VJ
  20. > compression doesn't seem to me to do as much good if the physical channel
  21. > is muxing lots of independent packet streams.  For example, it's not of
  22. > much use, I don't believe, on a high speed path between two routers busy
  23. > with lots of low-speed connections.
  24. > 
  25. > I'd be interested in the comments of other people more familiar with
  26. > TCP/IP compression schemes than I am.  How good IS the match between
  27. > VJ compression and ATM?
  28.  
  29.  
  30. No, VJ compression works fine for several simultaneous virtual
  31. circuits.  Any real TCP network often has more than one simultaneously
  32. active circuit even over a SLIP line.  That's why anyone sitting down
  33. to invent something like VJ compression without looking at the standard
  34. or his code does just as he did, and includes some kind of circuit or
  35. session or context ID in the compressed header.
  36.  
  37. You can have as many simultaneous VJ-like-compressed circuits as you
  38. wish to devote resources at the ends and bits in the compressed
  39. header.
  40.  
  41. "VJ-compression" is not really about "compression."  It is more about
  42. "header prediction", with the near side sending only those bits that
  43. the far side might not be able to predict.
  44.  
  45. I wonder about doing VJ-compression at full speed over ATM.  Some XTP
  46. ideas included finding the right "context" as the head of the packet is
  47. received, and using that "context" to forward, ACK, etc the packet,
  48. sometimes before you see the trailer.  That does not seem trivial at
  49. gigabit rates on a stream of tiny packets without some special
  50. silicon.  Last I knew, PEI was doing well with continuous streams of
  51. minimal sized UDP and TCP packets at FDDI rates.  I do not know how
  52. they are doing at high speed.
  53.  
  54.  
  55. Vernon Schryver,  vjs@sgi.com
  56.