[e2e] TCP in outer space
fred at cisco.com
Tue Apr 10 14:59:30 PDT 2001
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
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.
More information about the end2end-interest