- From: Mike Belshe <mike@belshe.com>
- Date: Thu, 5 Apr 2012 16:33:23 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, William Chan (陈智昌) <willchan@chromium.org>, Willy Tarreau <w@1wt.eu>, patrick mcmanus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>, Peter L <bizzbyster@gmail.com>
- Message-ID: <CABaLYCuGRAh337y86oppgUnw7ZBo-UJS2Yud+Au9XG4VH2dz1A@mail.gmail.com>
On Thu, Apr 5, 2012 at 12:24 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > > On 05/04/2012, at 11:55 AM, Mike Belshe wrote: > > >> In other words, the least-common-denominator sucks.... > > You don't have to resort to l-c-d in order to make your protocol > non-hostile to other transports. > > In many ways TCP, certainly compared to many other contenders at > the time of distinction, _is_ l-c-d: Just a byte stream. > > I think we can take it as a given that HTTP over UDP will exist pretty > soon: Between a surrogate like Varnish or HA-Proxy and the http-server > in the same rack, it would cut a fair bit time of transactions and > a lot of objects fit perfectly well inside a 64Kb UDP packet. > I would propose that HTTP only concern itself with reliable transports. A reliable transport provides both in-order delivery and guaranteed delivery. UDP does not provide guaranteed delivery (even if you use the 64K hack you mention to avoid the in-order issues), and therefore is not a transport worthy of discussion for HTTP/2.0 by itself. Mike > >> Mark Nottingham writes: > > >Right. I can see accommodating the potential for these things by putting > >a bit of thought into how our specs are factored, but am *not* > >suggesting that we require an existence proof, or spend significant time > >assuring that they're possible. > > seconded. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Received on Thursday, 5 April 2012 23:33:52 UTC