Subject: Adjusting our spec names

From: Mark Nottingham <[email-masked]>
Date: Sat, 31 Mar 2012 12:11:44 +0200

Our current products are named:

HTTP/1.1, part 1: URIs, Connections, and Message Parsing
HTTP/1.1, part 2: Message Semantics
HTTP/1.1, part 3: Message Payload and Content Negotiation
HTTP/1.1, part 4: Conditional Requests
HTTP/1.1, part 5: Range Requests and Partial Responses
HTTP/1.1, part 6: Caching
HTTP/1.1, part 7: Authentication

Note that many of the latter mechanisms are NOT specific to HTTP/1.1; i.e., they will work in an HTTP/1.0 message, and also (according to our charter) must work in a HTTP/2.0 message.

Therefore, I'm inclined to rename them, leading to something like:

HTTP/1.1 Message Format and Connections
HTTP Core Semantics  (combined p2 and p3, which the editors are currently undertaking)
HTTP Conditional Requests
HTTP Range Requests and Partial Responses
HTTP Caching
HTTP Authentication Framework

Thoughts? This doesn't (yet) account for the discussed p0.

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 12:24:09 +0200

> Thoughts? This doesn't (yet) account for the discussed p0.

I've mixed opinions on this. I agree with having p1 become 1.1 specific.
However there might be changes that are worth applying to other parts for
HTTP/2.0 to improve reliability/speed/security and which can still be
mapped 1-to-1 to HTTP/1.1. Some examples include date formats, and
handling of field value lists which are worth changing in 2.0 in my
opinion and which do not imply a change of semantics although being
documented in P2. It's very likely that the caching guys have
suggestions on cache/ranges/conditions.

In the end, why not name everything 1.1 in order to avoid later confusion
if we fix even very minor things in 2.0 ?

Just my two cents,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 31 Mar 2012 12:31:02 +0200

> if we fix even very minor things in 2.0 ?

If we update the caching model in HTTP/2.0 so that it can't work in HTTP/1.1 (i.e., it violates the basic model defined there), I'd be very surprised, and we'd probably be outside our charter scope. Someone might make *updates* to the caching model that's already defined, but that doesn't require us to version its core.

Regarding specific syntax such as Dates - I agree that this might be worth factoring out into a 1.1-specific document.

I'm more sceptical about changing *generic* field-value lists; keeping in mind our need to be able to handle arbitrary 1.1 messages, I don't think we can change too much here.

Regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 13:02:31 +0200

On Sat, Mar 31, 2012 at 12:31:02PM +0200, Mark Nottingham wrote:
> I'm more sceptical about changing *generic* field-value lists; keeping in
> mind our need to be able to handle arbitrary 1.1 messages, I don't think we
> can change too much here.

I know, but this is a real trouble we're all facing and that is worth working
on. I must say I don't have a solution, but by declaring we won't change this
in 2.0, we would discourage anyone from trying to find solutions. From time
to time, applications randomly break because of this list handling. Not long
ago I encountered the issue because of an application putting a comma into a
cookie value. And it's hard to iterate over field-values right now, some
people don't even get it right at all and make a big difference between
multiple header fields and a comma-delimited list of values. So I think
this problem is worth trying to address even if it ends up by handling a
handful of field names which can safely contain a comma (Date, Expires,
Referer, Set-Cookie, ...).

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 31 Mar 2012 11:17:21 +0000

Can I ask a really fundamental question:

How long do we expect HTTP/2.0 to last ?

It sounds a lot to me like people are busy trying to solve the last
remaining problems with yesterdays HTTP/1.1, rather than trying to
build a solid foundation for the next 10-ish years of HTTP.

If you look at what various labs are churning out of wired/optical/wireless
technologies, five years from now, we'll be talking a quite different
environment than now, with respect to bandwidth, RTT and spikiness.

10 years from now, something big will happen, and the big news-sites
will be expected to deliver 1Tbit/sec sustained while everybody and
his goat follows the news in real time.  Ask cnn.com what 9/11 felt
like, and move it up three orders of magnitude or more.

None of the proposals we have seen so far is anywhere near being
feasible in such a context.

We simply have to do something about stuff like the convoluted and
expensive generation and parsing of Date: headers.

-- 
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: Mark Nottingham <[email-masked]>
Date: Sat, 31 Mar 2012 13:26:17 +0200

> expensive generation and parsing of Date: headers.

PHK - 

Great. A specific problem is best; general hand-wringing about "how long will this last" is less useful.

We can discuss the problem of date generation/parsing. In a 2.0-only chain, it would indeed be nice if we could dispense with this altogether (e.g., with a separate set of headers to replace date/last-modified/expires that get transformed to them on a 1.x hop only). Let's discuss that.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 31 Mar 2012 12:13:38 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>We can discuss the problem of date generation/parsing. In a 2.0-only 
>chain, it would indeed be nice if we could dispense with this altogether 
>(e.g., with a separate set of headers to replace 
>date/last-modified/expires that get transformed to them on a 1.x hop 
>only). Let's discuss that.

Yes, we absolutely need to do that.

But there are things we should think about before that, such as

"Why do we even need a Date: header in the first place" ?

It's not like we're talking store-and-forward messaging...

My preference for how to shape the WG progress, would be to set up
a number of straw-man scenarios, and work through them to understand
where it is HTTP/1.1 come up short, and what HTTP/2.0 needs to do
better.

For example, if one of the strawmen is "1 Tb/s HTTP served on
a single IP#" we will probably end up with an analysis like:

	The first thing our incoming requests sees is a
	load-balancer/director gadget, which would much more precisely
	be named a "HTTP-router"

	Typically requests are distributed to backend HTTP servers
	based on relatively crude metrics, typically:

		Host:
		URI suffix (".jpg" vs. ".html")
		Session(-cookies)
		Extrinsic information (server load, etc.)

	While compression in general is a desirable thing, there
	may be a compelling argument for at least making it possible
	to avoid/prevent compression of these "envelope-fields" in
	order to reduce the amount of work a http-router has to do.

	The parallels to flow-routing should certainly be explored,
	in particular with respect to a session-concept that doesn't
	rely on cookies.

Ohh, so having a robust session-mechanism is important at the
second-lowest level of HTTP transport ?

Hmm, maybe we should pay some attention to that, rather than have
people kludge it with cookies.

And so on...

HTTP/2.0 needs to be a visionary standard, otherwise we'll just
be slowing down progress.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 1 Apr 2012 06:49:05 +0200

> environment than now, with respect to bandwidth, RTT and spikiness.

I can believe there is a different world ahead w.r.t. bandwidth, but seeing
massive RTT decreases would be surprising. Even if switching delay is
reduced to zero, speed-of-light still dominates the RTT costs. We could go
back to microwave to get some of the RTT costs down (I understand that some
of the real-time traders do this), but it seems unlikely to offer the same
bandwidth (who knows?). In any case, we're looking at something like an
improvement from 2/3rds speed-of-light plus epsilon to 1/1 speed-of-light
at best.

> feasible in such a context.

What is your basis for this statement? After all, your argument about
technology improvements in the future cuts both ways:  Are you assuming the
presence or lack of presence of hardware acceleration for any of the
features that may be required for any of the things required in any of the
proposal?

> expensive generation and parsing of Date: headers.

I completely agree on that one. Arguably that could be said for cookies and
the URL, etc. as well...

As for your first point... are you suggesting that we develop something
other than HTTP/2.0?
I'd suggest that we should design so that this is possible, but... I think
that (charter aside) things which are fundamentally different from what
HTTP does today would be biting off more than we can chew right now :/

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 1 Apr 2012 07:33:29 +0200

Hi Roberto,

On Sun, Apr 01, 2012 at 06:49:05AM +0200, Roberto Peon wrote:
> reduced to zero, speed-of-light still dominates the RTT costs.

There are basically four things which keep the RTT high :
  - speed of light (intercontinental traffic)
  - time division multiplexing as seen on DSL and Mobile environments
  - queuing (extremely present in mobile environments)
  - serialization (almost null right now)

The former is expensive but is in part addressed by geolocation, though after
that it will not shrink anymore. For instance from here in France :

  $ ping -c 3 www.ucla.edu
  PING www.ucla.edu (169.232.33.224) 56(84) bytes of data.
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=1 ttl=50 time=162 ms
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=2 ttl=50 time=162 ms
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=3 ttl=50 time=163 ms

  $ ping -c 3 www.google.com
  PING www.l.google.com (173.194.66.106) 56(84) bytes of data.
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=1 ttl=50 time=10.5 ms
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=2 ttl=50 time=10.6 ms
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=3 ttl=50 time=10.5 ms

The second is still important in 3G networks but is shrinking with increasing
bandwidth, because you always want approximately the same frame size to fit
in a time slot. Right now figures around 30 ms TTI are common in field, yielding
a minimum RTT on empty networks around 60 ms. But recent HSPA updates already
indicate a 2ms TTI. DSL providers have the same issue BTW, and some french ones
are still charging you with an option to reduce your ping time by not padding
small frames !

The third is probably the worst that is experienced on congested networks
everywhere there are speed differences between the two sides, because it's
common to see large buffers there (eg: several megabytes sometimes in 3G),
which is causing a large number of frames to wait. The good point here is
that this queuing time solely depends and the outgoing bandwidth so it is
expected to significantly drop.

> We could go

And it doesn't stand the long range, which is where it would be most helpful.

> features that may be required for any of the things required in any of the

I would be careful when suggesting hardware acceleration. It's already very
hard to get a round trip between CPU and a 10G NIC below 1 microsecond. And to
achieve this, you have to perform active polling using spinlocks (as traders
do). You can't use interrupts anymore otherwise you waste a lot of time. 1
microsecond is short and long at the same time. It's too short to allow you
to do something else (eg: context switching is much more expensive), and it's
very long because if you're waiting for your hardware to compress your frame
for instance, basically you're limited to one million frames per second, which
is lower than what current implementations can achieve on pure software.

You also have the option to share the device between multiple threads but
this involves a painful locking and for having discussed with you, I know
we both shared the same experiences with locking costs which completely
defeat the expected parallelism.

Also, we must keep in mind that the web is currently migrating back to
software only with virtualized environments. This is really not something
to forget !

> I completely agree on that one. Arguably that could be said for cookies and

Agreed too, except that for cookies the solution is far from being easy, as
many applications use a number of different context-based cookies, so the
solution is not trivial if we want to guarantee the 1:1 compatibility with
existing applications. That's what you tried to address by compressing
headers and what we tried to address by factorizing them. Maybe other options
exist, I don't know. Perhaps Roy had ideas on the subject when working on
Waka ?

Regards,
Willy