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

[Stefanos Harhalakis <[e-mail]>]

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

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

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.
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm