home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 17074 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.7 KB  |  63 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!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: <1992Nov20.083723.11984@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1992Nov16.213034.27895@eos.arc.nasa.gov> <BOB.92Nov18175532@volitans.MorningStar.Com> <shvdb6c@rhyolite.wpd.sgi.com>
  8. Date: Fri, 20 Nov 1992 08:37:23 GMT
  9. Lines: 52
  10.  
  11. vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  12. >In article <BOB.92Nov18175532@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
  13. >> ...
  14. >> 
  15. >> Even with only a single FTP stream traversing the link in one
  16. >> direction, the returning TCP ACKs (even VJ-compressed) usually require
  17. >> a large PEP packet,
  18. >
  19. >Are you sure?  I thought the magic number was 12 bytes.
  20. >12 is much larger than any reasonable VJ-compressed ACK.
  21. >
  22.  
  23. Perhaps Bob is talking about situations where small SLIP packets are
  24. being used, so the receiver is able to return several ACKs to the modem
  25. before the line turns around?
  26.  
  27. >
  28. >>                     and thus trigger a carrier turnaround.
  29. >
  30. >I've seen plenty of strange turnarrounds--rather, heard them with the
  31. >speaker on.  But only during light loading.  The worst case I know of
  32. >is `ping`.  The ICMP ECHO's seem to hit the modems at just the wrong
  33. >times, causing them to waste lots of time switching packet sizes and
  34. >turning the line around.
  35. >
  36. >> Performance (both throughput and latency) degrades under increased
  37. >> offered load much more catastrophically with PEP than with V.32bis.
  38. >
  39. >Are you sure?  From my experience, PEP does best when loaded.
  40. >It does worst with light traffic, such as interactive stuff.
  41. >
  42. >I just don't see how SLIP/PEP can "degrade under [increased] offered
  43. >load."  With increased load, the modems turn the line around less
  44. >frequently, thereby wasting less bandwidth.  "Collapse" would require
  45. >just the opposite, decreased effecency with increased offered load
  46. >
  47.  
  48. If Bob's "offered load" is multiple TCP sessions, he could again be
  49. describing a link that's returning multiple ACKs to the modem before
  50. the line turns around.  If the SLIP packets were small, the results
  51. would probably be as bad as he indicates.
  52.  
  53. However, with a link that can send large packets through the modems,
  54. only one or two ACKs would be waiting when the modems turn the line
  55. around.  No extra overhead is generated.
  56.  
  57.  
  58. -- 
  59.  .------------------------------------------------------------------.
  60.  |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
  61.  |                 |   Internet: gerg@netcom.COM                    |
  62.  `------------------------------------------------------------------'
  63.