Subject: More TCMP
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 25 Mar 92 10:34:36 MST

Motivation

Perhaps I should give some more motivation. I have 
been writing a paper on backward compatible extensions 
to communications protocols. The basic idea being that 
everyone seems to think backward compatibility is a 
good idea but no two people have the same definition of 
what backward compatibility is. In examining the 
proposed TCP extensions my conclusion was that 
absolute preservation of the current TCP packet 
format and length was required. The reason for this 
is that there seems to be (or at least everyone worries 
about) software and hardware other than TCP which 
contain TCP header dependencies. 

What someone needs to do is define exactly what are the 
important features of the TCP header that must 
be preserved and specify WHY the must be preserved. 
A good start would be to determine exactly what assumptions
are being made about the TCP header by hardware 
and software other than TCP.

1) does the TCP header length matter
2) does the TCP format matter 
3) if the format matters does the content of the fields 
matter
4) if so which fields. 

Without this information it is hard to have a meaningful 
discussion of different approaches to backward 
compatibility.

With this in mind:

Rob Warnock states: 
> No new IP protocol number is needed.

I think an IP protocol number is required even if we 
use the reserve bits for a packet type field.  Each TCP 
protocol would claim to be two IP protocol numbers 
(this is easy to do in the x-kernel) and send all new packet
types using the alternate IP protocol number. The 
reason for this is that no will be peeking into headers 
sent using the new protocol ID. Now this might create 
problems if the software or hardware doing the peeking 
does something useful (as apposed to simply making 
it difficult to change TCP). Wether TCMP is a real 
protocol or just another IP protocol number for TCP 
is not relevant. 

If we can get away with changing the header format 
that would be wonderful.  (and that was one of my original
proposals) However if we can't change the header format 
then we have to lower our expectations...

Jon Crowcroft states:

> this has one major failing - you have lost the fact that the SACK
> information was carried with the ACK clock information because the
> TCMP packet is separate (worse, it be carried through the net on a
> different path at different priority...)

This leads me to believe that I do not understand 
the SACK option. In my view the SACK option 
simply a very round about way to suggest to 
the sender that it might be a good idea to retransmit
a frame or frame(s). In my proposal the SACK option
is not piggy backed with an real TCP ACK. If you want 
to ACK you can send another packet. As such all that 
really seems to matter is that the sender be able to identify
the session and weed out old SACK's. Hence the SACK field 
probably should contain timestamps. However when the SACK 
actually arrives is irrelevant. If the sender has already 
done something about those frames no problem. The SACK 
should not be used to compute RRTs it is just a hint.

It might help here if someone would explain how an 
advisory SACK differs from a NACK?

Sean O'Malley

ps. sorry about the duplicate posting I forgot about the 
tcplw mail alias.

Date: Wed, 25 Mar 92 09:30:20 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: SACK vs. TCMP

(*blush*)
Please excuse the junk at the end of my recent submission to the TCPLW list.
A slip o' the keyboard failed to delete it...

-Rob

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

Date: Wed, 25 Mar 92 07:13:23 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: SACK vs. TCMP
Cc: [email-masked]

Sean,

Your proposal for a "TCMP" is interesting. It reminds me strongly of several
historical parallels/precedents in other protocols. On the one hand, your
suggestion of a separate IP protocol number parallels IP & ICMP (as you
obviously intended). But there are other approaches:

Xerox NS (XNS) provides a "datastream type" at the transport packet level
which can be used for such "large" control messages. Mostly, they're just
used for the "suggested" (i.e., standard) close handshake, with types 255,
254, etc., but many other values are available for use by transport clients
in "out-of-band" signalling.

XTP provides more explicitly defined "packet types", of which the most
commonly used are "DATA" and "CONTROL". (There is also a "FIRST", which
is just a DATA packet prefixed by an "address segment".) CONTROL packets
are where XTP puts its SACK-equivalent "span" lists, and also other
flow-control information that is not carried in every DATA packet. For
example, opening the window ("alloc") requires a CONTROL packet back
from the receiver to the sender, since DATA packets don't have have a
field in them for "alloc".

So given the XNS & XTP examples, it feels like what you are really talking
about -- despite the suggestive name "TCMP" -- is *not* so much an "ICMP-like"
thing for doing fatal error handling, echo tests, and other miscellany, but
a full-fledged "control" packet type -- larger and more extensible than what
we can cram in the TCP options. And that feels to me like something that
belongs within TCP, not in a bolt-on-the-side parallel protocol.

Well, go ahead, why not bite the bullet? I'll say it, if no one else will...

Maybe it's finally time to allocate another one (or two?) of the six remaining
"reserved" flag bits in the TCP header, said field to be called "Packet Type".
[A extremely conservative approach would allocate but one bit, and call it
simply "Control".]

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |       |PKT|U|A|P|R|S|F|                               |
   | Offset| Rsvd  |TYP|R|C|S|S|Y|I|            Window             |
   |       |       |   |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The value "0" (or "00" or whatever) to mean "DATA" -- that is, the same
old TCP byte datastream we know and love(?). Value "1" (or "01") would be
"CONTROL", and would contain something very much like your "TCMP" packet
(or an XTP CONTROL packet) and contain (at least) large window update
information and SACKs.

And we define one more new TCP option that says "yes, I know how to
process packet types other than DATA" that each end must receive before
sending CONTROL (or other non-DATA) packet types to the other. With the
"I understand non-DATA" option, *all* the extended window stuff gets
swept from the TCP Options into the CONTROL packet. Without succesfully
exchanging this option, the formerly-"reserved" bit(s) stay zero, and
"old" TCP proceeds as always.

No new IP protocol number is needed.

Comments?

-Rob

p.s. It's going to take *something* more or less like a CONTROL packet
to add multicast to TCP (which I'd like to do one of these days)...

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

To: [email-masked]
Subject: is end2end-interest list dead/moved?

Dear [email-masked]:

I sent the following to <[email-masked]>, and it bounced.
Has this list moved or been renamed?

-Rob

+------ attachment ---------
| From [email-masked]  Wed Mar 25 07:06:49 1992
| Received: from whizzer.wpd.sgi.com by rigden.wpd.sgi.com via SMTP (911016.SGI/911001.SGI)
| 	for rpw3 id AA11922; Wed, 25 Mar 92 07:06:49 GMT
| Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (911016.SGI/911001.SGI)
| 	for [email-masked] id AA09050; Tue, 24 Mar 92 23:06:45 -0800
| Received: by sgi.sgi.com (911016.SGI/910110.SGI)
| 	for [email-masked] id AA01361; Tue, 24 Mar 92 23:06:31 -0800
| Date: Tue, 24 Mar 92 23:06:31 -0800
| From: [email-masked] (Mail Delivery Subsystem)
| Subject: Returned mail: Service unavailable
| Message-Id: <[email-masked]>
| To: rpw3
| Status: R
| 
|    ----- Transcript of session follows -----
| While talking to isi.edu:
| >>> RCPT To:<[email-masked]>
| <<< 554 :include:/div7/iab/end2end-interest.list... Cannot open /div7/iab/end2end-interest.list: No such file or directory
| 554 <@sgi.sgi.com:[email-masked]>... Service unavailable
| 
|    ----- Unsent message follows -----
| Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
| 	for [email-masked] id AA01360; Tue, 24 Mar 92 23:06:31 -0800
| Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI)
| 	for @sgi.sgi.com:[email-masked] id AA11917; Wed, 25 Mar 92 07:06:29 GMT
| Date: Wed, 25 Mar 92 07:06:29 GMT
| From: [email-masked] (Rob Warnock)
| Message-Id: <[email-masked]>
| To: [email-masked]
| Subject: SACK vs. TCMP
| Cc: [email-masked]
| 
| Sean,
| 
| Your proposal for a "TCMP" is interesting. It reminds me strongly of several
| historical parallels/precedents in other protocols. On the one hand, your
| ...remainder deleted...
+---------------

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

Date: Tue, 24 Mar 92 21:04:13 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
Subject: SACK vs. TCMP

The TCP Control Message Protocol (TCMP)

Short Summary of SACK Option to Date

The TCP SACK (selective acknowledgment) option was added
to TCP in order to reduce the amount of retransmissions required
on networks with large bandwidth-delay products. The SACK
option allows the receiver to selectively acknowledge frames in
its window. The sender uses the information contained in the
SACK option to select frames for retransmission. The SACK is
strictly advisory in that the sender cannot discard frames that
have been SACK'ed. Because of the small amount of room
available for TCP extensions the original proposal used 16 bit
offset and length fields and scaled those fields using the same
value used to scale the window size field. This resulting in a
total of 6 frames. The SACK option was then modified to use 32
bit fields in order to simplify the algorithm and eliminate the
interaction between the SACK and window scale options. Which
reduced the maximum number of frames to 3.  Since then
evidence has been given by Van Jacobson that at least 6 frames
must be included in each packet for any significant improvement
and the SACK option is currently being redesigned.

Option Field is a Scarce Resource

Both of the proposed SACK options share the same problem. In
the worst case they consume the entire remaining room in the
TCP option field. This makes any subsequent backward
compatible extension to TCP difficult if not impossible.  Any
subsequent TCP modification that requires a TCP option which
appears in every TCP header (like the timestamp option) will
compete with the SACK option for space. I believe that we must
treat the option field as a scarce resource and preserve some of
for future use. The question then becomes is the TCP option
field the right place to put the SACK? I think the answer is no.

TCMP

A more realistic proposal would be to take advantage of the fact
that selective ACKs are purely advisor and treat the SACK as a
control message similar in formate to the messages used by
ICMP to manage IP. The simplest solution would be to give the
modified TCP protocol an additional IP protocol number to use
when transmitting a TCMP messages. The format of a possible
TCMP SACK message is given below:

struct {
        long type;
        long length;
        long checksum;
        short src,dest;
        long seq,ack;
        long count;
        struct {
                long offset,length;
        } frame[0];
}

Since TCMP messages are limited only by the IP MTU there is
no need to save space. The packet contains standard TCMP
preamble: a type field which identifies which TCMP message
type this and length field which gives the length of the packet
in 32 bit words. The body of the packet consists of the data that
would have been sent using the SACK option. The source and
destination ports are needed to identify the correct connection.
The remaining information can be used to identify the fragments
for retransmission. One may want to include the timestamp
field. This is by no means the only approach to SACK. I believe
that NACK'ing holes rather than SACK'ing frames would be
preferable. The TCMP message formate could also be made to
more closely resemble the TCP header to permit the unmodified
TCP code to find the correct session. Performance would either
be superior or unaffected by this proposal.

TCMP can be used to handle asynchronous and unreliable
communications between TCP peers. More importantly TCMP
permits changes to TCP without changing the existing TCP
header. The option field in the TCP header can be reserved for
modifications which require reliable agreement (as the TCP
window scale option does) or per-packet information (as the
TCP timestamp option does). Other uses of TCMP are also
possible. For example the receiver could use TCMP to inform
the sender of the maximum packet size recieved. The sender
could use this information to set its frame size to avoid addition
IP fragmentation.

TCMP permits very large SACKs and does not require any
scaling of the fields.

Sean W. O'Malley        

Date: Sun, 8 Mar 92 22:04:37 -0600
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: TCP Extensions Implementation on 4.3 BSD NR2
Cc: [email-masked], [email-masked], [email-masked]

Folks:

I'm making my experimental implementation of the 1072/1185 extensions
available as a patch file to 4.3 BSD Networking Release 2.  I finally got
a machine to test it out on and it's been working well.  The patch file
and a README file briefly describing how to use the extensions are
available via anonymous ftp from uxc.cso.uiuc.edu (128.174.5.50).  It's
a small shar file in the /pub directory called "tcplw.shar".  (Also, that
same machine is the now running the implementation.)

All the details are in the README file there.  All your comments,
suggestions, criticisms, etc., are welcome.

-skibo

------
Thomas Skibo		[email-masked]	ph: 217-333-7937