Hi Bob, Adrian, all, Please see inline some comment on the multipath part. Cheers, Med > -----Message d'origine----- > De : Teas <teas-bounces@xxxxxxxx> De la part de Bob Briscoe via > Datatracker > Envoyé : mercredi 19 juillet 2023 15:14 > À : tsv-art@xxxxxxxx > Cc : draft-ietf-teas-rfc3272bis.all@xxxxxxxx; last-call@xxxxxxxx; > teas@xxxxxxxx > Objet : [Teas] Tsvart last call review of draft-ietf-teas- > rfc3272bis-24 > ... > > §5.1.1.4. (Layer-4) Transport-Based TE > > When the draft says no support for ATSSS splitting has yet been > developed for QUIC, it would be worth explaining why (e2e > cryptographic protection), and possibly referencing multipath QUIC > [draft-ietf-quic-multipath]. It seems rather odd to say so much > about QUIC (which ATSSS does not support) [Med] When the text was drafted (05/2021), there was no WG-adopted multipath extensions to QUIC. Since then, ATSSS supports both MPTCP and MPQUIC. TS23501 says the following: "The MPQUIC functionality enables steering, switching, and splitting of UDP traffic between the UE and UPF, in accordance with the ATSSS policy created by the network. The operation of the MPQUIC functionality is based on RFC 9298 [170] "proxying UDP in HTTP", which specifies how UDP traffic can be transferred between a client (UE) and a proxy (UPF) using the RFC 9114 [171] HTTP/3 protocol. The HTTP/3 protocol operates on top of the QUIC protocol (RFC 9000 [166], RFC 9001 [167] , RFC 9002 [168]), which supports simultaneous communication over multiple paths, as defined in draft-ietf-quic-multipath [174]." and so little about > MPTCP (which ATSSS does use). > > [Med] I suggest to shorten the QUIC prose to be consistent with the spirit of the MPTCP text + insist on the native features supported by QUIC. I would also separate the MPDCCP text as this is not part of the ATSSS yet (although this is being proposed as a candidate for ATSSS in Rel-19)+ the applicability was restricted (?) in latest version of the spec (see "Concurrent path usage" section of that spec) + applicability to UDP traffic requires an encap which is not yet specified. OLD: QUIC [RFC9000] is a UDP-based multiplexed and secure transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC is a connection-oriented protocol that creates a stateful interaction between a client and server. QUIC uses a handshake procedure that combines negotiation of cryptographic and transport parameters. This is a key differentiation from other transport protocols. With QUIC it is possible to support the ATSSS switching and steering functions. Indeed, QUIC supports a connection migration procedure that allows peers to change their transport coordinates (IP addresses, port numbers) without breaking the underlying QUIC connection. While no support for ATSSS splitting has yet been developed for QUIC, extensions to Multipath Datagram Congestion Control Protocol (MP-DCCP) [RFC4340] to provide support for splitting data traffic of UDP and plain IP flows across multiple paths on a per-packet level can be found in [I-D.ietf-tsvwg-multipath-dccp]. NEW: Multipath QUIC [I-D.ietf-quic-multipath] and Proxying UDP in HTTP [RFC9298] are used to provide the ATSSS service for UDP traffic. Note that QUIC [RFC9000] natively support the switching and steering functions. Indeed, QUIC supports a connection migration procedure that allows peers to change their transport coordinates (IP addresses, port numbers) without breaking the underlying QUIC connection. Extensions to Datagram Congestion Control Protocol (MP-DCCP) [RFC4340] to support multipath operations can be found in [I-D.ietf-tsvwg-multipath-dccp]. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
