home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / ppp / 731 < prev    next >
Encoding:
Text File  |  1992-08-27  |  5.0 KB  |  104 lines
  1. Newsgroups: comp.protocols.ppp
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!mstar!mstar!bob
  3. From: bob@MorningStar.Com (Bob Sutterfield)
  4. Subject: Re: Why is PPP better than SLIP
  5. In-Reply-To: pankaj@bass.bu.edu's message of 27 Aug 92 16: 13:52 GMT
  6. Message-ID: <BOB.92Aug27180314@volitans.MorningStar.Com>
  7. Followup-To: comp.protocols.ppp
  8. Sender: news@MorningStar.Com
  9. Nntp-Posting-Host: volitans.morningstar.com
  10. Organization: Morning Star Technologies
  11. References: <94745@bu.edu>
  12. Date: Thu, 27 Aug 1992 22:03:21 GMT
  13. Lines: 89
  14.  
  15. In article <94745@bu.edu> pankaj@bass.bu.edu (Pankaj Tyagi) writes:
  16.    Currently I'm using on the PC side SLIP provided by Chameleon with
  17.    a 8250 UART talking to a Racal-Milgo Modem V42bis. That modem is
  18.    capable of giving sustained 14.4kbs and 38.2kbs burst. Using SLIP
  19.    my throughput (that is counting only usable data, not counting
  20.    headers and retransmission) is around 8kbs. which I believe is
  21.    pretty good, given the fact that the database is not physically
  22.    located in the same place as the terminal server but is about 250
  23.    miles away connected to the terminal server through a router and
  24.    leased line.
  25.  
  26. Between SPARCstation-1s connected via Telebit T3000/Worldblazers
  27. (V.32bis/V.42/V.42bis, 38400 DTE) over long-distance lines (Columbus
  28. to Minneapolis), running PPP with "VJ" TCP header compression, I see
  29. FTP throughput like 2.4-2.7 Kbytes/sec for /vmunix and 2.8-3.2
  30. Kbytes/sec for /usr/dict/words.  That's about 3 times your throughput.
  31. Offhand, I'd point to your 8250 as a bottleneck.
  32.  
  33.    Given this how much can PPP improve performance or what value can
  34.    it add to the whole process.
  35.  
  36. There's no performance difference between SLIP and PPP.  PPP has three
  37. more bytes of per-packet protocol overhead, which turns a typical
  38. 5-byte telnet packet into 8 bytes, so your interactive latency is
  39. imperceptibly and unmeasurably higher with PPP than with SLIP.  A
  40. typical PPP MTU (maximum packet size) is 1500, while SLIP is typically
  41. 1006, so those extra three bytes could be amortized over a larger
  42. amount of user data, but three bytes are down in the noise of 1500.
  43.  
  44.    As a side note, I have before me a recent article in CW titled
  45.    "Remote user get TCP/IP sans LAN" which goes on to describe this
  46.    prduct called "SupperPPP" whic is "...layered over the Microsoft
  47.    Corp. Windows operating environment and Frontier's TCP/IP or any
  48.    industry-standard Open System Interconnect communications
  49.    protocols."
  50.  
  51. That's great!  Customers are asking us all the time to recommend a PPP
  52. for that environment.  We'd do it ourselves, but we are UNIX
  53. adherents, and not of the MS-Windows faith :-)
  54.  
  55.    This product, it seems provides TCP/IP functionality over serial
  56.    lines and it "adds error correction, retransmission and speed to
  57.    the older SLIP for remote TCP/IP networking..."
  58.  
  59. If Super-PPP is the IETF PPP WG's RFC-1331/1332 PPP, then it doesn't
  60. have error correction or retransmission.  PPP has error detection, not
  61. correction; PPP drops bad packets and relies upon upper layers (UDP or
  62. TCP) for retransmission.
  63.  
  64. There are IETF PPP WG subcommittees working on error correction and
  65. retransmission, but there aren't even any draft standards yet.  It's
  66. all still research and exploratory stuff, nowhere near ready to call a
  67. product nor a standard.
  68.  
  69.    "... speedwise PPP could translate into a tenfold improvement over
  70.    SLIP"
  71.  
  72. Actually, that's attributed to someone from HDS, a company that
  73. recently started shipping "its own version of PPP" with its X
  74. terminals.  The article says they started shipping PPP "after rigorous
  75. performance testing of PPP and SLIP," but I haven't been able to
  76. reproduce their results.
  77.  
  78.    NOW is that really true. I mean I thought I was getting almost all
  79.    I could bet from my POTS line using SLIP. Can it really be true
  80.    that PPP is really that much superior to SLIP?
  81.  
  82. That's marketing hype.  Don't believe it.  They're constrained, like
  83. everyone else, by (1) the amount of user data that must traverse the
  84. link, and (2) current modem technology.  Since it's the same amount of
  85. user data, and since they're presumably using the same type modem,
  86. there's no difference between PPP and SLIP.
  87.  
  88. Actually, come to think of it, there's one way in which they might say
  89. that a PPP implementation shows a many-fold reduction in the number of
  90. bits that traverse the wire.  If the SLIP doesn't do RFC-1144 "VJ" TCP
  91. header compression, and if the PPP does, then the size of a typical
  92. transmitted telnet frame will decrease from forty-something to 8.
  93. That's a factor of about five, but it doesn't affect throughput, only
  94. interactive latency.  And plenty of SLIPs out there do VJ, they're
  95. called CSLIP.  
  96.  
  97. If that's the comparison, then it's totally invalid.  If they had
  98. compared a VJ-capable PPP with a VJ-capable SLIP, they would have seen
  99. no performance difference at all.  It's not a difference between PPP
  100. and SLIP, it's a difference between using VJ and not using VJ.
  101.  
  102. Sorry to rant.  PPP is subject to enough misunderstanding without
  103. having a dose of misleading marketing hype thrown in too.
  104.