Talk:QUIC

UDP is not a Transport Layer Protocol

The article starts by stating that QUIC is a "transport layer network protocol". However that statement is wrong. QUIC is not listed on IANA Assigned Internet Protocol Numbers list. See: . Actually QUIC works on top of UDP which is a transport layer network protocol. I believe the sentence should be fixed. - Silverbach (talk) 18:14, 21 March 2021 (UTC)

References

@Silverbach: Both QUIC and UDP are transport layer protocols. This may seem contradictory from a strict OSI layering perspective, but that's the way each protocol functions. QUIC utilizes UDP as datagram service instead of utilizing IP directly as an internet protocol because the ubiquity of NAT precludes the introduction of new IP protocols in widespread use. A transport layer protocol doesn't need to be listed by IANA to exist. --Zac67 (talk) 07:42, 24 September 2021 (UTC)

Agree with Silverbach (talk · contribs). QUIC is not a transport-layer protocol in the strict sense. It is a new application-layer protocol (included in HTTP/3) that requires implementation in application-space for both server and client; but does not require changes in operating system kernel (uses UDP transport layer). See illustration Protocol Stack of HTTP/3 compared to HTTP/1.1 and HTTP/2. – Aaditya_7 07:55, 1 April 2023 (UTC)

QUIC is general-purpose, as in, it is an application-layer protocol framework for providing connection-oriented/stream semantics, and network path migration over UDP. It is described in RFC 8999, RFC 9000, RFC 9001, and RFC 9002. HTTP generally uses TCP/IP; HTTP/3 (RFC 9114) is a concrete application-layer protocol that builds on QUIC. QUIC and UDP are not the same thing. Note that the RFC for HTTP/3 is also called draft-ietf-quic-http. In my opinion, the ability of the web-user to choose to use HTTP over TCP/IP has to be provided (and retained in the web-servers and web-browsers of the future) in a similar way to that of the ability of the web-user to choose to use HTTP without TLS encryption. – Aaditya_7 09:59, 1 April 2023 (UTC)

@Aaditya 7: Have you read those RFCs you mention? Each one of them puts QUIC in the transport layer. --Zac67 (talk) 12:18, 1 April 2023 (UTC)

UDP is connectionless

This sentence: "it does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP)." is wrong. UDP is connectionless and it doesn't make sense to have multiplexed connections. I believe it means that it uses multiple UDP data streams in parallel. — Preceding unsigned comment added by Ingframin (talk • contribs) 22:27, 2019 January 24 (UTC)

You are correct, this sentence does not really make sense. The whole sentence is odd. Statement that QUIC "is designed to obsolete TCP at the transport layer for many applications" is incorrect because QUICK is not a drop-in replacement, it might be used instead of TCP but does not obsolete it. The bit about "earning the protocol the occasional nickname "TCP/2" is just a weasel word. The whole sentence is supported only by self-published source on GitHub. I'll try to find better comparison with TCP; failing that, I'll just remove this sentence entirely. 77.120.159.74 (talk) 08:51, 1 February 2022 (UTC)

Multiplexing is done by the application protocol on top, ie. HTTP/2, within a single connection. Using multiple connections isn't multiplexing but parallelism. UDP is connectionless but QUIC is another transport-layer protocol (on top of UDP) that is connection-oriented. This works pretty much the same as if it would run directly on top of IP. The intermediate UDP is merely used as a vehicle to cope with the ubiquity of NAT that renders introducing new L4 protocols impossible. --Zac67 (talk) 09:49, 1 February 2022 (UTC)

POV-Check

This reads like a marketing page for Google; "As improving TCP is a long-term goal for Google, QUIC aims to be ..." — Preceding unsigned comment added by 2.29.7.103 (talk) 14:21, 11 April 2016 (UTC)

@2.29.7.103 I agree, it even still has this tone here in anno domini 2022 Pariah24 (talk) 12:15, 15 June 2022 (UTC)

FEC

Reading through forward error correction and what Google describes of what they did, there is no error correction right now. All they have is forward error detection. — Preceding unsigned comment added by Dschonbe (talk • contribs) 22:04, 30 June 2016 (UTC)

I don't understand the use of FEC over UDP. The UDP protocol contains a checksum that validates the entire packet, if errors are detected then the packet is discarded by routers or the network stack prior to the datagram beign delivered to the user space application. If FEC was a design goal then UDPLite (rfc3828) would need to be used. However this is not widely supported by routers or network stacks. K45671 (talk) 15:45, 11 August 2022 (UTC)

Untitled

This text is, it seems, very inaccurate.

It does not "aim to update UDP", saying it focuses on "data streams" is pretty nonsensical when talking about protocols, and its main use is not "to run a TCP like flow and congestion control mechanism over UDP" (which would not be useful in itself). — Preceding unsigned comment added by 130.231.12.75 (talk) 11:44, 2013 February 28 (UTC)

"data streams" are not "nonsensical", is common nomenclature for continuous sensor data and control signal streams that are typically fixed bandwidth continuous streams. Like RTP or other things used in Live Streaming video where delay is unacceptable. Or in the case of robotic control systems where again, it's about pushing the most current information for control systems to operate. - John Sokol — Preceding unsigned comment added by John.sokol (talk • contribs) 02:38, 2013 June 4 (UTC)

How can I add a disambiguation from QUIC the scientific software: http://www.cs.utexas.edu/~sustik/QUIC/ ? Sustik (talk) —Preceding undated comment added 05:36, 9 November 2013 (UTC)

Source Code section should be fixed or deleted

The Source Code section does not give any URL's to QUIC-specific source code. Instead it tells what license the code was released under, links to the generic BSD license, and what source code control systems (SCCS) were used to store the source code with URL's pointing to the wikipedia descriptions of the SCCS's. It tells you nothing specific about the QUIC source code, which is what someone would expect to find in a "Soure Code" section for the QUIC protocol, with special interest in a link to the latest source code for a reference or sample implementation (assuming one exists). If it doesn't exist, the section should be removed, as it provides nothing one would expect to find in a 'Source Code' section for a software project. -Astara Athenea (talk) 19:15, 25 October 2017 (UTC)

Good point. I took a shot at it. Dmitri tikhonov (talk) 21:06, 25 October 2017 (UTC)

QUIC acronym?

The article says that QUIC is not have an acronym. Doesn't QUIC stand for Quick UDP Internet Connections? in vivo veritas 00:36, 19 March 2019 (UTC)

@in vivo veritas I don't think the acronym was adopted into the official standard as is now mentioned in the article Pariah24 (talk) 12:32, 15 June 2022 (UTC)

References

"Quite" different

"The protocol that was created by Google and taken to the IETF under the name QUIC ... is quite different from the QUIC that has continued to evolve ..."

The British or the US quite? Must use another word, it's confusing. — Preceding unsigned comment added by 76.94.193.155 (talk) 22:04, 15 May 2020 (UTC)

Is there really much of a difference? Nog642 (talk) 11:09, 23 November 2020 (UTC)

Mary deusdedith Use Mary deus (talk) 20:19, 12 July 2019 (UTC)

gQUIC section is confusing

One of the sentences reads "The original Google QUIC was designed to be a general purpose protocol, though it was initially deployed as a protocol to support HTTP(S) in Chromium, while the current evolution of the IETF protocol QUIC is the general purpose transport protocol." (bold emphasis mine).

It basically says both the original Google QUIC and the current IETF QUIC are "general purpose". This is confusing to me.

In fact the entire "Google QUIC (gQUIC)" section of this article seems unnecessary. It doesn't say much besides that Google created QUIC then submitted it to the IETF, which is already in the lead section. It doesn't even mention the acronym gQUIC from the title once.

I think the section should just be deleted. Nog642 (talk) 11:14, 23 November 2020 (UTC)

Criticism getting reverted

I've seen a good edit adding criticism (with proper citations) to the protocol getting reverted. Why? For as much as Google wants to describe QUIC as a silver bullet, most of the problems that arise from using UDP where TCP should be used are unresolved, and the article should reflect this, especially if there are other protocols based on TCP that are aimed specifically at doing what QUIC should do, but more securely. Amideee (talk) 10:48, 29 October 2021 (UTC)

I'm the one who reverted those edits – the sources were somewhat better than from the first attempt but still don't support the bold claims.

• The marketing message that QUIC as a replacement of TCP is misleading because QUIC is fundamentally based on UDP is WP:OR entirely.
• QUIC inherits some of the UDP architectural vulnerabilities, for example, susceptibility to flood attacks. isn't supported by the quoted source as that explicitly states a QUIC flood is not necessarily the same as a UDP flood. This might be useful but requires elaboration.
• Academic study shows "QUIC’s performance is inherently tied to implementation design choices", "largely determined by the server’s choice of congestion-control algorithm and the robustness of its congestion-control implementation" is supported by source but it's essentially a platitude. That's not different from TCP or any other such protocol.
• There exist TCP-based implementations capable of soft real-time voice and video traffic such as HTTP Live Streaming (HLS) with its derivatives, and XRTC – HLS is based on HTTP which uses TCP which, of course, is an "alternative to QUIC", another platitude. XRTC targets replacing TCP, not QUIC, and is really exotic, so it's out of place here. Sadly, development of new IP protocols has all but stopped due to the ubiquity of network address translation which is why QUIC uses UDP instead of riding on top of IP directly. Blunt bashing against QUIC doesn't help here.

I'd really like to see some well-sourced, critical text but there isn't really anything to go with here, sorry. --Zac67 (talk) 15:04, 29 October 2021 (UTC)

Balance in lede

I restructured and lengthened the lede for balance.

With the complete lack of any adverse consideration in the lede, the protocol should probably have been named BLIS instead.

My framing of small gripes at the bottom is second rate, but at least the possibility of less-than-universal fawning is actually mentioned now.

I'm a one-and-done kind of guy. Revise or revert at will. — MaxEnt 02:24, 13 December 2021 (UTC)

This article badly lacks a neutral/all–encompassing POV

It has clearly lacked it for years, though it's not as bad as it once was (I shall not link the relevant WP:MOS topics, as people are perfectly capable of perusing the MOS themselves and I find that behavior asinine).

It still has a blatantly editorial and unencyclopaedic tone. One only need read for seconds to realize that criticism has no fighting chance in this framework. A significant redesign of the article (requiring the efforts of several people) is necessary. I will try to contribute when I have time.

Sources discussing QUIC's very common use cases for ads, tracking, fingerprinting, data–wasting background connections in the case of mobile, et cetera can likely be found on EFF or similar privacy-focused outlets to achieve better balance.

QUIC connections are often totally optional, so the idea or insinuation that it is some sort of next-generation drop-in replacement for TCP or other established HTTP protocols is pretty silly.

The privacy and security implications of this protocol, owing much to the manner in which companies like Meta are choosing to use it, are disconcerting to say the least. A reader would not glean a single iota of these concerns from this article. Pariah24 (talk) 13:12, 15 June 2022 (UTC)

Addition to "Adoption" topic

I'm not well versed in editing Wikipedia so I wasn't sure if this was a worthwhile edit or not, but Apple's iCloud Private Relay service now uses QUIC. I felt that since it's a widespread service that Apple is rolling out, mentioning it in the "Adoption" topic might be worthwhile.

Sources: https://support.apple.com/en-us/102602, https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay 128.252.89.29 (talk) 19:39, 8 January 2024 (UTC)

QUIC & It's Advantages

QUIC (Quick UDP Internet Connections) and why it is considered an improvement over traditional TCP-based protocols. QUIC is a modern transport protocol developed by Google that aims to enhance web performance and security. Here are some key points that could be included:

QUIC Overview:

QUIC is designed to address the limitations and performance bottlenecks of TCP (Transmission Control Protocol) by combining features of both transport and security layers into a single protocol. It operates over UDP (User Datagram Protocol) to provide a more efficient and secure way of transmitting data over the internet.

Advantages of QUIC:

• Improved Performance:

QUIC reduces latency and connection establishment times compared to TCP. It achieves this by combining multiple functions, such as encryption and error correction, into a single round trip, reducing the number of handshakes required to establish a connection. (Source: [https://cloud.google.com/blog/products/networking/new-tcp-bbr-comes-to-gcp-your-internet-just-got-faster Google Cloud Blog])

* Multiplexing:

QUIC supports multiplexing multiple streams of data over a single connection, allowing for more efficient use of network resources and faster loading of web pages. (Source: [https://www.chromium.org/quic+Chromium+Project])

* Connection Migration: QUIC allows connections to seamlessly switch between IP addresses or networks (e.g., from Wi-Fi to mobile data) without interrupting the user experience, improving connection reliability. (Source: [https://datatracker.ietf.org/doc/html/rfc9000+IETF+RFC+9000])

* Improved Security:

QUIC encrypts data by default, providing confidentiality and integrity of transmitted data. It also incorporates mechanisms to mitigate common network attacks, such as connection amplification attacks. (Source: [https://tools.ietf.org/html/rfc9000 IETF RFC 9000])

* Adaptive Congestion Control: QUIC includes built-in mechanisms for congestion control, adapting to network conditions more efficiently than TCP, resulting in better performance over lossy or congested networks. (Source: [https://cloud.google.com/blog/products/gcp/new-quic-protocol-google-cloud-beyond-tcp Google Cloud Blog])

I believe adding a section on QUIC would enhance the article's coverage of modern internet protocols and provide readers with valuable information on emerging technologies. Please feel free to incorporate this feedback into the article for the benefit of Wikipedia users.

Thank you!

Fraaz Alee Fraaz Alee (talk) 10:45, 2 May 2024 (UTC)

The entire QUIC article is about QUIC. Why would it have to have a section about QUIC added to it, given that all of its sections are about QUIC already? Guy Harris (talk) 01:16, 27 May 2024 (UTC)

This may be a stupid question

Some IT communications protocols enable binary files (eg database files, images) to be transmitted, while others only allow text files (because some binary numbers would conflict with control characters), in which case images have to be converted into text file format (eg converting the file to Base64). Which types of files can QUIC transmit (or am I at the wrong level)? Perhaps the article could make this clearer? FreeFlow99 (talk) 13:38, 3 August 2024 (UTC)

It's not a text-based protocol, so it allows binary data to be transported without requiring a binary-to-text transformation. See, for example, https://datatracker.ietf.org/doc/html/rfc9000#frame-stream - the data in a stream packet is just a lump of binary text. Guy Harris (talk) 05:33, 5 August 2024 (UTC)