Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!gpu.utcs.utoronto!dennis From: dennis@gpu.utcs.utoronto Newsgroups: comp.protocols.ibm Subject: Re: (none) Message-ID: <8809290248.AA07802@jade.berkeley.edu> Date: 29 Sep 88 02:42:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: dennis@gpu.utcs.utoronto Organization: The Internet Lines: 46 >> >>The one assumption TCP *does* make is that lower layers will not deliver >>a corrupted datagram and claim it's correct. The TCP (and IP and UDP) >>checksum(s) are a low-cost but extrememly useful last-ditch protection >>of this assumption, and are well worth it. >> > PLEASE remember that IP is a connectionless UNRELIABLE delivery >protocol. There is NO checking of the data in the packet - ONLY the >header fields! TCP and UDP checksums are only needed if you care what >data you will be getting... ;-) I think I agree with the first statement more. In the context of TCP/UCP/IP, "unreliable" most correctly means that you are not guaranteed that the datagrams you send will be received at their destination, and that you and/or the recipient must be prepared to recover appropriately in the event of non-delivery. It doesn't usually mean that you must be prepared to detect bit errors in datagrams which are received. For example, UDP is "unreliable", yet this doesn't require applications to implement a checksum of their own. The application can (and almost always does) assume that the data in a datagram delivered by UDP is error free, it just can't assume that all the datagrams which were sent are being received. However, if you really do care what data you are getting, you *will* use a link level which detects data errors and, at a minimum, drops those frames. The TCP checksum was chosen primarily for its ease of computation, is not strong enough to be reliable when data errors occur frequently and is particularly bad at detecting some types of errors. A year on the far end of a losy serial net link taught me to crc any large files I tried to transfer, before and after transmission. It didn't happen often, but every once in a while there'd be a string of bytes screwed up in the middle of one, let through undetected by TCP. The TCP checksum really is last-ditch protection, as it should be. It's much cheaper to calculate CRCs in hardware at the link level than it would be to do them in your host based TCP. It's also more efficient to catch and drop damaged datagrams early rather than relaying them the rest of the way to their destination. You really want to catch link errors at the link level, but want the transport checksum to catch the occasional bad one that will inevitably slip through anyway. Dennis Ferguson University of Toronto