home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 17086 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.8 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!olivea!sgigate!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: PEP over SLIP?
  5. Message-ID: <sjsv1fo@rhyolite.wpd.sgi.com>
  6. Date: 20 Nov 92 17:32:50 GMT
  7. References: <1992Nov16.213034.27895@eos.arc.nasa.gov> <1992Nov20.083723.11984@netcom.com>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 55
  10.  
  11. In article <1992Nov20.083723.11984@netcom.com>, gerg@netcom.com (Greg Andrews) writes:
  12. > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  13. > >> 
  14. > >Are you sure?  I thought the magic number was 12 bytes.
  15. > >12 is much larger than any reasonable VJ-compressed ACK.
  16. > 
  17. > Perhaps Bob is talking about situations where small SLIP packets are
  18. > being used, so the receiver is able to return several ACKs to the modem
  19. > before the line turns around?
  20.  
  21. That could be.  It could even be with larger TCP/IP/SLIP packets if the
  22. receiver does not deliver the ACKs smoothly to the modem.
  23.  
  24. >...
  25. > >
  26. > >I just don't see how SLIP/PEP can "degrade under [increased] offered
  27. > >load."  With increased load, the modems turn the line around less
  28. > >frequently, thereby wasting less bandwidth.  "Collapse" would require
  29. > >just the opposite, decreased effecency with increased offered load
  30. > >
  31. > 
  32. > If Bob's "offered load" is multiple TCP sessions, he could again be
  33. > describing a link that's returning multiple ACKs to the modem before
  34. > the line turns around.  If the SLIP packets were small, the results
  35. > would probably be as bad as he indicates.
  36. > ...
  37.  
  38. I do not see this.
  39.  
  40. The word "collapse" is often reserved for situations where a small
  41. increase in offered load results in a substantial decrease in
  42. throughput.  The system, whether a computer virtual memory system
  43. during "thrashing" or ethernet in "collision collapse" or rush-hour
  44. traffic in gridlock becomes all but useless in "collapse."
  45.  
  46. As far as PEP modems are concerned, a high offered load is just a lot
  47. of bytes.  It does not matter to them whether those bytes are for 1 TCP
  48. stream or a thousand.  The modems will be presented with a high load in
  49. both directions, and will switch to large packets.  Once they have
  50. switched to large packets, the modem-to-modem link does not "collapse"
  51. any more, does it?
  52.  
  53. The latencies of interactive SLIP traffic over a pair of PEP modems
  54. running large packets are kind of painful.  As long as the offered load
  55. is not above the modems throughput, that latency will be about 7
  56. seconds (3500 byte buffers in the modems) plus any host queue
  57. time--call it around 10 seconds.
  58.  
  59. These kinds of latencies happen in other circumstatnces.  For example,
  60. take a pair of Cisco routers and a 56K line.  Run a TCP based file
  61. transfer over the link between a pair of computers with 60K TCP
  62. windows.  At the same time, try to do some interactive stuff.
  63.  
  64.  
  65. Vernon Schryver,  vjs@sgi.com
  66.