Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!uflorida!gatech!rutgers!bellcore-2!envy!karn
From: karn@envy.bellcore.com (Phil Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <1990Oct25.165545@envy.bellcore.com>
Date: 25 Oct 90 20:55:45 GMT
References: <9010221418.AA03839@ftp.com> <1990Oct24.090841@apollo.HP.COM>
Sender: usenet@bellcore-2.bellcore.com (Poster of News)
Reply-To: karn@thumper.bellcore.com
Organization: Packet Communications Research Group (Bellcore)
Lines: 55

In article <1990Oct24.090841@apollo.HP.COM>, mishkin@apollo.HP.COM
(Nathaniel Mishkin) writes:
|> E.g., for the purposes of RPC, it sure would have
|> been nice if I could do something like send data (i.e., the remote
call's
|> input parameters) in a SYN.  (I've never seen an implementation that
|> allows this; I can't point to the place in the TCP spec that
disallows
|> it, but I imagine it is disallowed.)

I don't think anything in the TCP spec specifically disallows the
piggybacking of data with SYN bits. The only possible argument against
it is the fact that the active initiator of a TCP connection doesn't
yet know the receiver's window size yet. But even here the the worst
that should happen under the Robustness Principle is that the receiver
might not have buffer space for all (or any) of the data, requiring
the sender to retransmit it once the connection is fully open.  This
is an efficiency issue, not a protocol correctness issue, and is
identical to that associated with the "optimistic window" send policy.

But assuming no problems with buffer allocation, I see no reason why
an entire TCP connection couldn't consist of only three packets:

A->B: SYN, FIN and data
B->A: SYN, FIN, ACK (and optional data)
A->B: ACK

Of course, most application interfaces don't provide for sending such
"christmas tree" packets, but a correct implementation of TCP should
be able to handle them when received. It's hard to think of a "reliable
datagram protocol" that would take less than three packets to provide
at-most-once semantics for a single message in each direction.

Even with applications that don't require a "reliable datagram
protocol",
I think that the ability of TCP to piggyback control and data should be
much more widely used. There's no reason why a SMTP or FTP server's
opening banner couldn't be piggybacked on the server's SYN/ACK segment,
saving two packets, and no reason why FIN can't be piggybacked on the
last
segment of a data transfer, also saving two packets. Again, a correct
implementation of TCP should handle such packets just fine.

While we're on the subject of piggybacking, another thing I would
really like to see is widespread use of batched SMTP on the Internet.
I think the number of packets it takes for most SMTP implementations
to transfer a short mail message is criminal, especially when the
message has several recipients on the same system.  There's no reason
that you shouldn't be able to send a series of SMTP commands in a
single TCP segment and receive a series of responses, except that many
SMTP servers inexplicably blow up when you try this. Given that TCP is
supposed to be a reliable byte stream protocol, the designers of these
systems must have gone well out of their way to keep this from working.

Phil