TP4 and TCP

Alex McKenzie (mckenzie@BBNH.ARPA)
Fri, 24 Jan 86 8:28:18 EST

TP4 is intended to be functionally equivalent to TCP. The NBS and BBN people
who worked in the ANSI and ISO committees defining the OSI Transport protocols
were all familiar with TCP and had, as an explicit goal, getting TP4 to be as
close to TCP functionality as they could manage. In fact, the inital NBS
proposal was for ANSI and ISO to adopt TCP as it stood.

The biggest differences I can remember offhand are:

-For the purposes of allowing fragmentation, TCP numbers every byte. TP4
allows (requires) the two implementations to negotiate a maximum fragment size.
Every message is broken into fragments of this size (only the final fragment of
the message may be shorter) and numbers these fragments. [Silly window syndrome
is not likely.] The motivation here was primarily to make the reassembly task
as easy as possible, with fixed buffer pools and no byte shifting. A secondary
motivation was to reduce the size of the field used to hold the number.

-TP4 and TCP both allow a receiver to specify a zero window. TCP treats this
as a "hint" and handles the loss of an ACK which opens the window by source
probes. TP4 strongly discourages probing a zero window and provides a
reliability mechanism for the ACK which opens a closed window. The motivation
here is that the designers felt that a system might close windows when it was
overloaded and really didn't want to spend ANY cycles processing traffic from
the sources it had closed.

-TCP (as I recall) has an "urgent" bit in the header of all data which, if set,
tells the receiver to scan ahead looking for something special. TP4 has an
"expedited" flow of limited capacity which is completely separate from the
regular flow. [The expedited flow allows one outstanding message of up to 16
octets, I think.]

I hope this helps,
Alex McKenzie

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:39 GMT