[e2e] TCP in outer space

[Dan Wing]

> -----Original Message-----
> From: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]On Behalf Of Fred Baker
> Sent: Tuesday, April 10, 2001 3:00 PM
> To: L.Wood at eim.surrey.ac.uk
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] TCP in outer space
>
>
> 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.

You must be talking of HTTP 1.1; with 1.0 each image is a separate TCP
connection.  Even with HTTP 1.1 I suspect it's faster to open several
connections if you have a marginally fast link anyways, but I have no
testing to point to on that point.

> 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?

SMTP can be partially solved by attempting to fix the application.

One such fix is SMTP Pipelining, RFC2920 (and earlier RFCs), which allows
sending several SMTP commands in one TCP send() and waiting for each response
later.  With Pipelining you could send MAIL FROM and a dozen RCPT TO commands
and a DATA command all at once, wait for the 250s from the MAIL and RCPT
commands (or the 5xx or 4xx for certain users) and the 354 from the DATA
command, and then blast down the mail message.

-d

> 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.
>