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

Hello Adam,

I've just looked again at this. Its 1.5 month late but time runs fast.

> However, it appears that I've not made the case for the option yet. To
> do this, let me take HTTP as an example.
>
> HTTP is very latency sensitive[1]. Because of this, and guided by the
> sockets API, the client starts the exchange. Thus, if the client
> wishes to probe for optional features (like TLS upgrade: RFC2817) the
> exchange works like this:
>   Client --- OPTIONS ---> Server
>   Client <--- 101 Switching --- Server
>   Client --- GET ---> Server

AFAIKT, you're proposing that whenever the server side detects the SA option 
it switches to a different protocol behavior. Why not extend this even more 
and provide a generalized framework for more advanced customization?

I believe that this was not proposed before so here it goes:

Add a generic 'user data' option for SYN fields that would carry user data. 
Something like this:

KIND | LENGTH | DATA

Most of the time it should be: 

KIND | 3 | "1 Byte of data"

This is easy to implement (at the client side) and will allow for premature 
negotiation. For example this could include the client side application layer 
protocol capabilities. It can also be symmetric so that server side also 
sents some out-of-band data but most probably this should not be required 
with SA data (but an echo/acknowledge is required).

The implementation at the client will just require a setsockopt() that would 
set the extra header data and perhaps a getsockopt() that would get the reply 
(if any). This part needs some working.

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

Such a solution would allow the HTTP protocol to switch to HTTP-with-banner as 
you wished, without braking compatibility. Of course there can be many other 
uses for it. It is also 100% TCP friendly since a receiver that doesn't 
support such an option will just ignore it.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm