Subject: Re: HTTbis spec size, was: Rechartering HTTPbis

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 04:45:03 +0100

lör 2012-01-28 klockan 11:50 +0100 skrev Julian Reschke:

> I *agree* with improving the layering, and maybe giving the transport 
> layer a specific name, but "HTTP/2.0" it can't be.

My vision of HTTP/2.0 is

- HTTP message definition, defined largely by what we have today minus
anything transport related, and trowing out any special cases. No
definition of message delimiting, no chunking, no connection management,
no folding, etc. That's all transport defined.

- Definition of required transport properties/interface for HTTP message
exchanges.

- Definition of suitable transports ontop of TCP, TLS, UDP, DTLS, SCTP.
Each separate, mapping the requirements of the above. Completely
ignorant of any semanitcs of HTTP beyond the most basic structure.

- Mapping guidelines how to map relations bewteen transport identity
assosciations and messages, i.e. how transport level authentication fits
with messages.

- Defined upgrade paths from HTTP/1 to HTTP/2. I.e. HTTP Upgrade, TLS
negotiation, SRV records, etc...

I do not see a great need for a new semantic model. But several things
that need to change on the wire to provide a robust & efficient protocol
that can be built upon for the next several decades.

Regards
Henrik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Feb 2012 19:26:22 +0000

In message <CA+9kkMAj1vnTsxe7OLRVHSMZmDF5F=[email-masked]>
, Ted Hardie writes:
>2012/2/5 Henrik Nordstr=F6m <[email-masked]>:

>So, two of the transports you list above (UDP and DTLS) are unreliable; is
>reliability not a transport property you expect for HTTP message exchanges?
>[...]
>Of course you can build reliability on top of unreliable transports,

Lets try to be a bit more exacting with our vocabulary, shall we ?

TCP is not "reliable" any more than UDP is, many TCP connections
fail, both during establishment and later.

What TCP offers is "we'll hide all the retransmissions and pretend
to be much more reliable than the underlying network" which is often
convenient.

But for many HTTP-purposes, UDP would be good enough:  You send the
request and either you get a reply or you do not.  That isn't very
different from a TCP connection breaking.

Obviously, HTTP over UDP would be very exposed to DoS, so it should
probably be confined to behind firewalls and other walled gardens,
but I can certainly see the utility for a number of cases.

-- 
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: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2012 12:05:21 -0800

> to be much more reliable than the underlying network" which is often

"reliable transport" is a term of art for what you describe above;
I see no reason to redefine commonly understood terms.  At best,
that is going to add time for explanation and at worst, it will add confusion.

>different from a TCP connection breaking.

Personally, I see this as pretty different, but your mileage clearly
varies on that point.

Would you propose different method names for this mode, so that they
were distinguishable
to intermediaries, or would propose that the semantics of the method
be determined by
the transport on which it arrived?

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2012 11:03:13 -0800

Of course you can build reliability on top of unreliable transports,
but that seems
to go against the idea of clean layering (since it is usually the app
the recreates
the reliability).  Can you provide some clarification of your thinking here?

regards,

Ted

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 21:07:50 +0100

> reliability not a transport property you expect for HTTP message exchanges?

Depends on the message and application. The point here is that there is
no reason to confine HTTP to TCP. You obviously only use the UDP
transport when you know the network is in a good shape and when loosing
a message here and there is not a big deal, and there is several such
applications.

And DTLS is not by definition unreliable. It may be used alike over
unreliable transports such as UDP or over reliable message transports
such as SCTP. The reliability of the delivery in DTLS is a property of
it's underlying transport, not the DTLS protocol as such.

HTTP is a request/response message exchange protocol. At the high level
message level it's pretty ignorant about the transport.

Regards
Henrik

---

From: Robert Collins <[email-masked]>
Date: Tue, 7 Feb 2012 09:17:15 +1300

>> layer a specific name, but "HTTP/2.0" it can't be.
..
> that can be built upon for the next several decades.

FWIW - this is pretty much exactly what I'd like to see as well, both
wearing my squid hat, and my 'runs a complex web environment with
stacked accelerators, caches, heterogeneous appservers etc' hat on.

-Rob

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Feb 2012 21:16:07 +0100

> to be much more reliable than the underlying network" which is often

I'd say there are different classes of problems with TCP. It's more
reliable under most common conditions and can be worse than UDP sometimes
(eg: high loss rate, multiple congestion controls stacked on top of each
other etc). But FWIW TCP is generally known as a "reliable" transport
mechanism.

> different from a TCP connection breaking.

I think this is what UPNP looks like, I've already caught many HTTP-looking
requests over UDP multicasts.

> but I can certainly see the utility for a number of cases.

For small static files (eg: favicon.ico), UDP is much better suited than
TCP, one packet in each direction and let the client retry if it does not
get the response. You can extend the principle with content ranges where
the client asks to retransmit what it did not get. For the server it's
very convenient, no state to keep, everything runs at wire speed, no timeout
issues, no SYN_RECV nor CLOSE_WAIT states, etc... It's simply limited to a
very specific usage which might still cover most of the web's requests.

Regards,
Willy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2012 12:53:40 -0800

2012/2/6 Henrik Nordström <[email-masked]>:
> mån 2012-02-06 klockan 12:05 -0800 skrev Ted Hardie:
>
> I would simply state that there is no guaranteed delivery status when
> HTTP/UDP is used. Messages MAY be silently lost when using such
> transport and it's up to to the application to handle it gracefully.

There's also no guarantee that all messages will fit into a single UDP packet,
so you may get partial messages that need to be discarded.

>How
> is outside of the specification. There is also other very noticeable
> limitations of HTTP/UDP such as maximum message size which is fairly
> small. I.e. 64KB on a good day.
>
> If reliable datagram transport is desired then use HTTP/SCTP.  It's a
> very real alternative in the environments and for the applications where
> HTTP/UPD is interesting and provide much the same properties in
> unordered (but well defined) delivery of interleaved messages and other
> nice properties.
>
Note that many of the deployments of SCTP currently run over UDP.

regards,

Ted

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 21:28:47 +0100

transport and it's up to to the application to handle it gracefully. How

Regards
Henrik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Feb 2012 20:28:43 +0000

In message <[email-masked]>, Willy Tarreau writes:
>On Tue, Feb 07, 2012 at 09:17:15AM +1300, Robert Collins wrote:
>> FWIW - this is pretty much exactly what I'd like to see as well, [...]
>
>I too agree on this. [...]

+1

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Feb 2012 21:26:39 +0100

> stacked accelerators, caches, heterogeneous appservers etc' hat on.

I too agree on this. In my opinion, what made HTTP succeed so well is
that there are places for any sort of new component that can fit a given
application's usage. Almost everything can be inserted between two ends
to extend features, performance, security, filtering, etc...

We clearly need some polishing on the semantics to avoid interoperability
issues we have all been facing from time to time, but I think the model
is fine.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Feb 2012 20:18:00 +0000

>"reliable transport" is a term of art for what you describe above;

Yes, but people seem to leave the "transport" bit off and just say
"TCP is reliable" which leads to sloppy thinking and invalid
conclusions.

>Would you propose different method names for this mode, [...]

No, that would be missing the point about separating transport
from interpretation.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2012 13:07:41 -0800

> it's underlying transport, not the DTLS protocol as such.

"Datagram transport does not require or provide reliable or in-order
   delivery of data.  The DTLS protocol preserves this property for
   payload data.  "

The major point of DTLS is that it works without a reliable transport; its
advantages over TLS are there.  At least as I understand it, it also does not
guarantee this property when run over any transport.   It might, for example,
deliver data out of order even when the underlying transport will re-transmit
to get in-order delivery; it depends on the implementation to determine when
the data is passed up.

> message level it's pretty ignorant about the transport.

I suspect it gets to be ignorant about the transport in part because it gets
to assume certain things about the transport.  If you change those things,
I think the applications that are built on top of HTTP may want new tools from
HTTP (or they will each have to build those same tools for themselves).  This
is particularly the case for applications where non-idempotent methods are
used.

regards,

Ted

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Feb 2012 23:02:13 +0100

> but I can certainly see the utility for a number of cases.

If you are interested in a REST-style transfer protocol that runs over datagram transports (such as UDP and DTLS) at a low level, you may want to look at CoAP.

http://tools.ietf.org/html/draft-ietf-core-coap-08

CoAP might work well for favicon.ico :-)
(It is designed for constrained node/networks.)

Also have a look at coap-block (for payloads larger than what you like to have in a single datagram) and coap-observe (for going beyond original REST).

CoAP is different enough from HTTP that it may not be a drop-in, but if all you need is a back-end protocol behind, say, varnish, that runs on datagrams, it may be worth a look.

Grüße, Carsten

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 23:28:44 +0100

>    delivery of data.  The DTLS protocol preserves this property for

This is a property of the underlying transport, not DTLS itself. DTLS
preserves the same guarantees (or lack thereof) as the underlying
transport.

> advantages over TLS are there.

Yes.

> At least as I understand it, it also does not
> guarantee this property when run over any transport.

That's not my understanding. If the transport is reliable then DTLS is
as well.

> It might, for example,

Not sure what you talk about here. in-order transports do not provide
DTLS out-of-order access to the data.

> is particularly the case for applications where non-idempotent methods are

Well, to be honest those problems are there already even with TCP. Just
slightly different.

Please note that I do not say that HTTP/UDP is universally applicable to
all applications or even makes sense at all times. Only that UDP is one
of many transports HTTP may operate over and which makes sense for some
applications.

There is applications using HTTP/UDP today even if not part of any HTTP
standard. Not because it's cool, but because it makes sense for those
specific applications.

Regards
Henirk