craig@NNSC.NSF.NET (Craig Partridge) (12/01/89)
Hey folks -- let's not make using a different checksum harder than it
needs to be. It is very simple to do. A one-page RFC explaining how
is appended.
Please note I'm not endorsing the use of alternate checksums (although
it seems harmless enough).
Craig
Internet Engineering Task Force C. Partridge
Request for Comments: XXXX BBN
TCP Alternate Checksum Option
Status of This Memo
This memo is a draft RFC that proposes a TCP option to allow
use of alternate 16-bit checksums in the TCP header.
Distribution of this memo is unlimited.
Introduction
Some members of the networking community have expressed
interest in using checksums with different error detection and
correction properties than the standard TCP checksum. This
option makes use of such checksums feasible, provided the
checksums are 16-bit quantities.
Definition of the Option
This three-byte option may be sent in a SYN segment by a TCP
to indicate that it is prepared to both and receive an
alternate checksum. The alternate checksum replaces the
regular TCP checksum in the checksum field of the TCP header.
It is computed over the same data as the regular TCP checksum.
TCP Alternate Checksum Option:
+---------+---------+---------+
| Kind=X |Length=3 | cksum |
+---------+---------+---------+
Here cksum is a number identifying the type of checksum
to be used. The currently defined values of cksum are:
0 -- TCP checksum
1 -- 16-bit Fletcher's checksum
To use an alternate checksum, a TCP must both send and receive
a SYN segment specifying that the same alternate checksum
is to be used. Note that SYN segments must always use the
TCP checksum.
If a TCP receives an option containing different checksum
type value from the one it sent or does not receive an option
from the remote TCP, it must use the TCP checksum on the connection.
Observe that in practice this means that the initiating TCP
determines whether an alternate checksum is used, and the
listening TCP can only choose to accept or reject the
proposed alternate checksum.deering@PESCADERO.STANFORD.EDU (Steve Deering) (12/05/89)
Craig, I don't know how serious your proposal for a TCP Alternate Checksum Option is, but I would hope that any real proposal would allow for: - a checksum longer than 16 bits (for more robust error detection) - a checksum at the end of the packet (for pipelined interfaces) If it is important to maintain the current size of the TCP header, it might be reasonable to say that checksums longer than 16 bits *have* to go at the end of the packet. Steve
sklower@OKEEFFE.BERKELEY.EDU (Keith Sklower) (12/06/89)
Johnny, Steve, Craig (et al): This tempest in a teapot started when Johnny Zweig took a suggestion of mine for an alternative to the checksum employed in OSI transport and asked if it could be adapted to the TCP protocol. (And here I'm really speaking of TCP and TP and not the lower level headers). I refered to it as a ``16-bit'' version of the Fletcher algorithm, which actually yields 32 bits of checksum, has much better error detection properties than the standard OSI checksum, is twice as fast to compute, etc. etc. At no time did I EVER suggest that it would be a good thing to replace the TCP checksum with it!!!!!! (I could never make it run any faster than 2.5 times slower than the corresponding best TCP checksum). It does have the amusing property that you could have 16 bits of the 32 bits generated being the standard TCP checksum (in the standard place), and the other 16 bits could appear anywhere else in the packet. Craig suggested that if it were a TCP option, then it could be ignored or declined in a graceful way. To address Steve's concern, I'm not imaginative enough to think of a way to place TCP options behind the data; however the verification algorithm is one of the kind, like ethernet CRC, where you run along and compute numbers as you receive data, and hopefully come up with a known quantity at the end (in this case 32 bits of zeros). And, should Steve's reason for wanting the checksum at the end of the packet have to do with ease of computing changes to the checksum given small changes to the packet, in the case of TCP, you don't alter the TCP headers or data as they pass through gateways. It wouldn't be hard to come up with a minor modification to the VMTP checksum having the same property of position independence, which would be almost as fast to compute as the TCP checksum. The VMTP checksum would not detect 32 bit transpositions, nor double-bit errors (which is what may have triggered Johnny's interest). However, people on this list have already argued quite effectively that a stronger checksum is really not needed.
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (12/06/89)
I fail to see the reason why an alternative form of checksum is required for the TCP frame. As I recall the original posting, the host (in this case, an intelligent communications processor) received the data correctly. The error occurred in a subsequent transmission between the "host" and external memory. The problem is that the vendor of the intelligent communications processor did not fully understand or is not compliant with the protocol established by the vendor of the computer to govern DMA operations. Or, the vendor of the computer did not adequately define or implement the defined DMA proto- col. In either case, it is not TCP that is the problem. If it is, as indicated in an earlier message, a known problem that can occur during DMA operations, it is the computer manufacturer's responsibility to correct the error. If it is a problem that only occurs with DMA operations from the intelligent communications processor, its manufacturer is responsible for correcting the problem. Merton
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (12/07/89)
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >I fail to see the reason why an alternative form of checksum is required for >the TCP frame. As I recall the original posting, the host (in this case, an >intelligent communications processor) received the data correctly. The error >occurred in a subsequent transmission between the "host" and external memory. >The problem is that the vendor of the intelligent communications processor >did not fully understand or is not compliant with the protocol established >by the vendor of the computer to govern DMA operations. Or, the vendor of >the computer did not adequately define or implement the defined DMA proto- >col. I have to disagree (note my biased opinion, given that I'm the one who proposed the option). The TCP checksum is an end-to-end checksum. Saying "it's a hardware problem" is a cop-out (although I agree wholeheartedly that nobody in their right mind would buy/use hardware known to suffer from such bugs) -- my idea was simply to allow the possibility of specifying a checksum that can detect these errors which ought not to happen. >In either case, it is not TCP that is the problem. But is _is_ TCP's job to detect the presence of the problem, rather than get bitten by it. > If it is, as indicated >in an earlier message, a known problem that can occur during DMA operations, >it is the computer manufacturer's responsibility to correct the error. If >it is a problem that only occurs with DMA operations from the intelligent >communications processor, its manufacturer is responsible for correcting >the problem. >Merton All I thought was "gee, why not have a standard way of doing something that nobody ought to want to do, so that all the people who ought not to be doing it do it in the same way?" I am a researcher (not one of these evil vendor type goblins that ought to solve problems rather than think them up ;-) and I personally think playing with alternate checksums might be fun. Further, I am not in a position, for the most part, to say "Let's complain to Widgicorp that the beta-test hardware they gave us is flakey and suspend research on our latest transaction protocol for six months while they fix the problem" if I can just say "Oh. Plug in the Fletcher-TCP module on both of the machines in our experimental net and take a performance hit until Widgicorp gets it fixed." I prefer having standards that allow me to do crazy mixed-up stuff the same way as all the other screwballs over having a non-compliant implementation that I need to work around something. -Johnny
karn@jupiter..bellcore.com (Phil R. Karn) (12/07/89)
>I have to disagree (note my biased opinion, given that I'm the one who >proposed the option). The TCP checksum is an end-to-end checksum. Saying >"it's a hardware problem" is a cop-out... I am a big believer in the end-to-end argument. Unfortunately, even a TCP running in the same machine as the application isn't TRULY end-to-end. The problem is all that software between TCP and the application. In particular, it is common to first retrieve a file using FTP and then have an application read it. A lot can happen between TCP and the application in this case. Files can get corrupted or truncated by disk I/O errors, corrupted file system structures, full disks and buggy buffering schemes. And then there's the #1 cause of data corruption in FTP: transferring a binary data file in the default ASCII mode! (I've lost track of how many times I've had to help novice network users with this one.) In my experience these problems have accounted for far more actual cases of corrupted data than failures of the TCP checksum. One thing I often do on the PC to protect myself against the aforementioned hazards is to use file compression and archiving utilities like PKARC or ZOO. Not only do they make it easier and faster to ship a bunch of files over a slow network, but their built-in CRCs or checksums serve as a somewhat higher-layer check that includes FTP and the file system as well as TCP. Phil
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (12/07/89)
John: Unless we're talking about a simple link level interface rather than an intel- ligent communication processor, I still fail to understand how negotiating an additional or alternative checksum is going to help. You state: "The TCP checksum is an end-to-end checksum." Unfortunately, "end" in this case would refer to the intelligent communication processor NOT its host system. Most of the intelligent processors that I've had the (mis)fortune to deal with make the assumption that there will be no errors between the board and the TCP, UDP, TELNET, and FTP peer processes in the host system. This prob- len is common to all intelligent processors regardless of protocol or suite of protocols they are designed to support. If you want to minimize the possibility of end-to-end data corruption, you need to implement an end-to-end protocol that will physically execute in the host processor--to a large degree replicating features in TCP/IP--or use a simpler interface and performing the IP, TCP, etc. in the host. Merton
thomson@hub.toronto.edu (Brian Thomson) (12/08/89)
In article <18511@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >... after someone else first writes: >>The TCP checksum is an end-to-end checksum. Saying >>"it's a hardware problem" is a cop-out... > >I am a big believer in the end-to-end argument. > Many people appear to subscribe to "the end to end argument". I don't know if they have been convinced by persuasive argument or by the eminence of others who have endorsed it. The arguments I have heard do not convince me, and I believe that in many instances data integrity can and should be a hardware problem. Saltzer, Reed, and Clark argued the end-to-end case in their paper in the November '84 TOCS, They offer a file transfer application as their paradigm, and note five threats to the integrity of the data stored at the receiving host: 1) Undetected disk or disk controller error on the sending host while reading the original file. 2) Software error in either host or in communications system. 3) Undetected processor or memory hardware error in either end system. 4) Communications error. 5) Host crashes during transfer. They then claim that a harware-implemented communications checksum only addresses fault 4, and that "the careful file transfer application must still counter the remaining threats; so it should still provide its own retries based on an end-to-end checksum of the file." Perhaps a careful file transfer application should, but to conclude by extension that all applications must is unwarranted. In counter-argument, note that the first three risks are not unique to communications systems, and will be faced by a careful single-host disk-to-disk file copying program. Does this mean that every disk block on your computer system contains a software generated checksum? Undoubtedly there are applications that do this, but in most cases the prevailing industry standard of reliability, enhanced as it might be by embedded parity/EDC/ECC hardware, is sufficient. The particular flavour of risk 5 encountered here is unique to distributed systems, but its detection involves handshaking and does not require "an end-to-end checksum of the file." A related end-to-end argument, enunciated by Cheriton in his XXX VMTP paper, states that only the application knows how small an error probability is tolerable, so the application must implement the checksum. This argument is incorrect, firstly because checksumming can not establish a maximum error probability, it can only reduce it. An application may be willing to tolerate a 10^-18 error rate, but it cannot determine how strong an error detection scheme to use unless it also knows what error rate it is starting with. Secondly, different error detection methods have different strengths and weaknesses, and an appropriate selection may require knowledge of the nature of the most probable errors. In my view, data integrity can be effectively provided by chaining together reliable links, and if this is done properly then no end-to-end check is necessary. "Doing it properly" means providing a comparable input-to-output error rate as you get from your favourite disk drive/controller combination, or tape/formatter combination. That likely means some error detection (or maybe correction, for something like a satellite channel) "on the wire", and maybe some parity or something even fancier in the communications processor memory, and maybe you need to ensure that the domains of protection of these things overlap so that errors don't sneak in through the cracks. Check out what Ciprico/Xylogics/etc. do with the caches on their intelligent disk controllers. Provide the same level of service they do, it seems to be adequate for most applications. Who knows, you might even be able to write applications that don't have to be told whether they are dealing with disks or networks, becuase they same de facto reliability standard applies to both. When does this approach fail? Obviously, if your packets are going over a network you know nothing about, or have no control over, it is not safe to make assumptions about its error properties. In that case, higher-level error detection does make sense, but it should be provided as an option, or perhaps as a gateway function, and it need not be application-to-application. Or, if you have a particularly finicky or critical application that may not be satisfied with the 'standard' reliability, it may wish to enhance it and should do so whether the data transfer involves a network, a disk, a tape, or whatever. Moreover, it now has a fighting chance of doing what you want because it has at least a vague idea of the kind of underlying error rates it has to deal with. Finally, I will concede the possibility that under the right (unusual) conditions it may be cheaper to build hardware with no error control and rely entirely on end-to-end error detection in software, but I surmise that the performance penalty associated with providing error detection of any capability in software (say, the equivalent of a 32-bit CRC) will render this a rather unpopular option. Comments welcome. Thanks for your attention. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (12/08/89)
I don't know why this talk about intelligent communications processors seems to be taken for granted -- I was thinking of using Fletcher checksumming on Mac's with potentially flakey 3rd-party ethernet interfaces, other workstations and minis without front-end TCP/IP processors. I'll grant that if a front-end can't communicate reliably with a host, that's that and it's time to change hardware. Let me quickly respond to several of the arguments I've seen (paraphrased): The current checksum is fine. Don't change it. I am not suggesting anyone change anything, nor would I hope for such a thing. I want to add the possibility of a few lunatic-fringe people who feel it might be necessary/fun/worth looking at to use alternate checksum techniques. An argument that says the current way of doing things is fine is looking at what I suggested wrong. The End-To-End argument is wrong; concatenation of reliable links is all you need. Fine. I assert that, on my Mac, the linke between the ethernet card's RAM and my system RAM is unreliable, so I want to make the TCP module running on it sufficiently robust to detect failure of that link. I am glad you agree (albeit implicitly) that an alternate checksum capability is necessary to make this last (and vital) link reliable, since the end-to-end argument and the link-by-link argument agree on what to do when what you're talking about the last link. (Hairsplitting: the ethernet-card -> TCP link is the last hardware link, not the last conceptual link since the data still needs to be copied reliably to the application.) Water is wet and I don't get paid to listen to malcontents who want to make my life more complicated. I apologize. It's in my nature. -Johnny
barmar@Think.COM (12/09/89)
In article <8912071916.AA23996@beaches.hub.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes: >In my view, data integrity can be effectively provided by chaining >together reliable links ... >When does this approach fail? Obviously, if your packets are going >over a network you know nothing about, or have no control over, it is not >safe to make assumptions about its error properties. In that case, >higher-level error detection does make sense, but it should be provided >as an option, or perhaps as a gateway function, and it need not be >application-to-application. This is probably true. It does mean that the interfaces between the transport and link layers must provide ways of querying about the error properties of the path that datagrams will take. This, however, implies that the route is fixed, or at least can be determined ahead of time. IP uses dynamic routing at the packet level (caller-specified routes are possible, but out of the ordinary). A call to TCP_WRITE may result in multiple IP datagrams, which may be fragmented into multiple link layer packets, each of which may take a different route. Also, there are very few links with the kind of reliability most applications would like. Ethernet is usually considered a reliable medium, but when we had UDP checksums turned off on our Suns I saw lots of NFS problems between hosts on the same Ethernet. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
srg@quick.COM (Spencer Garrett) (12/09/89)
The problem is worse than might be imagined. In relying on link-level checksums not only are you vulnerable to errors occurring between your application or its peer and their respective link-level interfaces, but also on the same pathway *and the software* on every gateway in between. Given the choice between a) computing checksums/CRC's every time and b) trying to figure out/negotiate when to use them my inclination runs strongly toward the former. Given how easy it is to do CRC's in software (even 32-bit ones) I, for one, wish we could somehow convert to them instead of the weak checksum presently in use, but failing that I sure wish the current checksums weren't optional. Are you listening, Sun?
deering@PESCADERO.STANFORD.EDU (Steve Deering) (12/10/89)
Keith, My reason for wanting the checksum at the end of the packet is to allow a high-performance (hardware-assisted) implementation to compute the checksum on the fly as it copies a packet onto the wire, tacking it on at the end. This eliminates one expensive pass over the packet. I believe that Ultra's speedy TP-4 implementation places the checksum at the end for the same reason. > It wouldn't be hard to come up with a minor modification to > the VMTP checksum having the same property of position independence, > which would be almost as fast to compute as the TCP checksum. We'd welcome any suggestions. We did consider using 16-bit Fletcher (i.e., two 16-bit accumulators, yielding a 32-bit result), but as you mentioned, it would be several times slower than the TCP checksum. The TCP checksum takes basically one instruction per 32-bit word on common processors (using add-with-carry and loop unrolling); it's pretty hard to beat that. VMTP's checksum is a few percent slower than TCP's; it's not as strong as we would like. Steve
CERF@A.ISI.EDU (12/12/89)
Merton I think what is at issue is whether the TCP checksum should be sufficiently robust to detect some of these anomalies. In the past we opted for the simple checksum owing to a concern for the cost of computation; if this parameter is less crucial now, thanks to more powerful processors, one may be able to afford the expense of better failure detection. Vint
rpw3@rigden.wpd.sgi.com (Robert P. Warnock) (12/15/89)
In article <89.12.09.1713.750@pescadero.stanford.edu>, deering@PESCADERO.STANFORD.EDU (Steve Deering) writes: +--------------- | My reason for wanting the checksum at the end of the packet is to allow | a high-performance (hardware-assisted) implementation to compute the | checksum on the fly as it copies a packet onto the wire, tacking it | on at the end. This eliminates one expensive pass over the packet. I | believe that Ultra's speedy TP-4 implementation places the checksum at | the end for the same reason. +--------------- If you have any packet buffer RAM on your controller, you probably want to compute the checksum on transmit data as it's being copied from the host to the controller, rather than as it's going out on the wire, just to protect against mistakes while the data is in the controller. Also, one of the reasons XTP has a header/trailer checksum separate from the data checksum is so the data checksum can be done once during the copy from the host (and at the other end when finally copying *to* the host after reception) using some hardware assist as you suggest, while the header/trailer checksum computation can be deferred until the packet is actually about to go out onto the wire. This lets the headers contain the most recent status available just as the packet was about to go out... But the notion is similar; both checksums in XTP are in the trailer, and can be calculated with hardware assist as part of the copy (or transmission). ----- Rob Warnock, MS-9U/510 rpw3@wpd.sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311