Identifying QUIC deliverables

https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s

by arusahni • 8 years ago

253 182 8 years ago

mailarchive.ietf.org

Lotus123• 8 years ago

It seems they are getting ahead of themselves...why should it be a good idea to burn the http/3 name now given the stage of development quic is in?

xori• 8 years ago

Names aren't sacred. Windows skipped 9 for technical reasons, iPhone skipped 9 for marketing reasons. They only people impacted by a skipped http/3 would be technical people upgrading from /2 to /4 in 5 years.

m_eiman• 8 years ago

I really, really hope we're not going to be replacing fundamental low-level infrastructure code every five years.

Keep the web frontend culture contained where it is now, don't let them ruin everything else too.

isostatic3• 8 years ago

Windows skipped 9 for technical reasons

Really? I thought it was because they don't plan to release another major version of windows, and wanted the number to have a nice solid "10", rather than a "9"

tyingq• 8 years ago

"confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things."

Well, yeah, they have the same name. My first reaction to the headline was that lots of software isn't ready for http over udp.

zamadatix2• 8 years ago

The protocol differences are miniscule as well, pretty much a version bit and ever so slightly slimmed header requirements IIRC. I remember reading it and thinking "cool, generalized QUIC... looks like I can built an HTTP-like transport with it and that's it".

As for the HTTP over UDP, indeed - there is a reason Chrome has the ability to race a TCP connection alongside QUIC opens :).

ksec• 8 years ago

So what exactly is the QUIC-the-HTTP-binding?

Everything on the web about QUIC is about UDP. It doesn't talk about HTTP/3 and /2 difference. /2 is already complex enough as it is.

tialaramex4• 8 years ago

QUIC offers a bunch of features HTTP wants. So this binding is about how you use those features. In some places HTTP/2 had a feature that QUIC now does better, in others QUIC offers something completely new.

Rebinding is an example of the latter. When you change networks (and thus addresses) in QUIC it can update the ongoing connection seamlessly.

tveita2• 8 years ago

AIUI, the QUIC protocol [1] will be a general-purpose transport protocol built on top of UDP that offers multiple independent streams with encryption. For the application it's like it can open as many TCP connections as it wants, without the extra overhead from handshakes and rate control start.

HTTP-over-QUIC [2] specifies how to talk HTTP 2 over the QUIC protocol, with some adjustments like using "native" QUIC streams instead of multiplexing streams over a TCP stream, and adjusting the header compression to allow more out-of-order operations.

[1] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

[2] https://datatracker.ietf.org/doc/draft-ietf-quic-http/

anentropic• 8 years ago

I had to disable QUIC in Chrome a few days ago, was completely unable to access YouTube, and google.com search only intermittently

maybe they need to make it work first

unethical_ban• 8 years ago

Web proxy software isn't quite ready for it AFAICT.

DanielDent• 8 years ago

One of the ways to get it working is to get more people using it... QUIC is implemented with a number of fallbacks to deal with broken networks, but at some point it's probably better to just let things break and force network operators to fix their broken networks.

mobilemidget• 8 years ago

Seeing how long we have used http 1.0/1.1 (and still); and http/2.0 far from fully adopted, I'm somewhat surprised to see v3 being discussed already and v4 being mentioned in there.

Though maybe it requires way more future vision and planning then I expect.

gcb02• 8 years ago

its all mostly driven by Google pushing thu with chrome constant updates. they can update chrome tomorrow to v3, v4, v10... it's all the same.

on http2/spdy, they at least had the decency to publish something before forcing everyone into adoption

gregmac• 8 years ago

It helps that this also pushed the other browser vendors to step up their games. Firefox switched to a Rapid Release cycle. Even Microsoft is now on board with Edge updating fairly regularly (at least compared to IE).

A few years ago, web sites and infrastructure had to be built to serve decade-old versions. Now it's reasonable to support only a few years-old versions, and this time frame is continuously shrinking as the current generation of evergreen auto-updating browsers takes more market share.

Though I don't like the bit about forcing adoption onto others, I do think that advancing the market to allow standards changes like this to happen in years instead of decades is a good thing.

nextweek2• 8 years ago

What you are seeing is someone picking up the baton and running with it. HTTP 1.1 has drawbacks which we've been living with for far too long. Getting people used to change was step one, that was HTTP/2, now were in a position to fix pain points.

I'd also like to see updates to IMAP, SMTP and FTP to name a few.

numbsafari2• 8 years ago

I'm with you on IMAP and SMTP, as they serve a specific purpose. One thing I don't understand, is why anyone is holding on to FTP at this stage over HTTP. Outside of legacy enterprise "file transfer" appliances, which I deal with all day and can appreciate the inertia around, I just don't understand what the benefit is over HTTP.

otabdeveloper1• 8 years ago

HTTP 1.1 has drawbacks which we've been living with for far too long.

No it doesn't. Don't fix what's not broke, and doubly so if the only motivation for the change is "well, Megacorp (c) says it's the bee's knees".

tptacek8• 8 years ago

The most reasonable "update" to FTP would be to formally replace it with HTTP, because FTP is an awful protocol --- maybe the worst one in common use --- that deserved to die off decades ago.

protomyth2• 8 years ago

I'd also like to see updates to IMAP, SMTP and FTP to name a few.

I would really like to see each of these disappear to be replaced by new ways of doing things. The whole concept of e-mail needs a new thought. FTP should have already gone the way of the dodo if for nothing else the firewall issues its has.

klodolph2• 8 years ago

I don’t think that there’s any reason we should expect HTTP/2 to ever be fully adopted, and it’s not really necessary. I am excited to see TLS adopted everywhere and ALPN, SNI available to everyone who needs it, but once you have ALPN you don’t need to adopt HTTP/2. You can just choose to make HTTP/2 available if you think it will help, and in the future you could choose to make HTTP/3 available as well.

As a website operator, the hard part of HTTP/2 was getting TLS certificiates. As an end-user, I'm just happy that popular web pages load faster. And if most of the world still uses HTTP 1.1 I won’t care.

Making a datagram-based protocol available will open up a ton of possibilities for cool realtime apps over HTTP. Currently you’re stuck with WebSockets or WebRTC and for some applications these solutions aren’t good enough.

londons_explore6• 8 years ago

WebRTC datagrams are very 'close to the wire'. Size them correctly, and they map 1:1 with UDP packets.

I can't think of many network applications you couldn't build on top of them.

NuSkooler• 8 years ago

While HTTP/2 has very clear advantages in many areas, it's losing out on some major HTTP/1 advantages that have allowed it to last so long. Most importantly: Simplicity. One can create HTTP/1 server in just a few lines of code. It's the same sort of reason AT commands are still used over simple serial devices.

While a lot of the modern web is great, it also has drawbacks that should be looked at very carefully: A simple HTTP page from yonder can still be rendered just fine. A modern page can't be rendered properly a year or so down the line. We need modern protocols to solve modern problems we've created such as huge pages with tons of links and back and forth traffic to many servers. While I think work needs to be done in both directions, I don't know what we really need to go so far as to push down yet another HTTP/x protocol this soon. HTTP/1 is going to be used for quite a while still, HTTP/2 solves a lot, and where it matters (ie: dealing with specialized servers) QUIC is already and has been in use.

detaro3• 8 years ago

A modern page can't be rendered properly a year or so down the line.

Examples?

Matthias2475• 8 years ago

The main reason it’s simple is that someone else wrote the most complex code for it: A TCP stack in the OS. Without it, it would be quite painful. With Http2 one can do the same and rely on other people’s implementations to deal with the complexity. There are in the meantime good implementations for nearly every ecosystem.

What I would E.g. agree upon is that http2 is a pain for exotic systems or E.g. microcontrollers, due to the window size and buffering requirements that the protocol imposes. But those systems are still free to stay with HTTP/1.1 for as long as they like. Nobody is going to remove support for it anytime soon.

deathanatos• 8 years ago

One can create HTTP/1 server in just a few lines of code.

One can create a non-conforming server in a few lines of code. The actual protocol has a horrendous number of corner cases and weirdness. E.g., determining a message body's size depends on whether content-length is sent, is it chunked, was the request a HEAD request, etc. There's also header folding (whereby a header can be split over multiple lines) though one has the out that the standard allows that to be optional (you can respond w/ 400). Trailers (additional headers after the body) and continuations (allows the client to request a potentially large upload, and the server can reject it prior to the client transmitting the body). Actually parsing headers beyond just a KV mapping, that is, trying to work with any of the actual data in a header is fraught with error: many of them can be specified multiple times, and can thus be in multiple occurrences of the header, or all in a single header but separated by commas, or some mix of the two. (Except cookie headers, those are special.) Some also allow a comma to appear in the value itself, meaning a parser that first splits on comma and then parses the resulting parts is broken.

These text protocols, while "simple" in the sense that a human can generally look at the on-the-wire data and parse with their eyeballs, require complex FSMs to parse correctly. (Complex, relative to an equivalent binary protocol with binary-encoded length-prefixed data or even a text protocol that didn't accommodate every random slightly different way of doing it.) Now, HTTP/2 also adds a lot of functionality above and beyond what HTTP/1 has, so that certainly eats up some of the gains in parsing simplicity (and I think it would be fair to say that the outcome is overall more complex).

I'd much rather have a binary protocol and good tooling. (And that's much more feasible with today's browser's devtools. I would not want to attempt this with the lame excuse for tooling IE 6 had back in the 90s.)

MIME's header encoding of non-ASCII characters is another abomination that I'd toss in this bucket. E.g.,

    Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
     =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

(Yes, that's a valid email Subject line.) HTTP supported this at one time, though nowadays the standard has mostly deprecated this:

   Historically, HTTP has allowed field content with text in the
   ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
   through use of [RFC2047] encoding.  In practice, most HTTP header
   field values use only a subset of the US-ASCII charset [USASCII].
   Newly defined header fields SHOULD limit their field values to
   US-ASCII octets.  A recipient SHOULD treat other octets in field
   content (obs-text) as opaque data.

sametmax2• 8 years ago

When http2 will be widely adopted by most small companies, and not just big ones, yeah, let's talk about v2.

But right now, http2 adds complexity, a lot of frameworks are not compatible with it and must be fronted by a proxy that does, and the perf benefit is not obvious at all.

xroche• 8 years ago

The perf benefits are mainly for the big companies [namely, Google, Mozilla, and few others]. Hard to see any real ones for the rest of the world.

zamadatix2• 8 years ago

The punishments for not "building/packaging/spriting" your website/app are way lower thanks to the multiplexing. Smaller shops either didn't know or didn't have the time to care about this and it added seconds to the page load in many cases. Now it's fixed (not that you shouldn't still build/package/sprite in appropriate cases) by just using HTTP/2.

drewg123• 8 years ago

The problem is that QUIC, due to using UDP and not trusting the NIC to do segmentation or crypto offload, is incredibly expensive on the server side. You're paying costs upwards of a factor of 4 as compared to TCP for quality of experience gains that are questionable when compared to TCP.

This doesn't matter for small sites, or for clients. But when you're serving 190Gb/s from a single box, paying 4x per byte really hurts.

theandrewbailey• 8 years ago

My (already minimal) blog's load time was almost halved by using HTTP2. There are real benefits for small sites/companies.

SquareWheel2• 8 years ago

Not here. I've seen significant performance improvements from HTTP/2 across dozens of small sites.

maxfurman• 8 years ago

https://en.wikipedia.org/wiki/QUIC, for those like me wondering what it is.

I think it's funny that the Q in QUIC stands for Quick. Naming things is hard.

Cyph0n• 8 years ago

That reminds of me recursive acronyms[0].

Some examples:

* GNU: GNU's Not Unix

* cURL: Curl URL Request Library

* WINE: WINE Is Not an Emulator

[0] https://en.wikipedia.org/wiki/Recursive_acronym

SEJeff2• 8 years ago

GNOME - "GNU's Not Unix" Network Object Modelling Environment!

diydsp• 8 years ago

From the old days when it ran on slow hardware: Emacs Makes A Computer Slow

tech2• 8 years ago

One of my all time favourites was Xinu (Xinu is not Unix), much more so than the doubly-weird Hurd.

simias• 8 years ago

Recursive acronyms are a staple of hacker culture by now. There's of course GNU (and many GNU projects) but also PHP, PINE and many backronyms like XBMC: https://en.wikipedia.org/wiki/Recursive_acronym

maxmcd• 8 years ago

You mean "Personal Home Page"? :)

johnhenry• 8 years ago

Not technically recursive because the "Q" does not stand for "QUIC".

trumped• 8 years ago

QUIC, Quick UDP Internet Connections

looks like they forced the Internet word in there to make it work...

detaro3• 8 years ago

Seems to me there is a difference between "we're gonna propose that naming" and "will most likely be"?

That said, it doesn't seem like a good idea to me, since it's less of a clear protocol evolution. A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics.

bpicolo• 8 years ago

To be fair, helps that this is coming from the chair of the IETF HTTP working group

arusahni2• 8 years ago

That was my thought in constructing the title for this post. Apologies if I failed to capture the appropriate level of nuance.

gsnedders• 8 years ago

A variation of the http/2 name would IMHO make more sense, e.g. http/2q or something, since it's not changing the HTTP semantics.

HTTP/2 didn't change semantics, either. We literally only have one version of HTTP semantics, and a variety of transports for it.

h1d4• 8 years ago

Please keep it with simple numbers, we don't want to go the wifi route of a/b/g/n/ac where you can't tell what is more modern which they fixed.

Matthias2475• 8 years ago

A variation of the http/2 name would IMHO make more sense

Why? The core of HTTP/2 is defining how individual HTTP streams get multiplexed across a single TCP connection. That part is not applicable to QUIC over HTTP. There HTTP streams get mapped on top of QUIC streams. Some things might be similar between HTTP/2 and HTTP/QUIC mappings, but in the end they are separate definitions. The both define how HTTP semantics are carried over a different lower layer mechanism. So HTTP/3 or HTTP/QUIC seem reasonable.

plopz• 8 years ago

Not being familiar at all with QUIC other than it has something to do with UDP. Would this have any impact on being able to send/receive UDP from the browser for games?

the_clarence5• 8 years ago

QUIC is like TCP 2.0. So it won't help games

Dylan168074• 8 years ago

It'll probably get a non-blocking option. And some games need TCP anyway.

Matthias2475• 8 years ago

Even if quic would bring along an unreliable stream option: The browsers Api still only expose http semantics via xhr and fetch. So those would need to get extended too.

ex_amazon_sde• 8 years ago

Of course it will. You can have control over retransmission.

mtgx• 8 years ago

If we're really looking to start from scratch with a modern protocol and break compatibility then HTTP v3 should be something like http://noiseprotocol.org instead.

I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too.

dagenix8• 8 years ago

I assume the QUIC protocol also comes with some "happy accidents" that allows Google to more easily collect data on us, too.

This is just conspiracy theory nonsense. If QUIC has such a flaw, it has an open spec and you are free to go find it and point it out.

teddyh4• 8 years ago

Pointing it out would change nothing; Google would implement it anyway.

baby• 8 years ago

This is exactly what we've been working on (QUIC with Noise).

As for the happy accidents, none have been spotted so far, it is an open and collaborative project so feel free to check it yourself and chime in before its finalization.

dustingetz• 8 years ago

Is QUIC what is disrupting my video calls when I type into a google doc from chrome, or any other chrome->google interaction?

vntok• 8 years ago

No.

rebelde• 8 years ago

Interesting. Google has been pushing TLS on the world, with its additional 750ms round-trip time to clients on the other side of the world, while taking advantage of their ownership of Chrome to use QUIC to deliver very fast connectivity for their users. That is a sweet competitive advantage that they have over competing services. EDIT: Am I misunderstanding this?

tialaramex4• 8 years ago

If you are False Start compatible (allow modern ECDHE, etcetera and speak HTTP/2, don't use crappy middleboxes from Cisco, Palo Alto) you get 1RTT with TLS 1.2. If you do TLS 1.3 you always get 1RTT.

You can't avoid the one round trip on first connections, you pay that in QUIC too.

xfs• 8 years ago

There's 0RTT but once the connection setup cost is amortized by preconnects and multiplexing being 0 or 1 RTT is not that important to justify its engineering ugliness.

the_clarence5• 8 years ago

Isn't QUIC mixing the tcp handshake with the tls handshake? That should make it faster

londons_explore6• 8 years ago

If you trust people like cloudflare to do CDN termination for you, that time penalty is far lower.

There is also a proposal to allow connection sharing for different domains, which would reduce the connection time to 0-rtt even if the user has never visited your site.

mychele• 8 years ago

From what I understand, this email is proposing to update the name of the RFC for HTTP over QUIC, not QUIC itself.

ArtWomb• 8 years ago

Google Cloud introduced QUIC support recently for load balancing

https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...

Adoption of cloud gaming is accelerating. And we are already starting to see custom protocols in the wild

https://blog.parsecgaming.com/a-networking-protocol-built-fo...

the_clarence5• 8 years ago

QUIC is effectively TCP 2.0. It is not a lossy protocol which is what games need.

LinuxBender2• 8 years ago

Somewhat OT, if v3 has not yet been ratified, is there a chance to get SRV record support added for http? That could indirectly tie into QUIC optimization.

teddyh4• 8 years ago

It would be wonderful, but not likely, since Google is pushing it, and they gave completely spurious reasons for not including it in HTTP/2. I see no reason for this to be any different.

wmf4• 8 years ago

You'd need Chrome to do some SRV experiments for a few years before proposing it.

chaz6• 8 years ago

There is a 19-year old bug open for SRV support in Firefox [1] and it recently got updated (marked as blocking #1435798 APIs for p2p web applications)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=14328

londons_explore6• 8 years ago

The goal would be to use a SRV record rather than an A record for http?

Whats the benefit?

wmf4• 8 years ago

Using ports other than 443.

QuadrupleA• 8 years ago

This was the first I heard of QUIC - having dealt a lot with crypto libraries, https, TLS etc. it sounds super promising. Gets rid of a lot of old-cipher cruft and TLS latency, bake security into to the transport, multiplex connections etc. Some really cool ideas there.

the_clarence5• 8 years ago

QUIC uses TLS.

lucb1e• 8 years ago

I heard of it before and later also got it in school (wouldn't recommend the study but this one subject by Paola Grosso was superb). Definitely cool stuff.

ori_b• 8 years ago

Let's see a few independent implementations before we start using it. As far as I can tell, this is also horrendously complicated, and I'm not aware of any implementations outside of Google's.

wmf4• 8 years ago

https://github.com/quicwg/base-drafts/wiki/Implementations

the_other_guy• 8 years ago

Does QUIC provide any advantage for wireless connections over TCP/TLS? Also, does QUIC use DTLS or something that's more customized?

the_clarence5• 8 years ago

It uses TLS 1.3. No need for DTLS as QUIC isan in-order protocol (eventhough it's built on top of UDP). It is supposed to be faster than tcp+tls

londons_explore6• 8 years ago

It is especially beneficial for wireless connections, since it handles packet loss better than http/2, and flow control better than many http/1.1 connections.

KaiserPro• 8 years ago

Why does it still adhere to the weird semantics of HTTP, when in reality HTTP has evolved into a file delivery protocol, with a rich inband messaging system?

Surely we have an opportunity to split HTTP into a file delivery system and a socket-like streaming system?

fulafel3• 8 years ago

Meanwhile we are still waiting for http 1.1 pipelining to be enabled in browsers.

wmf4• 8 years ago

Stop waiting; there's no reason to work on this any more. If you want pipelining that bad, use HTTP/2.

ggm• 8 years ago

Don't people read about the OSI/ISO 7 layer model any more?

The biggest deliverable (to me at least) of QUIC is the formalism of a "session" layer which is transport binding agnostic: If you move to alternate underlying IP addresses, it can recover and continue.

Sessions were big in OSI. Internet applications/protocol stack basically ignored them, for reasons of NIH, complexity, place-and-time. But, Session layer is inherently useful

UDP? Schmoo Dee Pee. What matters to me, is a session layer with cryptography.

(ok. taste-testing the underlying fragmentation barriers, which was in an earlier QUIC, that was interesting because pMTU is broken)

Identifying QUIC deliverables

Related Stories