home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 765 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!nsisrv!Pt!wainner
  2. From: wainner@Pt.hq.af.mil (Scott Wainner)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Re: Computers dont like ATM?
  5. Message-ID: <wainner.722408411@hq>
  6. Date: 22 Nov 92 05:00:11 GMT
  7. References: <1992Nov18.025754.14749@trl.oz.au>
  8. Organization: Headquarters Air Force, The Pentagon Washington, DC
  9. Lines: 49
  10.  
  11. lampard@titan.trl.OZ.AU (Greg Lampard) writes:
  12.  
  13. > Paul Green statements: he mentioned that 53 byte cells are too small
  14. >for computers (or words to that effect).  His claim was that small
  15. >packets are good for delay-sensitive applications, but they make a lot
  16. >of unnecessary work for the computer that has to receive them, since it
  17. >has to process a header every 53 bytes, and often just stores the cell
  18. >to build up a larger packet for the next layer up the protocol stack.
  19.  
  20. It is true that 53 bytes is a nuisance to the computer.  The computer
  21. industry proposed a 69 byte cell (ie 64 byte payload) but a compromise
  22. was made with Europe which wanted a 32 byte cell.  So, we get a 44 or
  23. 48 byte payload depending on the AAL used.  I think 48 seems logical
  24. since it's a multiple of 8 bytes.  The reason for the fixed cell size is
  25. to minimize buffer requirements in the switch.  Since all the cells are
  26. the same length, the switch can process the cells in "parallel".  The
  27. other benefit of fixed size cells is that it may be implemented in 
  28. hardware that will perform frame reconstruction must faster than
  29. software processes.
  30.  
  31. >He also seemed to be suggesting that this storage and retrieval process
  32. >could become a bottleneck (at 100s of Mbit/s?) because of the limitations 
  33. >of memory bandwidth.  He was advocating variable length packets (an idea
  34. >called PTM - packet transfer mode - that IBM has proposed), because it
  35. >puts the complexity in the switch rather than in the receiving
  36. >terminal. 
  37.  
  38. Exactly, we're trying to make the switch faster by eliminating the
  39. protocol processing and implementing the switching in hardware.
  40.  
  41. >From this, his conclusion was (I think) that ATM is good for switching
  42. >voice traffic, but not so good for computer networks.  This seems to go 
  43. >against what's actually happening, with people building ATM LANs while 
  44. >telcos hang back, not sure if ATM is the right way to go.
  45.  
  46. I think ATM has great merits but I'm not quite sure how fault tolerance
  47. will be introduced in the network since we're using VCIs and VPIs to 
  48. perform the routing. Is this static once the call setup is complete?
  49. How does the switch know to reroute a failed connection without forcing
  50. the application to "reopen" the path.
  51.  
  52.  
  53. >Greg.
  54. >g.lampard@trl.oz.au             | communications engineer.
  55.  
  56. Scott Wainner
  57. swainner@tasc.com.
  58. Communications Systems Engineer
  59.  
  60.