home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12436 < prev    next >
Encoding:
Text File  |  1992-08-23  |  2.0 KB  |  36 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!cs.utexas.edu!torn!utzoo!henry
  3. From: henry@zoo.toronto.edu (Henry Spencer)
  4. Subject: Re: Modems, compression, and SLIP or PPP (was Re: Using Telebit PEP with SLIP)
  5. Message-ID: <BtGq33.F7p@zoo.toronto.edu>
  6. Date: Mon, 24 Aug 1992 00:45:02 GMT
  7. References: <1992Aug23.202309.22443@terminator.cc.umich.edu> <1992Aug23.203750.22670@terminator.cc.umich.edu>
  8. Organization: U of Toronto Zoology
  9. Lines: 25
  10.  
  11. In article <1992Aug23.203750.22670@terminator.cc.umich.edu> honey@citi.umich.edu writes:
  12. >i fail to see the point in having the link layer drop the packet. 
  13. >even if it gets past the ip header check, the transport layer will
  14. >surely drop it.  the ppp checksum is entirely redundant, wasteful.
  15.  
  16. "Surely"?  Peter, TCP or UDP has only a 16-bit checksum, which has one
  17. chance in 65536 of being okay on random garbage.  Modem errors don't
  18. produce random garbage, of course, but they are a lot more creative than
  19. they used to be.  When many bits are being transmitted simultaneously,
  20. many-bit errors are just as easy as one-bit errors used to be.  The TCP
  21. (et al) checksum is intended as a last-ditch defence against errors that
  22. get past lower layers, not as an impenetrable shield.  (Indeed, some of
  23. the RFCs on related issues imply that higher levels really ought not to
  24. depend on the checksum being 100% impenetrable... but most do.)  It
  25. functions well as a last backup, but only if the underlying layers are
  26. reasonably reliable to begin with.  If the hardware isn't good enough,
  27. you need either a better TCP checksum/CRC or some sort of link-layer
  28. error detection.  The latter is easier to fit in, and also lets you
  29. throw the packet away as soon as it is corrupted, rather than making
  30. you carry it to the receiving end (which might entail several more
  31. hops, perhaps over low-speed links, for a packet that is probably
  32. useless to the recipient).
  33. -- 
  34. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  35. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  36.