Subject: Optimizations vs Functionality vs Architecture

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Aug 2012 09:19:25 -0400

I am seeing a lot of overlapping discussions in the 'upgrade' thread
where the positions stem from different views as to the importance of
different types of optimization. Specifically we have a choice:

1) Optimize for the state of network conditions now

2) Optimize for the state of network conditions we expect to exist later

3) Design for some sort of balance between the two.

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. It will be a long time before there are no connections that
are not purple, but we can get to mostly purple pretty quick.

It is obvious that HTTP/2 has to establish a connection in every
situation where HTTP/1 will work. It is far from obvious that HTTP/2
must be a Pareto optimization on HTTP/1 and never result in worse
service regardless of the situation.

I do not like the Google approach of hyper-optimizing the protocol to
todays network conditions for that reason. Saving one packet in 20%
might seem important now but not if doing so locks us into a scheme
that will be sub-optimal later on.

In particular I do not want to see the whole design compromised for
the sake of reducing latency by a hair in Panera.

If we go for only doing in-band upgrade it means that we always have
to play the guessing game of HTTP/1.1 or 2.0 every time we try to
connect. And this will become even harder if we ever decide to do a
HTTP/3.0.

It is pretty clear to me that we are going to have to support some
form of in-band upgrade. 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.

2012 Latency should only be one of the deciding factors. Other factors
should be:

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

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

* 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.

* IP Port saving: We are racking up Web Services pretty fast at the
moment. At this point there are far more than 66535 Web services in
common use so port numbers are a dead letter.

* Web Services direct connect

Well Known service URLs are only a partial solution when a domain is
serving multiple Web Services. If you have 20+ Web services on your
site that all have a significant CPU load you have basically two
solutions today. The first is to plan ahead and give each service its
own DNS name so that they can be mapped to hosts as required (thus
making WKS irrelevant). The second is to deploy a 2 tier scheme in
which the front end is just a redirect to whatever back end is doing
the work. This is a very common configuration and essentially doubles
the number of machines you need and increases latency for no real
benefit other than making administration possible.

SRV and URI permit a direct connection to the host for the specific
Web Service. There is no need to do tiering just for the sake of
mapping the protocol onto the HTTP Web Service endpoint.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 21 Aug 2012 13:36:34 +0000

In message <[email-masked]>
, Phillip Hallam-Baker writes:

>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.

>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

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%.

>to support the new spec as fast as possible

Not agreed, see above.

>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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Aug 2012 10:01:24 -0400

> in party mode, doesn't mean that wallets fly out of pockets.

IPv6 tried a different approach. They tried to block functionality.
Specifically they decided that if you wanted more than one computer at
home you had to demand IPv6 from your ISP.

Then when people started using NAT boxes instead they went on a foot
stomping rant trying to stamp them out. They botched IPSEC in the
process so that none of the companies I have worked for that have
IPSEC VPNs have been able to use them with the stock Windows or Mac
clients.

Only recently has it started to penetrate that NAT is the way to
deploy IPv6 and that people are not going to wait for an
infrastructure deployment to complete to get required functionality.

That is the important difference between 'purple is better' and
'purple is essential'.

> benefit from all we can cause to happen.

You are proposing to change the software running in about 4 billion
computers. There is nothing remotely humble about it.

I think we have to be realistic and not place too big a bet on purple.
But the critical thing is that we can decide what purple looks like.
We can probably get a fix to one piece of Internet infrastructure
here.

Fixing DNS at the LAN side is the biggest win we can hope for right now.

> from unsecure to secure connection without a new TCP.

I am pretty sure that it is impossible to do that in a way that is not
vulnerable to a downgrade attack. Encrypting the transport is of zero
security benefit unless you can be reasonably sure you are encrypting
under a key that the attacker does not know.

This was not a big concern when the threat model was bank fraud types
like the Russian Business Network. Now the threat comes from the
government that gives them safe harbor and from Iran and from various
other governments.

> and unsecured requests could share a connection (think intermediary

I think we need to stop talking about 'intermediaries' and specify
whether they are client-side or server side. It makes a very big
difference.

> security, even before the user has pushed the "login" button.

That is actually a model I am working on in Omnibroker. I replace the
DNS client connection completely so that instead of taking DNS packets
from the local (likely mucked up) DNS resolver, I take them from a
trusted service that the user (or enterprise) chooses. This would be
likely something provided by Comodo or McAfee or Symantec as part of
their AV suite.

One big performance gain here is that there only needs to be one UDP
request/response rather than the six concurrent requests Google were
talking about. Instead of the IKEA approach of asking for connection
parts, the client just asks 'How to I get to DNS name X with protocol
Y' and back comes the IP address, port, transport security and key
authentication info.

This model is actually implicit in the traditional 'recursive
resolver' model. DNS is a pretty whacky protocol that very few
platforms even attempt to implement. They push the complexity onto the
resolver for a good reason - the protocol totally sux. Rather than fix
some obvious design oversights (e.g. how does a client resolve a
pointer to a DNS server that has a DNS name served by it) the
designers did kludges like glue records.

>>to support the new spec as fast as possible

OK, can we agree if I stipulate that changes have to be modest and achievable?

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

Depends on how fast we implement.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 21 Aug 2012 14:08:40 +0000

In message <[email-masked]>
, Phillip Hallam-Baker writes:

>IPv6 tried a different approach. 

The major mistake with IPv6 was to not deliver any improvement
worth the hazzle of migrating to the new protocol.

HTTP/2.0 could easily, even trivially, fall prey to the same problem,
in particular if the complexity of implementing HTTP/2.0 is too high
relative to HTTP/1.1.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Aug 2012 18:13:29 +0300

> in party mode, doesn't mean that wallets fly out of pockets.

Yup. While I agree that everyone would prefer the web to be faster, I am not convinced that a lot of people are bothered enough by how slow the web is to go through upgrade pains.

> from unsecure to secure connection without a new TCP.

Really?  RFC 2817 has been around for over 12 years, and has seen very little use.

> and unsecured requests could share a connection (think intermediary

I'm not in the TLS-all-the-time camp, but why would you want to mix secure and insecure content? How would the user know what parts of the screen that he sees are secure and what parts are not?

> security, even before the user has pushed the "login" button.

I don't like opportunistic. Security is all about guarantees. Opportunistic encryption doesn't give you any guarantees. A statement that there's a 95% chance that you have 256-bit security is meaningless, while a statement that you definitely have 64-bit security eliminates most attackers.

> decide when they think which one has best probability of suceeding.

We should if it's possible. Suppose HTTP/2.0 looks much like the SPDY draft. How can you ever get a current HTTP/1 server to reply to this? The only way you can do that is if you make HTTP/2 at least at the start resemble HTTP/1. And then you have the in-band upgrade forever, just like Phillip said.

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

Depends of how you measure market share. By sheer number of servers (counting all those web configuration screens for home routers and toasters) - yes. But we are very likely to have support in the big websites that people use a lot, so we could have a much higher number for percentage of requests.

Even now, Chrome + newer Firefox have together >50% share. Queries to Google services make up 6% of the web, so SPDY already has a market share of 3%. If we also add big sites like Facebook and common implementations like Apache, that percentage could go up really fast.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Aug 2012 11:36:07 -0400

On Tue, Aug 21, 2012 at 11:13 AM, Yoav Nir <[email-masked]> wrote:

> I'm not in the TLS-all-the-time camp, but why would you want to mix secure and insecure content? How would the user know what parts of the screen that he sees are secure and what parts are not?

+1

The mixed content thing is a horror show.

> I don't like opportunistic. Security is all about guarantees. Opportunistic encryption doesn't give you any guarantees. A statement that there's a 95% chance that you have 256-bit security is meani…

I disagree, there is a value to increase the proportion of encrypted
traffic so that encryption is no longer such a red flag for traffic
analysis.

Security is all about risk management, not risk elimination. Back in
1995 we all got that wrong. Some of us came to our senses earlier than
others, hence the stand up row on the Concourse of RSA back in 2000 or
so.

Opportunistic encryption does actually raise the bar on attacks quite
substantially and in particular it increases costs and reduces scope.
An attack that will defeat 95% of the script kiddies but not protect
against the RBN is actually quite useful in practice.

It is not a solution I would like to see for credit card transactions
or anything that matters, but training wheels for crypto have their
uses.

> Depends of how you measure market share. By sheer number of servers (counting all those web configuration screens for home routers and toasters) - yes. But we are very likely to have support in the…

+1

What really matters is the 'expected pain index'.

I think that if the IETF ever told network equipment vendors what was
expected of middleboxes with clarity that the vendors would be only
too happy to comply. Instead we have a nonsense situation where the
NAT vendors were at best ignored, at worse actively sabotaged (IPSEC)
and left to make things work by trial and error.

Tell folk what to do to make things work and they are much more likely
to do it right.

> Even now, Chrome + newer Firefox have together >50% share. Queries to Google services make up 6% of the web, so SPDY already has a market share of 3%. If we also add big sites like Facebook and com…

The question is what percentage of home routers, firewalls etc. would
get in the way of a solution that allowed SRV to be used for
signalling.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 21 Aug 2012 19:14:51 +0000

In message <[email-masked]>, Yoav Nir writ
es:

>I'm not in the TLS-all-the-time camp, but why would you want to mix secure =
>and insecure content? How would the user know what parts of the screen that=
> he sees are secure and what parts are not?

It would (not need to) be different from today.

The point is that the client could open a TCP connection to the server,
and when the user decides to login, those requests/responses can be
secured, without opening another TCP connection as we do today.

If the site expects the user to login, it can start the negotiation
of security even before the user has hit login, shaving the X RTT's
it takes to exchange certificates and keys of the response time.

>We should if it's possible. Suppose HTTP/2.0 looks much like the SPDY draft.
>How can you ever get a current HTTP/1 server to reply to this? 

That's why I've been saying from the start that SPDY was an interesting
prototype, and now we should throw it away, and start from scratch, being
better informed by what SPDY taught us.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 21 Aug 2012 19:16:08 +0000

In message <CAMm+Lwi=[email-masked]>

>The mixed content thing is a horror show.

But HTTP supports that on a connection between a multiplexing
intermediary and a server, so that boat is long since sailed.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Aug 2012 23:47:03 +0300

> better informed by what SPDY taught us.

A requirement for downgrade creates too many restrictions, even if we throw SPDY away. The beginning of a 2.0 connection would have to look enough like 1.x so as to fool existing servers. 

I think we should live with upgrade only, as long as clients can cache the knowledge that a certain server supports 2.0, so that they can skip the upgrade the next time. The extra roundtrip on a first encounter is not that bad.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Aug 2012 16:54:23 -0400

I think the same approach can be used for intermediaries and shows why
having both mechanisms is important.

A HTTP/2.0 connection can fail for two reasons:

1) The server does not support HTTP/2.0
2) An intermediary in the current path is blocking it.

Real machines move from one network to another so it is important to
be able to distinguish between the two modes if the information is
going to be cached. Otherwise we end up in a situation where the cache
is being corrupted by the intermediary.

If the reason HTTP 2.0 is failing is the intermediary blocks it then
the client should stop trying HTTP 2.0 altogether until the network
conditions change. It should certainly not attempt to remember the
effect of trying HTTP/2.0 at specific sites.

If the reason it failed is that the server only supports 1.1, that is
something that can and should be remembered for future use with some
form of reasonable expiry policy so that one failure in 2012 does not
continue to apply in 2020.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 21 Aug 2012 21:30:35 +0000

In message <[email-masked]>, Yoav Nir writ
es:

>A requirement for downgrade creates too many restrictions, even if we throw
> SPDY away. The beginning of a 2.0 connection would have to look enough like
>1.x so as to fool existing servers. 

Yes, and ?

Sending:

	HEAD / HTTP/1.1
	Upgrade: HTTP/2.0

as a preamble on a connection is not very expensive.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 21 Aug 2012 15:00:46 -0700

On Tue, Aug 21, 2012 at 1:47 PM, Yoav Nir <[email-masked]> wrote:

> A requirement for downgrade creates too many restrictions, even if we
> throw SPDY away. The beginning of a 2.0 connection would have to look
> enough like 1.x so as to fool existing servers.
>
>
Note that we'll always have to do downgrade-- perhaps someone deploys a
proxy which doesn't speak HTTP/2, or perhaps the site administrator deploys
a different server or load balancer that only speaks HTTP/1.1 when it used
to do HTTP/2.
These will happen and must be addressed.

> I think we should live with upgrade only, as long as clients can cache the
> knowledge that a certain server supports 2.0, so that they can skip the
> upgrade the next time. The extra roundtrip on a first encounter is not that
> bad.
>

I disagree-- I want the user to experience the lowest latency possible for
all sites possible whenever possible! :)

-=R

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Aug 2012 15:57:02 -0700

On Tue, Aug 21, 2012 at 8:36 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> > I'm not in the TLS-all-the-time camp, but why would you want to mix
> secure and insecure content? How would the user know what parts of the
> screen that he sees are secure and what parts are not?
>
> +1
>
Perhaps when all the traffic is from a single client originating from a
single user-agent within a single application context, I agree... but when
you're talking about traffic between an intermediary handling requests from
a broad diversity of user-agents communicating with an origin server that
legitimately offers both secure and insecure content, the ability to pass
insecure and secure traffic within a single TCP connection [1] could
realize some fairly significant benefits.

[1] http://tools.ietf.org/html/draft-snell-httpbis-keynego-00

> > I don't like opportunistic. Security is all about guarantees.
> Opportunistic encryption doesn't give you any guarantees. A statement that
> there's a 95% chance that you have 256-bit security is meaningless, while a
> statement that you definitely have 64-bit security eliminates most
> attackers.
>
>
Opportunistic does not mean "no guarantee" but then again, "opportunistic"
is a perhaps a poor word choice... I prefer "in session" or "on demand"
encryption, allowing the client and server to selectively apply privacy
protections as necessary without requiring the existing tcp/ip connection
to be re-established. Rules can be established, similar to the Same Origin
Policy, that define how various user agents are to best make use of those
mechanisms in specific contexts -- including when NOT to use mixed traffic
-- but the protocol itself does not suffer from the mixing of plain text
and encrypted content.

- James

> > Depends of how you measure market share. By sheer number of servers
> (counting all those web configuration screens for home routers and
> toasters) - yes. But we are very likely to have support in the big websites
> that people use a lot, so we could have a much higher number for percentage
> of requests.
>
> +1
>
> > Even now, Chrome + newer Firefox have together >50% share. Queries to
> Google services make up 6% of the web, so SPDY already has a market share
> of 3%. If we also add big sites like Facebook and common implementations
> like Apache, that percentage could go up really fast.
>

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Aug 2012 16:24:23 -0700

On Tue, Aug 21, 2012 at 2:30 PM, Poul-Henning Kamp <[email-masked]>wrote:

> throw
Sending is not a problem... but handling it on the server side could be
depending on what work the server needs to do to generate the HEAD
response. As per the spec, "The metainformation contained in the HTTP
headers in response to a HEAD request SHOULD be identical to the
information sent in response to a GET request" .. calculating the Entity
Tag, Last-Modified Timestamp, Content-Length and Content-Type headers could
be rather more expensive than one may expect depending on what's on the end
of that request.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Aug 2012 17:52:43 -0700

On Tue, Aug 21, 2012 at 3:00 PM, Roberto Peon <[email-masked]> wrote:

>> I think we should live with upgrade only, as long as clients can cache
>> the knowledge that a certain server supports 2.0, so that they can skip the
The more I read through this conversation, the more I worry that all this
talk about zero-latency upgrade negotiation through multiple hops of
arbitrary 1.1 or 2.0 servers is going to lead to significantly more
complexity than originally hoped -- and not the acceptable good kind of
complexity that delivers real benefits in the end.

- James

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Aug 2012 14:43:31 +1200

> enough like 1.x so as to fool existing servers.

Quite the opposite IMO. We want the 2.0 services to be able to detect 
the difference and auto-downgrade to 1.x, but we want the 1.x services 
to discard 2.0 attempts cleanly without corrupting the connection 
framing.

* An Upgrade: header amidst a 1.x frame allows this seamlessly. At cost 
of bandwidth on first request.

* A probe OPTIONS/SETTINGS query ahead of the main traffic pipeline 
allow sthis seamlessly. At cost of RTT plus some bandwidth. (ie worse 
than Upgrade:)

* a Happy-Eyeballs double TCP connection allows this on first request. 
At cost of doubling the TCP network load. In the presence of IPv4/IPv6 
happy eyeballs that means maybe 4x TCP connections. Is anyone able to 
show an overall benefit amongst that?

* DNS SRV records easily perform end-to-end detection. But HTTP 
requires next-hop detection. That is at best a useful optimization for 
the last-mile of connections IMO. Not useful at all for the main 
client->server/proxy architecture of HTTP.

>
> I think we should live with upgrade only, as long as clients can
> cache the knowledge that a certain server supports 2.0, so that they
> can skip the upgrade the next time. The extra roundtrip on a first
> encounter is not that bad.

I agree with this.

* it exists and is already well defined.
* it has existing implementations we can leverage.
* it operates on next-hop independent of any connection complexity and 
most legacy software.
* ANY hop can attempt to optimize/Upgrade.
* it has a safe failure mode resulting in 1.1 being used.
* worst-case cannot be worse than standard 1.1 performance (since 
failure ist to use 1.1).

The downside is all in the implementation code specifics. ie it is 
*our* problem to find easy implentation methods, not impacting the 
users.

Amos

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Aug 2012 20:03:43 -0700

On Tue, Aug 21, 2012 at 7:43 PM, Amos Jeffries <[email-masked]> wrote:

> [snip]
> * worst-case cannot be worse than standard 1.1 performance (since failure
> ist to use 1.1).
>
> The downside is all in the implementation code specifics. ie it is *our*
> problem to find easy implentation methods, not impacting the users.
>
>
Ok.. so how exactly would this work... suppose all I want to do is a simple
HTTP GET. Am I going to send a 1.1 GET request with an Upgrade header and
wait for the response to come back as HTTP/2.0 or do I send an HTTP 1.1
OPTIONS request with upgrade, check to see if 2.0 is supported, then send a
HTTP 2.0 GET request second? In the former case, assuming we are indeed
using SPDY, we won't have an established SPDY Stream yet within which to
send the response so I'm not quite sure how that's suppose to work. In the
latter case, we're wasting one RTT to upgrade the request (which,
thankfully, should only need to happen once per connection...).

- James

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Aug 2012 15:07:59 +1200

On 22.08.2012 12:52, James M Snell wrote:
>>> >> We should if it's possible. Suppose HTTP/2.0 looks much like the 
>>> SPDY
>>> draft.
>>> > prototype, and now we should throw it away, and start from 
>>> scratch,
>>> being
>>> cache

I'm more positive. Many of these proposed mechanisms are non-starters 
for one reason or another. Meanwhile we are building a good list of 
requirements that the final solution(s) must meet in order to be useful 
adding to the spec.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Aug 2012 15:15:31 +1200

On 22.08.2012 11:24, James M Snell wrote:
>> In message <[email-masked]>, 
>> Yoav
>> Nir writ
>> es:
>>
>> > SPDY away. The beginning of a 2.0 connection would have to look 
>> enough
>> like

That would be why HEAD is a bad choice.

We also have prefix request:

  OPTIONS * HTTP/1.1
  Max-Forwards: 0
  Upgrade: HTTP/2.0

Which can be replied to with:

  HTTP/1.1 101 Switching Protocols
  CRLF
  <HTTP/2.0 response frame with transport options/features available>

or,
  HTTP/1.1 200 OK
  <frame with 1.1 options>

Whether this is better or worse than just adding Upgrade: to the first 
GET depends on whether we do SPDY-style gzip compression on headers, or 
an adaptive dictionary style learning as per network-friendly.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Aug 2012 15:28:39 +1200

On 22.08.2012 15:03, James M Snell wrote:
> On Tue, Aug 21, 2012 at 7:43 PM, Amos Jeffries wrote:
>
>> [snip]
>> failure
>> *our*
> HTTP 2.0 GET request second?

(Just replied to this in response to the other email about HEAD 
requests.)

> In the former case, assuming we are indeed

Which is reason #1 why server-initiated stateful sessions don't work on 
a pull architecture. SPDY session flow control needs to be thrown away 
and re-designed to use implicit instead of explicit setup. The 
network-friendly draft had implicit hop-by-hop session creation and 
teardown based on WebSockets - with the benefits described in mobility 
draft - it works more efficiently than SPDY stateful session handshake 
is capable of. We picked it per-request to keep teh 1-to-1 
request/response mapping of HTTP/1 but there is no technical reason taht 
cannot be extended to handle future server-push or client-push features.

Essentially a session can be created on client request receive, and 
persists as long as necessary with associated "state". 1 response or N 
responses it does not matter. But never mind that for now. I'll pull out 
the details when we get as far as flow control designs.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 22 Aug 2012 06:06:16 +0000

In message <[email-masked]>

>complexity that delivers real benefits in the end.

That's my conclusion too.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Aug 2012 17:03:32 +0200

On 8/22/12 4:43 AM, Amos Jeffries wrote:
> 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?

Eliot

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Aug 2012 08:11:32 -0700

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.

---

From: Albert Lunde <[email-masked]>
Date: Wed, 22 Aug 2012 11:36:02 -0500

On 8/22/2012 10:11 AM, James M Snell wrote:
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:

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  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Aug 2012 10:51:41 -0700

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 <[email-masked]> wrote:

> may need to know something of what might be happening end to end. What is
> the least-common-denominator that is supported?
>
> provider wants all their phones to speak HTTP 2.0, and provides a gateway
> to downgrade to HTTP 1.1 or 1.0.
>
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Aug 2012 14:33:47 -0400

On Wed, Aug 22, 2012 at 1:51 PM, James M Snell <[email-masked]> wrote:
> 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.

---

From: James M Snell <[email-masked]>
Date: Wed, 22 Aug 2012 12:29:51 -0700

> 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

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 23 Aug 2012 12:11:11 +1200

> try to use HTTP 2.0 on port 80.

Yes. agreed.

You would face the same upgrade issues if you were to attempt SPDY on 
port 80. But once you change the port you change the assumed protocol 
away from HTTP/1 and enable the NPN upgrade method to identify SPDY vs 
HTTP/1 vs HTTP/2 or whatever.

Our charter as proposed requires that HTTP/2 operate over existing web 
infrastructure. Which means port-80 for a vast majority of networks - 
where HTTP/1 is assumed by every hardware transistor along the way. I 
see the DNS and alternative as optimizations we *might* be able to use 
for faster setup, but cannot guarantee working.

Amos

> On Wed, Aug 22, 2012 at 8:03 AM, Eliot Lear wrote:
>
>>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 23 Aug 2012 02:56:41 -0700

On port 80, the only thing you can rely upon working is the most commonly
used subset of http/1.1.

Thus, user-agents and servers must handle both upgrade and downgrade as
necessary basically all the time.

-=R
On Aug 22, 2012 5:13 PM, "Amos Jeffries" <[email-masked]> wrote:

> You would face the same upgrade issues if you were to attempt SPDY on port
> 80. But once you change the port you change the assumed protocol away from
> HTTP/1 and enable the NPN upgrade method to identify SPDY vs HTTP/1 vs
> HTTP/2 or whatever.
>
> infrastructure. Which means port-80 for a vast majority of networks - where
> HTTP/1 is assumed by every hardware transistor along the way. I see the DNS
> and alternative as optimizations we *might* be able to use for faster
> setup, but cannot guarantee working.
>
> Amos
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Aug 2012 07:44:12 -0400

Which is one reason I like SRV, you can specify a different port.

I think we have to decide what we mean by make intermediaries work, do
we mean that the user gets the experience they expect or do we mean
that the deployer of the intermediary gets to control that experience?

I don't see that we really need to consider proxies as anything more
than a roadblock to get through.

On Thu, Aug 23, 2012 at 5:56 AM, Roberto Peon <[email-masked]> wrote:
>> and alternative as optimizations we *might* be able to use for faster setup,
>> but cannot guarantee working.
>>
>> Amos
>>