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

Re: Optimizations vs Functionality vs Architecture

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 21 Aug 2012 13:36:34 +0000
To: Phillip Hallam-Baker <hallam@gmail.com>
cc: ietf-http-wg@w3.org
Message-ID: <83663.1345556194@critter.freebsd.dk>
In message <CAMm+LwjSVHzRQS3W4NLBQfe+Bmpk2c5ovuOtrNjOSx1EDBDG0g@mail.gmail.com>
, Phillip Hallam-Baker writes:

>Unlike most protocol proposals, HTTP/2 is big enough to drive changes
>in infrastructure. If HTTP/2 will go faster over a purple Internet
>connection then pretty soon there will be purple connections being
>installed. 

Provided, and this is a very big variable, that HTTP/2 brings enough
benefits to pay for the purple internet.

IPv6 should have taught everybody, that just because the IETF is
in party mode, doesn't mean that wallets fly out of pockets.

I would advocate a much more humble attitude, where we design
and architect expecting few changes, but such that we can
benefit from all we can cause to happen.

>It is pretty clear to me that we are going to have to support some
>form of in-band upgrade.

This is actually one of the things users are asking for:  Upgrade
from unsecure to secure connection without a new TCP.

A closer analysis shows that it would be even better if secured
and unsecured requests could share a connection (think intermediary
to server for instance.)

Such a mixed mode might even allow oppotunistic negotiation of
security, even before the user has pushed the "login" button.

>But even if that turns out to be the fastest
>choice in 2012 deciding to only do in-band upgrade means that we are
>permanently locked into a sub-optimal solution in perpetuity.

No, thats not a given.

Nothing prevents us from designing a procedure which allows for
both upgrades and downgrades, and leave it to protocol users to
decide when they think which one has best probability of suceeding.

We should do that.

>* Can we move to a HTTP/3.0 in this scheme? If not its a non starter.

Agreed, 100%.

>* 2016 Latency: Performance after 80% of the network has been upgraded
>to support the new spec as fast as possible

Not agreed, see above.

>* 2020 Latency: Performance when the remaining legacy can be ignored
>as far as latency issues are concerned, people using 2012 gear in 2020
>are not going to be getting world class latency anyway.

Not agreed, I doubt HTTP/2.0 will have more than 40% market share
by 2020.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 21 August 2012 13:37:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 August 2012 13:37:25 GMT