Re: [Last-Call] [Teas] Tsvart last call review of draft-ietf-teas-rfc3272bis-24
Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 20 July 2023 14:36 UTC
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12992C14CE51; Thu, 20 Jul 2023 07:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZwYUhwnKldh; Thu, 20 Jul 2023 07:36:54 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB38C14F75F; Thu, 20 Jul 2023 07:36:54 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3143b88faebso766081f8f.3; Thu, 20 Jul 2023 07:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689863812; x=1690468612; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BQSSNswvAQwQ3FcAfHShhn1JS++HRYG2RX6jwDUxTQo=; b=hhci6JMCvkgCPNgtFCOHC9RcKsqSkhEpcwF9UoYzhIP0NiorFySOwi0u7y0wbPiLoO QO/yOS3PsUkoMoHWeb+F2Fmt0c76AkjQZIDOk+NM0FuzVlE1UWZEq/5HP94apf8D2Y/I Mw+bSfDfVg93s2RPCBCtdRChQB4mBSJUqbGoP2K6sJMIPhKHFBg+MINSWzsPSnLHwT7f 3ex4k993+MIsHJHjZUPztbPHVWSlWaVwqbFutsu1yKVn6MouTAAQpncJ4YidpDXfh5Eu IC//Rfd/Aa2/rgTmc8INYyLqFMw4YN6XKX99wYMjN05dokNuIGwNQ+QXdOEaYuaLE5pk PYjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689863812; x=1690468612; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BQSSNswvAQwQ3FcAfHShhn1JS++HRYG2RX6jwDUxTQo=; b=Ig7hsf++zkH9nMxcAsvPYPD35C7TFex6aF0pZQODu6Hwu++y05ZKJdH4NzUe756FWF 9I+yQFnf+UxAI4xMFWh/n3Sl9qytopOs7Sw9j2QzMlh+o1GEuy1iW+4VVKJOu2S8wHB/ tPBrH/J4z8VOgILFEgAYsS9flTqM5A52MQSAB16q02rKAqvYtuPm7zX7HTZMA41uve8o 5RUxrt1m9iAQdO4cpircv2kqL+tgy1SJlz1mHJhOfaStRiCuvp14xVfP2PkjBXiZclWq 0H93xOoMRjXvSuWm33/nAFk/3srirBSiBsx6ZIXQEcaca+IVXNTkMhyEpRiWD0Oc/8pf zdiA==
X-Gm-Message-State: ABy/qLZ+hqD8uTDj9qmyDGoV6TrS8rcwAxPygwR+LKvOalLy2htjUBLI KWY3rcIbSkn9dNme3Ic6JcZzNs/EyBpjCK1fdohSkw70nwNnjw==
X-Google-Smtp-Source: APBJJlEuGDCAOvCipjlfPR5fhUI9CGqiTv21+o25nN5V9ib1oSHcMm/37Lt9hVgMwO0q67K5oFxpywcwJbna5WkcOQY=
X-Received: by 2002:adf:cd90:0:b0:314:c2a:31c5 with SMTP id q16-20020adfcd90000000b003140c2a31c5mr2562995wrj.19.1689863812134; Thu, 20 Jul 2023 07:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <168977241026.20221.9353844256722402673@ietfa.amsl.com> <DU2PR02MB1016030A456840AE7D1C4B226883EA@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB1016030A456840AE7D1C4B226883EA@DU2PR02MB10160.eurprd02.prod.outlook.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Thu, 20 Jul 2023 09:36:40 -0500
Message-ID: <CAC8QAceXuwOHNO_eJ9Kb6VDynYiuK2ZK5ve9J_dow54kRzOdLw@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-teas-rfc3272bis.all@ietf.org" <draft-ietf-teas-rfc3272bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003dba3d0600ec14b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/C7GWI3DccgAUVPp2ttWrz3v7ZTY>
Subject: Re: [Last-Call] [Teas] Tsvart last call review of draft-ietf-teas-rfc3272bis-24
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2023 14:36:58 -0000
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 >
- [Last-Call] Tsvart last call review of draft-ietf… Bob Briscoe via Datatracker
- Re: [Last-Call] Tsvart last call review of draft-… Adrian Farrel
- Re: [Last-Call] Tsvart last call review of draft-… Bob Briscoe
- Re: [Last-Call] [Teas] Tsvart last call review of… mohamed.boucadair
- Re: [Last-Call] [Tsv-art] [Teas] Tsvart last call… Bob Briscoe
- Re: [Last-Call] [Teas] Tsvart last call review of… Behcet Sarikaya
- Re: [Last-Call] Tsvart last call review of draft-… Adrian Farrel
- Re: [Last-Call] [Tsv-art] Tsvart last call review… Bob Briscoe
- Re: [Last-Call] [Tsv-art] Tsvart last call review… Adrian Farrel