From 8859e21ad93c3a34ae5a6f4b567d1eae44c8141b Mon Sep 17 00:00:00 2001 From: maxfranke Date: Wed, 5 Apr 2023 21:38:21 +0200 Subject: [PATCH 1/4] Changed retransmission to include MAX_DATA --- draft-jholland-quic-multicast.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-jholland-quic-multicast.md b/draft-jholland-quic-multicast.md index c2c7cdd..c2e9512 100644 --- a/draft-jholland-quic-multicast.md +++ b/draft-jholland-quic-multicast.md @@ -325,6 +325,8 @@ The same stream ID may be used in both one or more multicast channels and the un # Flow Control {#flow-control} The values used for unicast flow control cannot be used to limit the transmission rate of a multicast channel because a single client with a low MAX_STREAM_DATA or MAX_DATA value that did not acknowledge receipt could block many other receivers if the servers had to ensure that channels responded to each client's limits. +Instead of terminating a connection if its MAX_DATA gets exceeded (as described in {{Section 19.9 of RFC9000}}), a client must be able to robustly handle multicast packets that would exceed its MAX_DATA without aborting the connection, either by increasing its MAX_DATA as needed to keep up with received multicast packets or by dropping the packet and leaving the channel (resulting in unicast fallback). +If a server detects that a clients MAX_DATA is about to be exceeded, it MUST instruct the client to leave channels to prevent any further MAX_DATA violations. Instead, clients advertise resource limits via MC_LIMITS ({{client-limits-frame}}) frames and their initial values from the transport parameter ({{transport-parameter}}). The server is responsible for keeping the client within its advertised limits, by ensuring via MC_JOIN and MC_LEAVE frames that the set of channels the client is asked to be joined to will not, in aggregate, exceed the client's advertised limits. From 97fab04113aaf39673da008ca230a8226a8224a0 Mon Sep 17 00:00:00 2001 From: Louis Navarre Date: Tue, 10 Oct 2023 09:47:06 +0200 Subject: [PATCH 2/4] Integrate Multipath QUIC discussion on Multicast channel --- draft-jholland-quic-multicast.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-jholland-quic-multicast.md b/draft-jholland-quic-multicast.md index c2e9512..8a88e82 100644 --- a/draft-jholland-quic-multicast.md +++ b/draft-jholland-quic-multicast.md @@ -121,17 +121,21 @@ Incoming packets received on the network path associated with a channel use the A client with a matching joined channel always has at least one connection associated with the channel. If a client has no matching joined channel, the packet is discarded. -Each channel has an independent packet number space. To enable clients to detect lost packets, packet numbers in channels MUST be continuous. -Since the network path for a channel is unidirectional and uses a different packet number space than the unicast part of the connection, packets associated with a channel are acknowledged with MC_ACK frames {{channel-ack-frame}} instead of ACK frames. +## Channel using Multipath QUIC + +From the point of view of the client, each Multicast QUIC channel is handled as a second path from the server. A client keeps its unicast connection with the server open during all the transmission. Additionally, it negotiates a second path with the server where it will receive multicast content. All mechanisms, except those listed below, follow {{I-D.draft-ietf-quic-multipath}}. + +The first major change concerns the encryption of the multicast path. To keep the unicast path between the client and the server secure, the multicast path must use a different cryptographic context that is common between all clients. As such, each path is encrypted differently, differing from the current version of {{I-D.draft-ietf-quic-multipath}}. NB: there are discussions within the Multipath QUIC draft to integrate this feature to strengthen the security of MPQUIC. Secondly, a client MUST NOT send any data on the multicast path with the server. + +Leveraging Multipath QUIC for Multicast QUIC provides interesting properties from the client's point of view. For example, the client can seamlessly receive data from the multicast and the unicast path. This enables efficient unicast fall-back and unicast retransmissions. Leaving the multicast channel is performed by closing the multicast path with the server. + +This draft imposes the Multiple Packet Number Space version of Multipath QUIC (See {{Section 5 of I-D.draft-ietf-quic-multipath}}). Each channel possesses its own packet number space. To enable clients to detect lost packets, packet numbers in channels SHOULD be continuous. The use of any particular channel is OPTIONAL for both the server and the client. It is recommended that applications designed to leverage the multicast capabilities of this extension also provide graceful degradation for endpoints that do not or cannot make use of the multicast functionality (see {{graceful-degradation}}). The server has access to all data transmitted on any multicast channel it uses, and could optionally send this data with unicast instead. -No special handling of the data is required in a client application that has enabled multicast. -A datagram or any particular bytes from a server-initiated unidirectional stream can be delivered over the unicast connection or a multicast channel transparently to a client application consuming the stream or datagram. - Client applications should have a mechanism that disables the use of multicast on connections with enhanced privacy requirements for the privacy-related reasons covered in {{I-D.draft-krose-multicast-security}}. # Transport Parameters {#transport-parameter} From 554101dbace8fcaafd819e0e53e62ca350cc50c8 Mon Sep 17 00:00:00 2001 From: Louis Navarre <37408317+louisna@users.noreply.github.com> Date: Mon, 23 Oct 2023 10:47:58 +0200 Subject: [PATCH 3/4] Multipath: generalize the concept to several paths Co-authored-by: Max Franke <18706009+MaxF12@users.noreply.github.com> --- draft-jholland-quic-multicast.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-jholland-quic-multicast.md b/draft-jholland-quic-multicast.md index 8a88e82..1e67802 100644 --- a/draft-jholland-quic-multicast.md +++ b/draft-jholland-quic-multicast.md @@ -123,7 +123,7 @@ If a client has no matching joined channel, the packet is discarded. ## Channel using Multipath QUIC -From the point of view of the client, each Multicast QUIC channel is handled as a second path from the server. A client keeps its unicast connection with the server open during all the transmission. Additionally, it negotiates a second path with the server where it will receive multicast content. All mechanisms, except those listed below, follow {{I-D.draft-ietf-quic-multipath}}. +From the point of view of the client, each Multicast QUIC channel is handled as an additional path from the server. A client keeps its unicast connection with the server open during all the transmission. Additionally, the server can inform the client about an additional path where it will receive multicast content. All mechanisms, except those listed below, follow {{I-D.draft-ietf-quic-multipath}}. The first major change concerns the encryption of the multicast path. To keep the unicast path between the client and the server secure, the multicast path must use a different cryptographic context that is common between all clients. As such, each path is encrypted differently, differing from the current version of {{I-D.draft-ietf-quic-multipath}}. NB: there are discussions within the Multipath QUIC draft to integrate this feature to strengthen the security of MPQUIC. Secondly, a client MUST NOT send any data on the multicast path with the server. From 17c0a7d11eb7556a67b58b3f2639db9afb1f42f4 Mon Sep 17 00:00:00 2001 From: Louis Navarre Date: Mon, 23 Oct 2023 10:54:38 +0200 Subject: [PATCH 4/4] Add comment about MPQUIC path creation and loosen the crypto per path Revert deleting sentence about transparency --- draft-jholland-quic-multicast.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-jholland-quic-multicast.md b/draft-jholland-quic-multicast.md index 1e67802..ab66db6 100644 --- a/draft-jholland-quic-multicast.md +++ b/draft-jholland-quic-multicast.md @@ -124,8 +124,9 @@ If a client has no matching joined channel, the packet is discarded. ## Channel using Multipath QUIC From the point of view of the client, each Multicast QUIC channel is handled as an additional path from the server. A client keeps its unicast connection with the server open during all the transmission. Additionally, the server can inform the client about an additional path where it will receive multicast content. All mechanisms, except those listed below, follow {{I-D.draft-ietf-quic-multipath}}. +TODO: either rely the current Multipath QUIC draft (the client must create the new path itself) or extend the draft to allow the server to initiate the creation of the second path. -The first major change concerns the encryption of the multicast path. To keep the unicast path between the client and the server secure, the multicast path must use a different cryptographic context that is common between all clients. As such, each path is encrypted differently, differing from the current version of {{I-D.draft-ietf-quic-multipath}}. NB: there are discussions within the Multipath QUIC draft to integrate this feature to strengthen the security of MPQUIC. Secondly, a client MUST NOT send any data on the multicast path with the server. +The first major change concerns the encryption of the multicast path. To keep the unicast path between the client and the server secure, the multicast path MUST use a different key and MAY use a different algorithm, that is common between all clients. As such, each path is encrypted differently, differing from the current version of {{I-D.draft-ietf-quic-multipath}}. NB: there are discussions within the Multipath QUIC draft to integrate this feature to strengthen the security of MPQUIC. Secondly, a client MUST NOT send any data on the multicast path with the server. Leveraging Multipath QUIC for Multicast QUIC provides interesting properties from the client's point of view. For example, the client can seamlessly receive data from the multicast and the unicast path. This enables efficient unicast fall-back and unicast retransmissions. Leaving the multicast channel is performed by closing the multicast path with the server. @@ -136,6 +137,9 @@ It is recommended that applications designed to leverage the multicast capabilit The server has access to all data transmitted on any multicast channel it uses, and could optionally send this data with unicast instead. +No special handling of the data is required in a client application that has enabled multicast. +A datagram or any particular bytes from a server-initiated unidirectional stream can be delivered over the unicast connection or a multicast channel transparently to a client application consuming the stream or datagram. + Client applications should have a mechanism that disables the use of multicast on connections with enhanced privacy requirements for the privacy-related reasons covered in {{I-D.draft-krose-multicast-security}}. # Transport Parameters {#transport-parameter}