W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Optimizations vs Functionality vs Architecture

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wed, 22 Aug 2012 14:33:47 -0400
Message-ID: <CAMm+LwgHgtKHQw3O5q37BVXGXeS=DE+xp0nnfCPqoEubNLkekA@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: ietf-http-wg@w3.org
On Wed, Aug 22, 2012 at 1:51 PM, James M Snell <jasnell@gmail.com> wrote:
> I've just been going back through all this... and I will be the first to
> admit that my low level TCP Kung Foo is a bit rusty and I'm just pulling
> this off the top of my head... but... could we not leverage the Options
> field in the TCP ACK Headers for protocol version notification? Yes, I know
> that there are very few stacks that actually surface that information up to
> the higher levels, but it's there, it's extensible, and it allows us to
> leverage an already existing RTT. Specifically... If an endpont supports 2.0
> on a connection, it would include a specific Option in it's TCP SYN_ACK.

No, you can't.

Extracting information from the TCP transport is a layer violation. It
is pretty much guaranteed to fail through pretty much every form of
middlebox and quite likely to fail through quite a lot that isn't.

Unlike the DNS situation where the network stacks conceal information
the application layer needs, the TCP stacks that conceal this
information have it right. That is what they are meant to do.

One other point here, people need to stop talking in terms of bytes
and instead focus on packets and round trips. Adding 50 bytes to a
packet has negligible performance impact. Sending two packets instead
of one is a much bigger hit. Sending a packet and waiting for a reply
before you send the next one is a major penalty.

Website: http://hallambaker.com/
Received on Wednesday, 22 August 2012 18:34:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC