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

Adam Langley wrote:

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

This is an excellent summary of the core problem. It also summarizes
why SCTP is not the solution. An httpsctp protocol would be far
superior to an httpssf protocol, but it would be just as lonely.

So to translate your application level problem into transport layer
terms, you want to subdivide the class TCP payload stream into
a finite-sized "banner" that is at the start of the stream and
is followed by the traditional byte stream payload.

Further, you want to establish both bannerless and banner-enabled
connections using the same server-side listen. That is:

- When a banner-unaware client attempts to connect to a banner-capable
  server, everything will work. The server will know that the client 
  did not provide a banner, and the client will never see a banner
  that it does not know what to do with.
- When a banner-aware client attempts to connect to a banner-unaware
  server, everything will work because the client does not send a banner
  until it has seen the server's TCP options. The client will be told
  that the connection was accepted by a banner-unaware server, and the
  server will think it has a traditional client.
- When a banner-aware client attempts to connect to a banner-capable
  server they will actually exchange banners, and the banner payloads
  will be delivered to the client and server applications in a manner
  that is separate from the normal payload.

The rationale for doing this in TCP is that the total application
infrastructure cannot steer banner-aware clients to an alternate port
due to the class chicken-and-egg problem.

   If only 1% of clients understand banner-enabled HTTP then no sites
   will be encoded to use the special URL indicating banner capability.

   Since no sites use the banner indicating URL there is no reason for
   new clients to add that capability.

So there *is* rationale for doing this at the transport layer. Whether
there is *sufficient* rationale is subject to debate. My key reservation
remains that this breaks a fundamental concept of TCP. Instead of the
TCP payload being "a stream of bytes" it is now "an optional banner
message sent only when the peer's TCP options indicate it can be
parsed followed by a stream of bytes".

I've never been a fan of the "stream of bytes" model (I far prefer
the SCTP "stream of messages" model), but it is very simple and it
is what TCP is. I'm not sure the improvements cited here are reaching
a threshold sufficient to justify the required extra conceptual
complexity.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm