Stevens@A.ISI.EDU (Jim Stevens) (01/08/88)
Michael Padlipsky wanted to know why I asked about IP & TCP Precedence. Well, I am trying (for quite a while now actually) to complete an RFC on a new protocol called Transaction Transport Protocol (TTP). TTP differs from TCP and UDP by providing reliable message delivery instead of reliable byte stream or unreliable packet delivery. Anyway, one of the optional TTP services is precedence and preemption. Note that the optional TTP service is more than just a field reservation since the draft TTP RFC actually describes the processing which is performed at the TTP level based upon the TOS. I propose to get the priority level out of the precedence field within the IP Type Of Service (TOS) field. In fact, my TTP packet format includes the IP TOS within the TTP pseudo header of information which is obtained from the IP layer and is TTP checksummed (similar to UDP & TCP pseudo headers except that the zero octet is replaced by the IP TOS). My question to the TCP-IP distribution list was prompted when a reviewer questioned whether the IP TOS field was available from all IP implementations. Since no one has said otherwise, I presume that the IP TOS is available in all IP implementations. As pointed out by John Lekashman <lekash@orville.nas.nasa.gov>, authentication is required for fair TOS processing by IP to prevent people from setting their priority to the highest possible and thus hogging the network. Also as pointed out by Dan Lynch <LYNCH@A.ISI.EDU>, the IP TOS processing would have to be implemented by everyone if the TOS parameters are ever to have any use. I feel that precedence makes more sense at the Transport Level since the authentication issues are simpler than at the Internet Level and also since fewer people would have to implement precedence for it to make sense. Jim P.S I have been asked if I could forward any responses I got to the TCP-IP distribution list. Well so far all of the responses that I have received were also CC'd to the list. P.P.S I feel that there is a flaw to TCP's use of precedence and security. The TCP Military Standard (MIL-STD-1778) specifies the processing to be performed based upon the IP precedence field and security options. (I believe that the TCP RFC also specifies the use of the IP TOS and Security options but do not have a copy of the RFC with me to check right now). The use of the IP fields is fine and dandy since it is a standard and since it saves space in the TCP header. Unfortunately, TCP does not checksum the IP precedence field or the security options. Thus these fields could have been changed or corrupted en route between the 2 TCP implementations and this change would not be detected by TCP. You could say that the IP header checksum would detect this sort of error. Well if we must depend upon the IP header checksum why does TCP have a checksummed pseudo header at all? I am sure that the reason we have the TCP pseudo header is to detect if IP corrupted the addresses and protocol number. I am also sure that the reason why the TCP pseudo header does not include the precedence and security fields is just an oversight. -------
srg@quick.COM (Spencer Garrett) (01/11/88)
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.