home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12432 < prev    next >
Encoding:
Text File  |  1992-08-23  |  3.2 KB  |  72 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!wupost!gumby!destroyer!terminator!honey
  3. From: honey@citi.umich.edu (Peter Honeyman)
  4. Subject: Re: Modems, compression, and SLIP or PPP (was Re: Using Telebit PEP with SLIP)
  5. Message-ID: <1992Aug23.203750.22670@terminator.cc.umich.edu>
  6. Sender: news@terminator.cc.umich.edu (Usenet Owner)
  7. Reply-To: honey@citi.umich.edu
  8. Organization: Center for Information Technology Integration, Univ of Michigan
  9. References: <1992Aug23.202309.22443@terminator.cc.umich.edu>
  10. Date: Sun, 23 Aug 1992 20:23:09 GMT
  11. Lines: 59
  12.  
  13. sorry about the earlier, abbreviated version of this article.
  14. i sure wish xrn would let me cancel ... oh well.
  15.  
  16. Bob Sutterfield writes:
  17. |> Whether you use V.42bis depends upon your application.  It will only
  18. |> very rarely (if at all) decrease your throughput, likewise latency, so
  19. |> it's probably safe to turn it on and leave it on for most purposes.
  20.  
  21. in experiments run here, we have seen very high latencies due to v.42
  22. and v.42bis.  (but since we use the network more for file transfer
  23. than interactive traffic, we do leave them on, as bob suggests.)
  24.  
  25. |> A typical PPP frame is exactly three bytes larger than a typical SLIP
  26. |> frame.  This expands a typical VJ-compressed telnet packet from five
  27. |> bytes to eight.  So far as I can tell, the difference is unmeasurable
  28. |> and imperceptible.
  29.  
  30. a typical vj-compressed telnet packet is four bytes, not five -- here
  31. are three quotes from rfc 1144, "compressing tcp/ip headers for
  32. low-speed serial links", by van jacobson:
  33.  
  34. from section 1 (introduction): the average compressed header is 3 bytes
  35.  
  36. from section 3.1 (the basic idea): Recognizing a couple of special
  37. cases special cases will get us three byte headers for the two most
  38. common cases---interactive typing traffic and bulk data transfer
  39.  
  40. from section 3.2.2 (compressed packet format): compressed terminal
  41. traffic usually looks like (in hex):  0B c c d, where the 0B indicates
  42. case (1), c c is the two byte TCP checksum and d is the character
  43. typed.
  44.  
  45. |> Few connections are error-free.  A V.32bis/V.42/V.42bis modem, clocked
  46. |> at 38400 or better, can easily deliver bits fast enough to overwhelm
  47. |> primitive serial I/O interfaces such as are found in many popular UNIX
  48. |> systems.  Those UART overruns are manifested as line errors, which
  49. |> PPP's 16-bit CRC (not a checksum!) will almost always catch, so that
  50. |> the PPP can drop the damaged packet before passing it up to IP.  This
  51. |> will save your bacon if you're running non-UDP-checksummed NFS, even
  52. |> over a V.42 or MNP4 modem.
  53.  
  54. there are many errors here.
  55.  
  56. my home computer is an ibm rt, three or so mips, with a run of the
  57. mill 16550 async card.  i run the interface at 57,600.  uart overruns
  58. are infrequent -- way less than 1%.  if my dinky, five-year old unix
  59. box can do it, so can yours.
  60.  
  61. crc *is* a checksum -- that's what the second c stands for.
  62.  
  63. i fail to see the point in having the link layer drop the packet. 
  64. even if it gets past the ip header check, the transport layer will
  65. surely drop it.  the ppp checksum is entirely redundant, wasteful.
  66.  
  67. should i comment on the utter stupidity of running nfs (or *any
  68. networked application!*) over a non-checksummed udp?  especially in a
  69. low-speed environment, where computational overhead is slight?
  70.  
  71.     peter
  72.