Re: [Teas] [Last-Call] Tsvart last call review of draft-ietf-teas-rfc3272bis-24

On Thu, Jul 20, 2023 at 1:03 AM <mohamed.boucadair@orange.com> wrote:

> Hi Bob, Adrian, all,
>
> Please see inline some comment on the multipath part.
>
>

I support the changes suggested on the multipath/QUIC part. When I made my
review of  draft-ietf-teas-rfc3272bis-24

I had noticed the issue but not bothered to report it.

It should be some minor and editorial corrections.

Behcet

> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Teas <teas-bounces@ietf.org> De la part de Bob Briscoe via
> > Datatracker
> > Envoyé : mercredi 19 juillet 2023 15:14
> > À : tsv-art@ietf.org
> > Cc : draft-ietf-teas-rfc3272bis.all@ietf.org; last-call@ietf.org;
> > teas@ietf.org
> > 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>