Re: [tcpm] Faster application handshakes with SYN/ACK payloads

[Stefanos Harhalakis <[e-mail]>]

Hello,

I'm sending this reply mostly to clarify the things. Perhaps there is 
something that I don't understand or I don't express well. If it is so, 
please excuse the stubbornness of mine.

On Sunday 21 September 2008, Joe Touch wrote:
> HTTP does send a banner of that type; the issue is that you want #2
> above - if you don't act on the banner info until after the TWHS, you
> "waste" an RTT waiting for the connection to be established before the
> server can reply.
>
> That's a **design feature** and requirement of TCP, not a "waste".

I don't exactly understand what you mean by saying that HTTP sends a banner. 
An HTTP server will never send anything unless it is triggered to do so by a 
client request. Creating an HTTP version that sends an initial one-line (or 
more) will break backwards compatibility. (no?)

> > and more specifically with the first sentence. Supposing that (a
> > hypothetical) HTTP/1.3 would support an optional banner, such an option
> > would allow the server side to send it without braking backwards
> > compatibility:
> >
> > Client --> SYN+DATA --> Server
> > Client <-- SYNACK+? <-- Server
> > Client -->   ACK    --> Server
> > Client <--  BANNER  <-- Server
>
> The server can start sending data before the TWHS completes (let's call
> the above "sequence 1" and the below "sequence 2"):
>
> Client --> SYN+DATA --> Server
> Client <-- SYNACK+? <-- Server
> Client <--  BANNER  <-- Server
> Client -->   ACK    --> Server
>
> In sequence 1, the banner can depend on the SYN+DATA data. In BOTH
> sequences, however, the SYNACK+? "?" **cannot** depend on the SYN+DATA
> data.

I believe that I didn't describe well what I meant (or else I don't completely 
understand what you're saying).

I'm talking about (lets say) 8 bits of out-of-band information that the client 
can send to the server side and vice-versa. The server side application will 
most probably get those data after the TWHS completes. There is no placed 
requirement to do otherwise.

So, a complete trace (with most function arguments ommited or altered for 
simplicity, no error handling, etc etc :-) of a non-well thought proposal 
(there are issues) would be:

(C: Client, S: Server)

# Server side listens for connections, supports USER_DATA
S: s0=socket()
S: setsockopt(s0, SO_USER_DATA, 0x02)
S: bind(s0, 0.0.0.0, 80)
S: listen(s0)

# Client attempts connection. Sends USER_DATA
C: s=socket()
C: setsockopt(s, SO_USER_DATA, 0x01)
C: connect(1.2.3.4, 80)

# Connection is established. Remote USER_DATA is available to both ends
S: s=accept()
S: getsockopt(s, SO_REMOTE_USER_DATA, &mybuf)
C: getsockopt(s, SO_REMOTE_USER_DATA, &mybuf)

At this point, the client side has connected to the server side and they have 
exchanged one byte of out-of-band data (C->S: 0x01, S-C: 0x02). This is all 
done without messing with the TWHS.

>From the TCP's point of view, the above would look like:

* Client sends SYN with TCP option USER_DATA, length 1, data 0x01
* Server receives SYN, supports USER_DATA, responds with SYNACK with option 
USER_DATA length 1, data 0x02 and *no* data in the segment.
* Client receives SYNACK and responds with ACK
* Everything continues normally

The only difference with existing TCP behavior is that a 3-bytes TCP option is 
included in the SYN and SYNACK segments. There is no messing with user data 
in SYNACK at all. Perhaps the USER_DATA option name is confussing. USER_DATA 
is just an arbitrary name for a KIND of an option.

> > p.s: I can write a draft if this would clarify things.
>
> I think you're exploring the space of the discussion that has already
> been had on this list...

Adam's proposal was that data (outside of TCP options) would be sent with the 
SYNACK field. I still believe that the USER_DATA option is not related to 
that. Perhaps if I hadn't initially related this proposal with Adam's 
proposal (since it is related to his 'wish' and not to his proposal) it would 
be clearer?

I'm *really* sorry if what you say above is true and I just don't understand 
something. 

p.s. Do you know if there is a way to force the tcpm mailing list to send me 
duplicates for mails that are CC'd to me too? It seems that all mails that 
I'm CC'd are only sent directly and not via the list. I've set the "Avoid 
duplicate copies of messages?" to "No" in the mailman options but there was 
no change.
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm