home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 17174 < prev    next >
Encoding:
Text File  |  1992-11-22  |  4.5 KB  |  90 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!umn.edu!csus.edu!netcom.com!gerg
  3. From: gerg@netcom.com (Greg Andrews)
  4. Subject: Re: PEP over SLIP?
  5. Message-ID: <1992Nov23.082126.29825@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1992Nov16.213034.27895@eos.arc.nasa.gov> <1992Nov20.083723.11984@netcom.com> <sjsv1fo@rhyolite.wpd.sgi.com>
  8. Date: Mon, 23 Nov 1992 08:21:26 GMT
  9. Lines: 79
  10.  
  11. vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  12. >In article <1992Nov20.083723.11984@netcom.com>, gerg@netcom.com (Greg Andrews) writes:
  13. >> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  14. >> >
  15. >> >I just don't see how SLIP/PEP can "degrade under [increased] offered
  16. >> >load."  With increased load, the modems turn the line around less
  17. >> >frequently, thereby wasting less bandwidth.  "Collapse" would require
  18. >> >just the opposite, decreased effecency with increased offered load
  19. >> >
  20. >> 
  21. >> If Bob's "offered load" is multiple TCP sessions, he could again be
  22. >> describing a link that's returning multiple ACKs to the modem before
  23. >> the line turns around.  If the SLIP packets were small, the results
  24. >> would probably be as bad as he indicates.
  25. >> ...
  26. >
  27. >I do not see this.
  28. >
  29. >The word "collapse" is often reserved for situations where a small
  30. >increase in offered load results in a substantial decrease in
  31. >throughput.  The system, whether a computer virtual memory system
  32. >during "thrashing" or ethernet in "collision collapse" or rush-hour
  33. >traffic in gridlock becomes all but useless in "collapse."
  34. >
  35. >As far as PEP modems are concerned, a high offered load is just a lot
  36. >of bytes.  It does not matter to them whether those bytes are for 1 TCP
  37. >stream or a thousand.  The modems will be presented with a high load in
  38. >both directions, and will switch to large packets.  Once they have
  39. >switched to large packets, the modem-to-modem link does not "collapse"
  40. >any more, does it?
  41. >
  42.  
  43. Before I try to answer your last question, let me admit that I didn't
  44. fully understand the use of the word "collapse" in this context.  I'm
  45. vaguely familiar with data flow patterns over SLIP, but I'm probably not
  46. aware of the more subtle details.  My response may have been about a
  47. different situation than the one you and Bob have in mind, confusing the
  48. picture rather than making it clearer...
  49.  
  50. The type of session I had in mind is where there are multiple TCP sessions
  51. passing through the same SLIP link.  With my vague understanding of how
  52. SLIP works, I pictured each TCP session returning ACKs independently of
  53. (and asynchronously from) the other sessions.  Perhaps I erred in this,
  54. but if not, then the additional ACKs could conspire to increase PEP's
  55. overhead in the reverse direction.
  56.  
  57. Now for the question you asked.  In theory, Yes, the link can "collapse"
  58. further after the modem begins using Long packets in the reverse direction.
  59. Remember that the more packets the modem sends in the reverse direction,
  60. the more time is stolen away from the forward direction.  If the modem has
  61. enough data (ACKs) to overflow one Long packet, it will send two.  If it
  62. has more data than will fit into two, it will send three, and so on up
  63. to the maximum of 12 Long packets in a single burst.  Generally, I would
  64. not expect ACKs to fill the modem up enough to force additional Longs, but
  65. it's not impossible.
  66.  
  67. Also, looking back on your first article (still quoted above), I think
  68. I see a misconception where you say "...the modems turn the line around
  69. less frequently, thereby wasting less bandwidth."  Bandwidth is wasted
  70. far less by a line turnaround than it is by transmitting something back
  71. in the reverse direction.  If you count the number of line turnarounds
  72. per second, you'll think returning a Long packet is good, as the modems
  73. turn the line around less often.  However, extend this concept a little
  74. further and the problem will rear its head.  Return 12 Long packets and
  75. you'll have enormously reduced the number of line turnarounds, but your
  76. throughput will drop through the floor.  It's not the number of line
  77. turnarounds that's important in PEP.  It's the proportion of forward
  78. transmit time to reverse transmit time.
  79.  
  80. (Sorry if you're already aware of all this - I'm just trying to
  81. clear up some things that appeared to be misleading...)
  82.  
  83.  
  84. -- 
  85. /u3/gerg/signatures/sig.carp-pyramid
  86. Greg Andrews  --  gerg@netcom.com  --  ...!{claris,amdahl}!netcom!gerg
  87.  
  88. ObGuindon:  Carp pyramid schemes are fun, but remember to enter
  89.             late.  That way, you'll get stuck with fewer carp.
  90.