home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 229 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.2 KB  |  46 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!mcsun!dxcern!brian
  3. From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
  4. Subject: Re: Question
  5. Message-ID: <1992Jul22.130820.11652@dxcern.cern.ch>
  6. Organization: CERN European Lab for Particle Physics
  7. References: <1992Jul16.150120.28047@walter.bellcore.com> <21956@venera.isi.edu> <1992Jul17.114053.1@research.ptt.nl> <1992Jul17.160015.7158@dxcern.cern.ch> <1992Jul18.154155.1@research.ptt.nl>
  8. Date: Wed, 22 Jul 1992 13:08:20 GMT
  9. Lines: 35
  10.  
  11. In <1992Jul18.154155.1@research.ptt.nl> walvdrk_r@research.ptt.nl (Kees van der Wal) writes:
  12.  
  13. >In article <1992Jul17.160015.7158@dxcern.cern.ch>, brian@dxcern.cern.ch (Brian
  14. >Carpenter   CERN-CN) writes: 
  15.  
  16. >>>So the question is "who makes those small 48-56 byte packets? And why is it the 
  17. >>>that size. Is there some kind of "natural" packet size that peaks around those 
  18. >>>values? It's hard for me to believe that.
  19.  
  20. >> Anyone who histograms data packet sizes finds two peaks, one around
  21. >> 40-50 bytes and one at some higher value - often 512 bytes, sometimes
  22. >> 1500 (i.e. full Ethernet packets). Even when running on FDDI which
  23. >> allows 4Kbyte packets it is very difficult to persuade typical software
  24. >> to use more than 512 bytes.
  25.  
  26.  
  27. >I don't argue against the argument that nowadays protocols may produce this
  28. >size of packets. With "one step back" I meant that we have to re-think what
  29. >we're doing with the protocols that eventually are supposed to perform some
  30. >"task". That "task" i.e. the transport of a 1Mbyte digitized picture is then
  31. >what I see as "the driving force". We'll have to design systems and protocols
  32. >that support that "task" rather than restricting ourselves for eternity to
  33. >protocols that don't fit. 
  34.  
  35. >If system designers are desgning ATM equipment that delivers ATM cells with a 
  36. >cell loss probility in the order of 10E-8, it doesn't make sense to me to use a 
  37. >protocol that expects an ACK for every few bytes that is sends.
  38.  
  39. Kees, when typing or moving my mouse (both on an X terminal), I don't
  40. know about the protocol, but *I* expect an ACK every few bytes, i.e.
  41. the X client half a kilometre away is supposed to respond to me. So yes,
  42. as several people have said, small packets are intrinsic to computer-
  43. generated traffic.
  44.  
  45.  -- Brian
  46.