From 69e3e08402fc65ec467b4ab801076b641479e4b1 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 7 Dec 2022 04:56:33 -0500 Subject: [PATCH 1/6] add content for quic muxer --- content/concepts/multiplex/quic.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/content/concepts/multiplex/quic.md b/content/concepts/multiplex/quic.md index 8ff96c73..8a6a06af 100644 --- a/content/concepts/multiplex/quic.md +++ b/content/concepts/multiplex/quic.md @@ -4,12 +4,19 @@ description: QUIC is a transport protocol that contains a native stream multiple weight: 181 --- -QUIC is a [transport](../../transport/overview) protocol that contains a "native" stream multiplexer. -libp2p will automatically use the native multiplexer for streams using a QUIC transport. View the -[QUIC section](../../transports/quic/) to learn about QUIC. - -{{< alert icon="💡" context="note">}} -This section is incomplete, and many of the articles are stubs. To help fill in -the gaps, please see the issues linked in each article to add your input and -help us prioritize the outstanding work. -{{< /alert >}} +## QUIC native multiplexing + +QUIC is a [transport](../../transport/overview) protocol that contains a "native" +stream multiplexer. libp2p will automatically use the native multiplexer for streams +using a QUIC transport. View the [QUIC document](../../transports/quic/) to learn +about QUIC. + +QUIC interleaves frames from multiple streams into one or more QUIC packets at the +transport layer. A single QUIC packet can include multiple frames from one or more +streams. Transport-layer multiplexing removes the HOL (head-of-line) blocking issue +in HTTP/2 as QUIC identifies each byte stream with a stream ID, unlike with TCP. + +Because QUIC runs on UDP, which uses out-of-order delivery, each byte stream is transported +independently (through the most optimal route available.) However, QUIC still ensures the +in-order delivery of packets within the same byte stream. Using the stream ID, QUIC can +identify a lost packet, and unaffected byte streams can continue to transmit data. From 783b91675574c03a79820e27c97e520eb43976ef Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Mon, 12 Dec 2022 16:56:54 -0500 Subject: [PATCH 2/6] Apply suggestions from code review Co-authored-by: Marten Seemann --- content/concepts/multiplex/quic.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/content/concepts/multiplex/quic.md b/content/concepts/multiplex/quic.md index 8a6a06af..64f0d213 100644 --- a/content/concepts/multiplex/quic.md +++ b/content/concepts/multiplex/quic.md @@ -13,10 +13,7 @@ about QUIC. QUIC interleaves frames from multiple streams into one or more QUIC packets at the transport layer. A single QUIC packet can include multiple frames from one or more -streams. Transport-layer multiplexing removes the HOL (head-of-line) blocking issue -in HTTP/2 as QUIC identifies each byte stream with a stream ID, unlike with TCP. +streams. This solves the problem of HOL (head-of-line) blocking: If a packet contain stream +data for one stream is lost, this only blocks progress on this one stream. All other streams +can still make progress. -Because QUIC runs on UDP, which uses out-of-order delivery, each byte stream is transported -independently (through the most optimal route available.) However, QUIC still ensures the -in-order delivery of packets within the same byte stream. Using the stream ID, QUIC can -identify a lost packet, and unaffected byte streams can continue to transmit data. From bc4e17c26d3c7785c59dff786165d327017a4895 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Mon, 12 Dec 2022 17:01:31 -0500 Subject: [PATCH 3/6] move quic muxer content to quic transport doc --- content/concepts/multiplex/quic.md | 19 ------------------- content/concepts/transports/quic.md | 13 +++++++++++++ 2 files changed, 13 insertions(+), 19 deletions(-) delete mode 100644 content/concepts/multiplex/quic.md diff --git a/content/concepts/multiplex/quic.md b/content/concepts/multiplex/quic.md deleted file mode 100644 index 64f0d213..00000000 --- a/content/concepts/multiplex/quic.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "QUIC" -description: QUIC is a transport protocol that contains a native stream multiplexer. -weight: 181 ---- - -## QUIC native multiplexing - -QUIC is a [transport](../../transport/overview) protocol that contains a "native" -stream multiplexer. libp2p will automatically use the native multiplexer for streams -using a QUIC transport. View the [QUIC document](../../transports/quic/) to learn -about QUIC. - -QUIC interleaves frames from multiple streams into one or more QUIC packets at the -transport layer. A single QUIC packet can include multiple frames from one or more -streams. This solves the problem of HOL (head-of-line) blocking: If a packet contain stream -data for one stream is lost, this only blocks progress on this one stream. All other streams -can still make progress. - diff --git a/content/concepts/transports/quic.md b/content/concepts/transports/quic.md index cf651cc4..5d1ee568 100644 --- a/content/concepts/transports/quic.md +++ b/content/concepts/transports/quic.md @@ -82,6 +82,19 @@ In addition, a client can make use of QUIC's 0 RTT feature for subsequent connec when it has already communicated with a certain server. The client can then send (encrypted) application data even before the QUIC handshake has finished. +### QUIC native multiplexing + +QUIC is a [transport](../../transport/overview) protocol that contains a "native" +stream multiplexer. libp2p will automatically use the native multiplexer for streams +using a QUIC transport. View the [QUIC document](../../transports/quic/) to learn +about QUIC. + +QUIC interleaves frames from multiple streams into one or more QUIC packets at the +transport layer. A single QUIC packet can include multiple frames from one or more +streams. This solves the problem of HOL (head-of-line) blocking: If a packet contain +stream data for one stream is lost, this only blocks progress on this one stream. All +other streams can still make progress. + ## QUIC in libp2p libp2p only supports bidirectional streams and uses TLS 1.3 by default. From 9bdb9d6f0b1ec44978757455e271278d7d57835d Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Mon, 12 Dec 2022 17:04:16 -0500 Subject: [PATCH 4/6] edits now that in transport doc --- content/concepts/transports/quic.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/content/concepts/transports/quic.md b/content/concepts/transports/quic.md index 5d1ee568..26ac23bb 100644 --- a/content/concepts/transports/quic.md +++ b/content/concepts/transports/quic.md @@ -84,11 +84,6 @@ when it has already communicated with a certain server. The client can then send ### QUIC native multiplexing -QUIC is a [transport](../../transport/overview) protocol that contains a "native" -stream multiplexer. libp2p will automatically use the native multiplexer for streams -using a QUIC transport. View the [QUIC document](../../transports/quic/) to learn -about QUIC. - QUIC interleaves frames from multiple streams into one or more QUIC packets at the transport layer. A single QUIC packet can include multiple frames from one or more streams. This solves the problem of HOL (head-of-line) blocking: If a packet contain From cbf9454fd509a6f73636ae70536d61f943dbc1f1 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 11 Jan 2023 20:23:42 -0500 Subject: [PATCH 5/6] Apply suggestions from code review Co-authored-by: Marten Seemann --- content/concepts/transports/quic.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/concepts/transports/quic.md b/content/concepts/transports/quic.md index 26ac23bb..713c44f5 100644 --- a/content/concepts/transports/quic.md +++ b/content/concepts/transports/quic.md @@ -84,9 +84,8 @@ when it has already communicated with a certain server. The client can then send ### QUIC native multiplexing -QUIC interleaves frames from multiple streams into one or more QUIC packets at the -transport layer. A single QUIC packet can include multiple frames from one or more -streams. This solves the problem of HOL (head-of-line) blocking: If a packet contain +A single QUIC packet can include multiple frames from one or more +streams. Since QUIC packets can be decrypted even when they're received out of order, this solves the problem of HOL (head-of-line) blocking: If a packet that contains stream data for one stream is lost, this only blocks progress on this one stream. All other streams can still make progress. From d37b3467338b429cc8905268f4a662421ab3cac7 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Tue, 24 Jan 2023 07:12:50 -0500 Subject: [PATCH 6/6] Apply suggestions from code review Co-authored-by: Marten Seemann --- content/concepts/transports/quic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/transports/quic.md b/content/concepts/transports/quic.md index 713c44f5..b4e95258 100644 --- a/content/concepts/transports/quic.md +++ b/content/concepts/transports/quic.md @@ -84,8 +84,8 @@ when it has already communicated with a certain server. The client can then send ### QUIC native multiplexing -A single QUIC packet can include multiple frames from one or more -streams. Since QUIC packets can be decrypted even when they're received out of order, this solves the problem of HOL (head-of-line) blocking: If a packet that contains +A single QUIC packet can carry frames containing stream data from one or more +streams. Since QUIC packets can be decrypted even when they're received out of order, this solves the problem of [HoL blocking](/#key-challenges-with-tcp) that multiplexers applied on top of a TCP connection suffer from: If a packet that contains stream data for one stream is lost, this only blocks progress on this one stream. All other streams can still make progress.