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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Stefanos Harhalakis wrote:
> On Sunday 21 September 2008, Joe Touch wrote:
>>> Stefanos Harhalakis wrote:
>>>> Add a generic 'user data' option for SYN fields that would carry user
>>>> data.
>> There are two reasons for doing this:
>>
>> 	1- to send an out-of-band signal
>>
>> 	2- to send a signal that the server acts on before the
>> 	handshake completes
>>
>> #2 violates TCP semantics, so the SYN-ACK cannot have application data
>> that depends on the SYN's user data option (which is the desired result
>> here). The signal can't be acted on at the application layer until the
>> handshake completes.
>>
>> #1 changes TCP semantics as well, since TCP does not have an out-of-band
>> signal path, and this would add that. However, because it cannot be
>> acted on until after the handshake completes, it cannot modify
>> application behavior that isn't required to wait until the handshake
>> finishes - i.e., apps that can write to the socket before the handshake
>> completes (e.g., to write data available to a SYN-ACK) would never
>> change because of this signal. The utility of this feature depends on
>> application behavior, which cannot be known, and thus cannot be relied
>> upon.
> 
> What I proposed is what you describe in #1. It is different from the 
> SA-with-data proposal and thus it hasn't to do anything with #2. As I said in 
> the original mail, it has to do with what Adam said:
> 
> "If HTTP sent a banner, like SMTP servers, then my life would be a lot
> easier! The banner could advertise all the extensions supported.
> However, without SYNACK payloads, this banner would cost another round
> trip."

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

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

> Without changing current behavior (It is not required that data be sent with 
> the SYNACK option).
> 
> Also, this is not exactly "data" as there is space for a very small amount of 
> information (some bits). Considering the possibilities of this, it can be 
> used in many situations such as:
> * HTTP or other protocols that use a well-known-port, to negotiate different
>   behavior without introducing a new port number (SSL over port 80?).
> * Cryptographic applications
> * Anything that someone out there can think of. 8 bits (or a little more) of 
>   information can be used for many things.
> 
> Wrong?
> 
> 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...

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkjWdq8ACgkQE5f5cImnZrttuwCY3gRvZM7rIEWn3Afu9O4aKEss
MgCdHhBYcwQPli47R7YfewyAKNoVPPo=
=xJ3F
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm