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