Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

21–30 of 246 posts

Re: QUIC is now RFC 9000

#21

Post by ekidd »

hydrox24 wrote: post #10

Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs? The QUIC Wikipedia page[0] makes it sound like a substantial amount of traffic, due largely to Facebook, Google, and the Google Chrome browser, uses QUIC already. Facebook claims 75% of their traffic (for the app?) is via QUIC[1] [0]: https://en.wikipedia.org/wiki/QUIC [1]: https://engineering.fb.com/2020/10/21/networking-tra…

> Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs?

As other people have noted, yes.

One of the interesting facts about the IETF is that they actually require two existing implementations in order to advance from an RFC to an official "Internet Standard":

The IETF Standards Process (RFC 2026, updated by RFC 6410) requires at least two independent and inter-operable implementations for advancing a protocol specification to Internet Standard.

I suspect that this requirement for two independent implementations that can actually talk to each other is one reason the IETF has a relatively solid track record.

Re: QUIC is now RFC 9000

#22

Post by ivan4th »

sigjuice wrote: post #12
ivan4th wrote: post #11

Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)

Both ends need to grok MPTCP. Which services and devices meet the requirement?

I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance.

[1] https://www.openmptcprouter.com/

Re: QUIC is now RFC 9000

#23

Post by ivan4th »

rektide wrote: post #19
ivan4th wrote: post #11

Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)

It will never ever be included. That's not how protocols & specs work. They are modular and build off of one another. The linked article includes some examples: RFC9001 is "Using TLS to secure QUIC", RFC9002 is "QUIC Loss Detection and Congestion Control." These are expected capabilities of most users, but they are still defined out of the core spec. Similarly, there is steady progress on a multipath extension to QUI…

Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready for production use yet, if I understand correctly.

[1] https://www.openmptcprouter.com/

Re: QUIC is now RFC 9000

#25

Post by wyattpeak »

corndoge wrote: post #2

Off topic, but doesn't GDPR stipulate[0] that cookie consent dialogs cannot have non-essential options that are by default opted in? This page seems to have those. > The use of pre-ticked opt-in boxes is invalid underthe GDPR. Silence orinactivity on the part of the data subject, as well as merely proceeding with a service cannot beregarded as an active indication of choice. [0] https://edpb.europa.eu/sites/default/f…

Huh, I didn't know that, I'd wondered why so many sites defaulted them all to unchecked.

Fastly's one seems a pretty dark-patterned in general, throwing up a primary-styled "allow all" button (and simultaneously pushing the switches out of view) if you disable one of the options.

Re: QUIC is now RFC 9000

#26

Post by wahern »

ivan4th wrote: post #22
sigjuice wrote: post #12

Earlier quoted context omitted.

Both ends need to grok MPTCP. Which services and devices meet the requirement?

I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance. [1] https://www.openmptcprouter.com/

Wouldn't QUIC work all the same with that setup, considering that you're not using MPTCP end-to-end? Or do you have a SOCKS or HTTP proxy on the other side of the aggregated links?

Also, why do you need MPTCP for this? Aren't there simpler methods for this kind of setup, like LACP? Or is OpenMPTCProuter, like OpenVPN, one of those things that everybody uses because everybody else does, with more informal documentation and help?

I haven't done this myself but it looks like OpenBSD would support LACP out-of-the-box w/ the aggr(4) or trunk(4) devices. See https://man.openbsd.org/aggr.4, https://man.openbsd.org/trunk.4, and https://undeadly.org/cgi?action=article;sid=20190710071440. I presume standard Linux distros have similar support.

EDIT: To be clear, AFAIU you'd also need to combine the LACP pseudo-devices w/ something like tpmr(4) and etherip(4) to actually bridge the peers. See https://www.undeadly.org/cgi?action=article;sid=201908022358... which describes tpmr(4) as providing a simpler complement for use in LACP-over-IP setups, where the normal bridge(4) device would require too much additional configuration. Again, I presume Linux has analogs.

Re: QUIC is now RFC 9000

#27

Post by 1vuio0pswjnm7 »

Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully (using openssl-1.1k) but I got illegal instruction core dumped when executing cli.

https://github.com/h2o/quicly

There are a few Rust alternatives for QUIC. Anyone tried them and have comments.

https://github.com/cloudflare/quiche

https://github.com/quinn-rs/quinn

https://github.com/mozilla/neqo

Re: QUIC is now RFC 9000

#28

Post by tweenagedream »

ivan4th wrote: post #23
rektide wrote: post #19

Earlier quoted context omitted.

It will never ever be included. That's not how protocols & specs work. They are modular and build off of one another. The linked article includes some examples: RFC9001 is "Using TLS to secure QUIC", RFC9002 is "QUIC Loss Detection and Congestion Control." These are expected capabilities of most users, but they are still defined out of the core spec. Similarly, there is steady progress on a multipath extension to QUI…

Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready…

Seems like there are quite a few options that show up pretty quickly when searching for multipath udp e.g: https://github.com/angt/glorytun

Would that work for you?

Re: QUIC is now RFC 9000

#30

Post by CobrastanJorji »

infogulch wrote: post #4

Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.

Sure, and that's one good meme. But we also get to make some HAL 9000 jokes about Google now, and that's even better (though ironic, given that it was intended to be IBM jokes).
Post reply on HN