Re: [tcpm] SYN/ACK Payloads, draft 01

On Thu, Aug 14, 2008 at 1:36 PM, Joe Touch <touch@isi.edu> wrote:
> Isn't it a *lot* simpler to avoid an option and just send the data anyway?

Yep! And I intend to patch Linux to support exactly this (no options
involved anywhere) at some point. To reuse an example, I could have an
SMTP server which writes "200 example.com ESMTP\r\n" this way and save
a round trip. (Although SMTP isn't too latency sensitive some busy
servers might be glad of it.)

But many application level protocols have been designed as
client-speaks-first, like HTTP. So, let's define HTTP-ssf (server
speaks first). HTTP-ssf is exactly the same as HTTP, except that the
client waits for a banner from the HTTP server before sending a banner
of it's own. We can use the same trick as the SMTP server to maybe fit
this banner in the SYNACK. If it doesn't fit, no loss, it can go in
later packets. If the client doesn't ACK all the data from the SYNACK,
no loss, again it goes in the next packets.

Now, I can run an HTTP-ssf server, but no web browser on the planet
can talk to me! And the browsers that I modify to speak HTTP-ssf can't
take to any non-ssf HTTP servers. It's a very lonely website.

I could define a whole new URL scheme (httpssf://...) and a new port.
But then there's no gradual deployment path because users with old
browsers don't understand httpssf:// and it confuses the users anyway.
Most type http:// by habit.

My HTTP-ssf server happens to be an embedded device and it handles the
TCP processing directly. So, I have browsers that understand HTTP-ssf
set an option in the SYN packet. If I see this option, I start talking
HTTP-ssf, otherwise I stick with HTTP. When I start talking HTTP-ssf,
I echo the option to let the client know which protocol is in effect.
Now HTTP-ssf can be deployed gradually.

In order to run HTTP-ssf servers on non-embedded machines I define a
couple of (get|set)sockopt's to set and query the option so I know
what protocol to speak. I also want to include the banner in the
SYNACK for latency reasons, so I include another setsockopt to set a
constant banner that's prepended to the beginning of the server's
outgoing data stream. However, the kernel needs to know only to
prepend this banner if the client include the option, so I add that
ability too.

Now my server gets SYN flooded and, to mitigate the problem, it
doesn't want to send large SYNACKs out, even when the client has
requested them. It can send minimal SYNACKs and put the banner in
later packets. However, user's hate it when their websites slow down
so, rather than do that, the kernel can also ignore the requests and
fall back to HTTP.

(Sorry, I don't mean to be condescending in the slightest! I just got
carried away with the personification there. However, I don't think
the clarity suffered for it, so I'm going to stick with it. I hope you
don't mind)

AGL

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