home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 764 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  1.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!isi.edu!finn
  2. From: finn@isi.edu (Greg Finn)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Re: Is ATM well suited to LANs?
  5. Message-ID: <22934@venera.isi.edu>
  6. Date: 21 Nov 92 23:04:09 GMT
  7. References: <1992Nov19.104113.1@tnclus.tele.nokia.fi>
  8. Sender: news@isi.edu
  9. Reply-To: finn@dalek.isi.edu (Greg Finn)
  10. Organization: USC-Information Sciences Institute
  11. Lines: 22
  12.  
  13. In article <13605@grayt> grayt@Software.Mitel.COM (Tom Gray) writes:
  14.  
  15. >Indeed if the application on the WAN is to allow the user to edit
  16. >the video stream, why restrict it to MPEG when JPEG is much more
  17. >suitable. Perhaps this will show you why ATM is designed for end to end
  18. >applications and negotiations of protocols.
  19.  
  20.     ATM is not designed for negotiations of protocols.  ATM is a
  21. data-link layer protocol.  Negotiation of options and encoding
  22. protocols is a much higher layer function that occurs usually in the
  23. session and presentation layers.
  24.  
  25.     The choice of a coding standard is application driven.  MPEG
  26. is designed for motion picture coding, hence its name.  JPEG was
  27. designed for stills.  You feel the need for JPEG frame by frame to
  28. decrease artifacts - fine.  You pay for greater bandwidth consumption.
  29. This has nothing to do with ATM unless you are arguing that ATM can
  30. send JPEG packets more easily than MPEG packets.  That is a pretty
  31. strange argument to make if it is supposed to favor ATM.
  32. --
  33. Gregory Finn    (310) 822-1511
  34. Information Sciences Institute, Marina Del Rey, CA 90292
  35.