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