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

Re: Optimizations vs Functionality vs Architecture

From: James M Snell <jasnell@gmail.com>
Date: Wed, 22 Aug 2012 12:29:51 -0700
Message-ID: <CABP7Rbc_KdTL7OfGBdvADTmyEmr7pp=XxuGHGR5Vxwe-AFBKow@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: ietf-http-wg@w3.org
On Aug 22, 2012 11:33 AM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
>
> 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.
>

That's what I suspected but wanted to at least surface the idea. Never
hurts to ask ;) ...

- James

> 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 19:30:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 August 2012 19:30:25 GMT