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,
> 
> 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?)

Yes - that would be a different service, which is also why it should sit
on a different port.

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

If the data is "out of band", then the application needs to understand
what it means. TCP ports currently specify services with no out-of-band
information. If you want a service that understands that kind of
additional information, those would be a different service.

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

Understood; you're setting up a second data channel, and ACKing it
separately.

First, that can't be used to help reduce the RTT as Adam has suggested
without changing the "app doesn't get data until the handshake
completes" semantics.

Second, that information can't be used by the app unless you change the
*service* semantics, which means these are different services.

TCP options are for changing TCP behavior, not changing application
semantics, IMO.

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

You should take this up with the list manager; I'm not sure of how TCPM
is setup.

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

iEYEARECAAYFAkjWwi4ACgkQE5f5cImnZruBWwCgve+wUlxDLD7oMzxseHmuzw1q
Tr8Anjdh7tnzmJdoewsSzHTBgRriVo3L
=h2jo
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm