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

On Tue, Aug 5, 2008 at 4:46 PM, Joe Touch <touch@isi.edu> wrote:

I've just posted a new version of the draft, incorporating your
comments, which I hope is a lot clearer. Thanks for everything so far.

> Using a transport signal to change the application protocol seems very
> strange to me. Others can comment on that. My view is that this is a
> case where perhaps you want something that is better encoded by using a
> different port number (thus a different application service, explicitly)
> than a TCP option that implies that application behavior.

It is strange, I agree. My usual test about such things is if I get an
"ick" reaction and, in this case, I don't. Although, that might just
be me.

Two reasonable questions arise:

"Where will this stop?"  - obviously, the TCP option space shouldn't
be a repository for application data. In this case, at least, the
option is advertising a certain minimum capability of the TCP stack,
as defined in the draft. Also, I'll claim that this is the last such
need in this area:

The SYNACK payload sizes is a decision for the server (within the
advertised window). No more client options could be needed to
advertise support for larger ones.

Since the SYNACK payload is (nearly) constant, and TCP stacks are not
going to differ sufficiently to change this in the next 20 years,
applications don't gain anything else by stuffing anything more in the
SYN option space.

So I don't think this sets an unreasonable precedent.

"Is it really needed?" - If you consider examples one and three from
the 01 draft that I just posted, I'm claiming that it would at least
be very useful. Of course, alternative ports solve the problem but I
believe that such a solution is messy enough as to be not a going
concern. Much of the time, SYNs to a closed port on a public server
will result in no reply at all, meaning that timeouts have to trigger
the back off.

The above is the sort of stuff that I should have put in the revised
draft :) I probably shall include it in -02.

Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm