Re: Optimizations vs Functionality vs Architecture

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.

- James

On Wed, Aug 22, 2012 at 9:36 AM, Albert Lunde <> wrote:

> On 8/22/2012 10:11 AM, James M Snell wrote:
>> I would say no. It's no different, for instance, than using any other
>> tcp-based protocol.. you wouldn't use http to determine if ftp is
>> supported, for instance. The upgrade path should only be required when
>> we try to use HTTP 2.0 on port 80.
>> On Wed, Aug 22, 2012 at 8:03 AM, Eliot Lear <
>> <>> wrote:
>>     On 8/22/12 4:43 AM, Amos Jeffries wrote:
>>      > * DNS SRV records easily perform end-to-end detection. But HTTP
>>      > requires next-hop detection.
>>     Is that true for ports other than 80?  That is- if you have an
>>     indication to use, say, port 880, and you're going right to SPDY, do
>> you
>>     need next-hop detection for purposes of versioning at least?
> It's a bit like path-MTU detection, too. If you want to account for HTTP
> proxies (and more obscure intermediaries) in the path to the server, you
> may need to know something of what might be happening end to end. What is
> the least-common-denominator that is supported?
> This is where DNS records like SRV or the proposed URI can't give the
> complete picture.
> Another case is a gateway that does protocol conversion: say a phone
> provider wants all their phones to speak HTTP 2.0, and provides a gateway
> to downgrade to HTTP 1.1 or 1.0.
> --
>     Albert Lunde
>           (address for personal mail)

Received on Wednesday, 22 August 2012 17:52:29 UTC