Path: utzoo!utgpu!water!watmath!clyde!rutgers!sdcsvax!ucbvax!A.ISI.EDU!Stevens
From: Stevens@A.ISI.EDU (Jim Stevens)
Newsgroups: comp.protocols.tcp-ip
Subject: Pseudo-Headers & Checksumming
Message-ID: <12365632245.20.STEVENS@A.ISI.EDU>
Date: 11 Jan 88 03:26:39 GMT
References: <175@quick.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Rockwell International
Lines: 50


Spencer Garrett responded to my message about TCP/IP Precedence &
Preemption and raised a very interesting point about pseudo-headers
and checksumming.  Garrett's message follows:

    > I think one of the biggest warts in TCP/IP is the stupid
    > checksum spec.  Including noncontiguous, and sometimes
    > nonexistent, fields in the checksum insures that they will be
    > slow and awkward to compute.  If you're designing a new
    > protocol, PLEASE have the checksum include all of, and only,
    > your header and data.  If you feel you can't trust your IP
    > level to check its own header checksum, then please recompute
    > the ip checksum yourself; don't pluck bits of that header out
    > and pretend they're your own.  If the IP header got mangled,
    > you shouldn't even see the packet.  If that's not true, you
    > need to fix your IP module.  Let's hear it for layering.

Since I am designing a new protocol, I am interested in people's
comments on the implementation difficulty of using pseudo-headers. 

In addition, I am interested in any responses on why we have
pseudo-headers which are checksummed at all in TCP.  Especially in
light of the fact that there are other IP fields which TCP could use
but does not checksum.  Two such IP fields are precedence (within
IP type of service) and security options.

Is the old "End to End Argument" a reason for having pseudo-headers?
(Reference "End-to-End Arguments in System Design" by J.H. Saltzer,
D.P. Reed, and D.D. Clark, ACM Transactions on Computer System, Nov
1984.) 

Does the pseudo-header checksumming issue have anything in common
with the issue of whether the ARP packets should have their own
checksum in addition to relying upon the Ethernet checksum?
(Remember all the messages on this subject on TCP-IP about a year or
so ago.)

If we are worried about implementation efficiency, should we place
the checksum field at the end of the protocol packet (i.e. a protocol
data unit for a particular protocol) as well as make the data to be
checksummed contiguous?  For example, David Cheriton's Versatile
Message Transaction Protocol (VMTP) places the checksum at the very
end of the VMTP packets (even after the user data) to allow the
checksum "to be calculated as part of a software copy or hardware
transmission or reception as expected in an intelligent network
interface".   (Quotes are from Cheriton's July 1987 Preliminary
Version 0.3 description of VMTP.)

Jim Stevens
-------