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

[Joe Touch <[e-mail]>]

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

Hi, Stefanos,

Stefanos Harhalakis wrote:
> 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"

I've been calling a a user data option for that reason, but I feel that
it changes TCP semantics. You're using a SYN option to change the
behavior of a service on a port. This requires substantial changes to
the interface as outlined in RFC793 (and implemented in sockets). In
particular, you need the server to be able to read the SYN options from
a socket before writing the response to a SYN-ACK.

This is outlined in previous emails to the list; it might be useful to
review them.

> This is easy to implement (at the client side) and will allow for premature 
> negotiation. 

As per above and in previous emails, it seems impossible to implement in
existing stacks without substantial modification of the socket interface.

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

The issue is that the data is carried in the DATA of the SYN, not in the
option (in the SYN-ACK reply once negotiated). A different issue is that
TCP cannot ensure that data, once written, is solely in the SYN - it
could be retransmitted in subsequent data packets anyway, so it should
not be assumed to be inside the SYN.

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

iEYEARECAAYFAkjV5wcACgkQE5f5cImnZrsR8ACeML9+DyBNxhXLuf5us0N3tKwo
S4gAn1rbAq/h/j1tRU+7pVAXS6pelstk
=u3UW
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm