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

Re: The List (of application-layer desired features)

From: Mike Belshe <mike@belshe.com>
Date: Tue, 6 Aug 2013 11:26:13 +0200
Message-ID: <CABaLYCtnLWgT=YYFzpRjLAUGDS3+1bP6eSPyF7ocYdgzxUaPZg@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: tsvg@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Aug 6, 2013 at 10:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

> For those of you who missed it, at the HTTPBis/TSVG joint session, a
> question about what applications want from the transport (I really want to
> put quotes around that) came up.
> Here is a rendition of what was on the note that I jotted down in response
> to this question, and which I passed to people at the mic.
> (Apps-folks want the following) Deployed in 1996:
> -----------------------------------------
> - Prioritization
> - Partial Reliability
> - "Shared" congestion between multiple streams
> - Security
> - No HOL blocking on stream X when loss on stream Y
> - Cheap/Fast  channel/connection setup

I think this is far-and-away the biggest area for latency improvements.  We
should be able to have a handshake negotiated once, and reuse that forever.
 (e.g. forever connections)  The server can revoke, of course, and force a
new handshake if needed.  But if I authenticated and established a secure
channel 5 hours ago, there is no reason I shouldn't be able to resume that
channel again without incurring a round trip before data can be sent.
 Obviously, this needs to be done without server-side state.


> - Wide, "safe" deployment
> - Competes with TCP/HTTP/1.1 (performance-wise)
> - Multipath/roaming robustness, i.e. the "driveway" problem
> I'll reiterate that by far the most important feature is "is deployed".
> Nothing else matters until that is true, at least at the application-layer.
> -=R
Received on Tuesday, 6 August 2013 09:26:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC