[e2e] TCP in outer space

[Fred Baker]

At 12:04 PM 4/10/2001 +0100, Lloyd Wood wrote:
> > The other is that both HTTP and SMTP are fairly chatty transaction
> > protocols, which kill time for several RTTs before doing much of anything.
>
>Funny, I've always thought that about TCP, thanks to its handshake. (Not 
>that transactional TCP is going anywhere, for DoS reasons.)

I've looked at a few session setups in my time. You might take a second 
look at Transaction TCP - its big change really is that it can carry the 
SYN flag on a segment containing data, so that the "connect" can also say 
what it wants to talk about. You're correct about DoS issues, but I should 
think that an authenticated and authorized requestor should be able to use 
the protocol.

But it really only gets rid of one round trip in a session that generally 
requires at least three or four, which seems like a pretty small 
optimization. An HTTP request for a web page could carry the HTTP GET data 
on the SYN packet, and the data coming in reply could be on the SYN-ACK, 
but if there is any loss at all in the network you are going to see some 
level of retransmission anyway, and the mean web page (10K, I'm told) is 
still going to take several segments and at least a couple of round trips. 
Email is a much deeper kettle of fish; sure, you could carry the EHELO on 
the SYN packet, but how much would that help with the succession of "From", 
"To", "Data", and "end of data" messages that SMTP carries?

Some common session setups:
  - X.25 has a two-way handshake; connect.request results in a
    connect.indication at the peer, and its connect.accept results in a
    connect.response at the originator.

  - XNS SPP has a three-way handshake; a probe (system packet requiring a
    response) results in a probe back, which as required gets a system
    packet in response.

  - ISO TP-4 has a two-way handshake as I recall, although it has been a
    zillion years since I looked at it and it was then called the "BBN
    Transport developed under contract to US-NBS". It had "open" and
    "accept" TPDUs, which operated a lot like an X.25 connection.

IMHO, it is pretty difficult to set up anything resembling shared state on 
a pair of machines without at least a two-way exchange, and the third 
message in the exchange assuring the respondent that the originator 
received the "I accept your connection" message is necessary - he otherwise 
doesn't know. When a transport has a two-way handshake, the third step is 
implicit - the sender says something on the connection. The third packet in 
SPP or the Ack in TCP merely formalizes that, and takes no measurable time. 
I just don't see much to argue about there other than that if you actually 
have data to send you may as well send it.