RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 03 December 2020 10:01 UTC
Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08C03A0E0D; Thu, 3 Dec 2020 02:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI1foT-yIJxv; Thu, 3 Dec 2020 02:01:24 -0800 (PST)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E673A0E09; Thu, 3 Dec 2020 02:01:23 -0800 (PST)
Received: by mail-yb1-xb2d.google.com with SMTP id o71so1519629ybc.2; Thu, 03 Dec 2020 02:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=N0wdmNRS/0XsBqJ7smWSv7Ywbkz1wnJPNmt/VExnwA4=; b=HGurw5qb8VH5j4EyetXAlMDSaD0TieHhCzR1AdXQvR4U3sK1Kodttqt5b4GL10iBkY V/bh51uLHZY4pSPzO9SEzTVPBZqIIWinl3eECdkSUK/sMjdZTBtW2Buje83K+UKrxDvD ipu7hxf2Ohbh7tSl1b5l3RQQCTVKgo2XYXlBR2hoz1jtzhbaDawxgNvY7VcK606YlfE1 kTNk9jpusZrApRbxcGiuBktY+UXcv9Bb9TQ1hFOHIizD4DjdwqbyR2JVLJRV+kkAW3c7 Neok4+WBFQz2o9wsey7CGrF9tWGsQjNcK1BndzLmW+c/MCpBUW/X5jJFM9fWVr0j1Gwh eKyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=N0wdmNRS/0XsBqJ7smWSv7Ywbkz1wnJPNmt/VExnwA4=; b=pR89HKBTpwW4/QFcWSY2tnfT16CxRFxwQDYpg8lQP4EzbvzTikU3c/cZVVvdER6F1l agp4RCrRPkP7RXdeuK9Uha55pSKxC/5tc7q9emRU9uysYgmuiqXqOrqMqBU4F+kzqXY6 a9Dws0hJEiHS4tzofpC41zFotaaU2zflFA+mMgohOBi5Twn7LpE85PxVafDlhAXjA7xX 494BksknyOGNk0hlT2ru6judV/d0l9F6uWqgeLyWAW6Wj18Da+3wwvZ/fLYqjc0eO2Zg y1jdBxey2M5JIIu81xUSwY/310XLyRjoHnObYKFsAaQVolSf2aPxOtIy4dRevyT1igLe XpWQ==
X-Gm-Message-State: AOAM532VbymLnQGqdSatmsEXdJQbNl0THZsWE+i1r2PGtqn9BrUnanwh pGv7KUCGsY0kak2ogTor6xD/xGWxa8zD0bohb10=
X-Google-Smtp-Source: ABdhPJylld1qiMmO7pWszOTlCw9Drdj/EpxZ3/dDgD4V4ypqD5zlxfNUti7DSOxLKU1tZxd4z/9xrelkv4/c95qVqGo=
X-Received: by 2002:a25:d713:: with SMTP id o19mr3563091ybg.378.1606989683020; Thu, 03 Dec 2020 02:01:23 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 3 Dec 2020 02:01:22 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <LEJPR01MB0635AA0C1EF193B23922FFDFFAF20@LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE>
References: <160675082221.16479.6130039061469494989@ietfa.amsl.com> <CAOYVs2ogM86kasog5T7-XG3Nx3kZGx6Vi1id=O=0yK6WK3LHOg@mail.gmail.com> <7047_1606815783_5FC61027_7047_384_1_6B7134B31289DC4FAF731D844122B36E3A64B1F1@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <CANatvzwjyfrzoX6vA4S81hABQXcpYCJ7DWEDYBnNnRLFGWMgXg@mail.gmail.com> <LEJPR01MB0635396C6C147F869AFDCD14FAF40@LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE> <1927_1606850062_5FC6960E_1927_422_1_6B7134B31289DC4FAF731D844122B36E3A64C3E8@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <CACpbDceeYDNV7mDcj1x4w21UE3nJggoxp0vNTd8M-yn3ShhYDg@mail.gmail.com> <BYAPR02MB5176090F48871DD8E9FB9904F7F20@BYAPR02MB5176.namprd02.prod.outlook.com> <LEJPR01MB0635AA0C1EF193B23922FFDFFAF20@LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE>
MIME-Version: 1.0
Date: Thu, 03 Dec 2020 02:01:22 -0800
Message-ID: <CAN1APddJzP=GHHE11Jfabgw57sxTtQyTjzJBhCLiG9b787Oeug@mail.gmail.com>
Subject: RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
To: jri.ietf@gmail.com, wzia@qti.qualcomm.com, markus.amend@telekom.de, lionel.morand@orange.com
Cc: quic@ietf.org, martenseemann@gmail.com, lucaspardue.24.7@gmail.com, 3gppliaison@etsi.org, salki@motorola.com, lars@eggert.org, gonzalo.camarillo@ericsson.com, chair@ietf.org, kazuhooku@gmail.com, martin.h.duke@gmail.com, statements@ietf.org, magnus.westerlund@ericsson.com
Content-Type: multipart/alternative; boundary="00000000000036d85305b58c71ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3QG1vQQj3oVzsJZ8VgGiy2yo9P0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 10:01:27 -0000
Are the special ordering concerns beyond single streams? I don’t think it is useful to reorder datagram frames and streams are by definition ordered within a stream and not across streams in QUIC v1 and I don’t see any multipath design that would change that. If datagram frames were to be ordered, you would loose the ASAP property you want from those frames, and if cross stream ordering is applied, you introduce HoL. Kind Regards, Mikkel Fahnøe Jørgensen On 3 December 2020 at 10.33.17, markus.amend@telekom.de ( markus.amend@telekom.de) wrote: Full ACK. 3GPP requests MP-QUIC to be applied between UE and UPF. Encapsulating the traffic from services on the UE into this MP-QUIC connection allows communication with the respective remote servers. Br Markus *From:* Waqar Zia <wzia@qti.qualcomm.com> *Sent:* Donnerstag, 3. Dezember 2020 09:49 *To:* Jana Iyengar <jri.ietf@gmail.com>; lionel.morand@orange.com *Cc:* magnus.westerlund@ericsson.com; lars@eggert.org; statements@ietf.org; Apostolis Salkintzis <salki@motorola.com>; gonzalo.camarillo@ericsson.com; 3GPPLiaison@etsi.org; chair@ietf.org; lucaspardue.24.7@gmail.com; martenseemann@gmail.com; Amend, Markus <Markus.Amend@telekom.de>; quic@ietf.org; martin.h.duke@gmail.com; kazuhooku@gmail.com *Subject:* RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" Hi Jana, The diagram is the correct depiction as I see: the MP-QUIC connection is indeed expected to be between the UE and the UPF, not between the UE and a (3GPP-) external server. Hence the reordering that may happen due to use of two different access technologies between the UE and UPF needs to be fixed at the UPF for the uplink and at the UE for the downlink. Best regards, Waqar. *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of *Jana Iyengar *Sent:* 03 December 2020 05:55 *To:* lionel.morand@orange.com *Cc:* magnus.westerlund@ericsson.com; lars@eggert.org; statements@ietf.org; Apostolis Salkintzis <salki@motorola.com>; gonzalo.camarillo@ericsson.com; 3GPPLiaison@etsi.org; chair@ietf.org; lucaspardue.24.7@gmail.com; martenseemann@gmail.com; Markus.Amend@telekom.de; quic@ietf.org; martin.h.duke@gmail.com; kazuhooku@gmail.com *Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" *CAUTION*: This email originated from outside of the organization. Speaking only as a user of computer technology, thanks for making this more palatable as a PDF. A few questions: - I am a bit confused by the picture, and Spencer or someone else can point me to something that I haven't read yet -- I thought the QUIC connection was between the remote server and the UE, not between the UPF and the UE. Am I missing something? - Assuming that the QUIC connection is between the UE and the remote server: Since only endpoints can see the packet numbers, how are the packets supposed to be re-sequenced at any point in the middle (the UPF)? Thanks! - jana On Tue, Dec 1, 2020 at 11:14 AM <lionel.morand@orange.com> wrote: Including Apostolis into the loop. *De :* Markus.Amend@telekom.de [mailto:Markus.Amend@telekom.de] *Envoyé :* mardi 1 décembre 2020 12:07 *À :* kazuhooku@gmail.com; MORAND Lionel TGI/OLN <lionel.morand@orange.com> *Cc :* magnus.westerlund@ericsson.com; statements@ietf.org; gonzalo.camarillo@ericsson.com; 3GPPLiaison@etsi.org; chair@ietf.org; lucaspardue.24.7@gmail.com; martenseemann@gmail.com; lars@eggert.org; quic@ietf.org; martin.h.duke@gmail.com *Objet :* RE: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" Thanks for raising this topic. With https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01 we consider exactly that and try to provide input to develop/discuss different re-ordering strategies. My personal belief is, that without any re-ordering implementation in the UPF or UE the end-to-end delivery will be worse. *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of *Kazuho Oku *Sent:* Dienstag, 1. Dezember 2020 11:29 *To:* lionel.morand@orange.com *Cc:* Magnus Westerlund <magnus.westerlund@ericsson.com>; Liaison Statement Management Tool <statements@ietf.org>; gonzalo.camarillo@ericsson.com; 3GPPLiaison@etsi.org; chair@ietf.org; Lucas Pardue < lucaspardue.24.7@gmail.com>; Marten Seemann <martenseemann@gmail.com>; Lars Eggert <lars@eggert.org>; QUIC Discussion List <quic@ietf.org>; Martin Duke <martin.h.duke@gmail.com> *Subject:* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" Lionel, thank you for converting the statement to PDF. Reading the document, I have one question. "The simultaneous transmission of a data flow across two accesses should not result in out-of-order delivery" I wonder what this sentence means. Is it suggesting that UPF (and possibly UE) would buffer packets that arrive on the faster path until the packets that were sent on the slower path reach that node? To give an example, let's say that UE has sent three packets: packet 1 sent using WiFi, packet 2 using LTE, packet 3 using WiFi. UPF receives packets in the order of 1, 3, 2. Is UPF expected to postpone the forwarding of packet 3 until it receives packet 2? I raise the question, because during the interim, some have pointed out that such buffering has negative effects on loss recovery, and that we should devote our efforts to designing an end-to-end multi-path design, rather than having an intermediary that aggregates paths (in this case UPF). 2020年12月1日(火) 18:43 <lionel.morand@orange.com>: Hi, Here is a pdf version. Regards, Lionel *De :* Marten Seemann [mailto:martenseemann@gmail.com] *Envoyé :* mardi 1 décembre 2020 05:17 *À :* Liaison Statement Management Tool <statements@ietf.org> *Cc :* Lucas Pardue <lucaspardue.24.7@gmail.com>; Lars Eggert < lars@eggert.org>; Magnus Westerlund <magnus.westerlund@ericsson.com>; MORAND Lionel TGI/OLN <lionel.morand@orange.com>; gonzalo.camarillo@ericsson.com; 3GPPLiaison@etsi.org; chair@ietf.org; QUIC Discussion List <quic@ietf.org>; Martin Duke <martin.h.duke@gmail.com> *Objet :* Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions" Would it be possible to publish this document in a format that can be opened by everyone without using proprietary software? Thank you, Marten On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool < statements@ietf.org> wrote: Title: LS on ATSSS Phase 2 conclusions Submission Date: 2020-11-30 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1710/ From: Susanna Kooistra <3GPPLiaison@etsi.org> To: Lars Eggert <lars@eggert.org>,Lucas Pardue <lucaspardue.24.7@gmail.com> Cc: QUIC Discussion List <quic@ietf.org>,Martin Duke < martin.h.duke@gmail.com>,Magnus Westerlund <magnus.westerlund@ericsson.com>,Lucas Pardue <lucaspardue.24.7@gmail.com>,Lars Eggert <lars@eggert.org>, gonzalo.camarillo@ericsson.com,chair@ietf.org Response Contacts: lionel.morand@orange.com,3GPPLiaison@etsi.org Technical Contacts: Purpose: For information Body: Attachments: S2-2009400_8852r02 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-11-30-3gpp-tsgsa-sa2-quic-ls-on-atsss-phase-2-conclusions-attachment-1.doc _________________________________________________________________________________________________________________________ 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. -- Kazuho Oku _________________________________________________________________________________________________________________________ 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.
- New Liaison Statement, "LS on ATSSS Phase 2 concl… Liaison Statement Management Tool
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Marten Seemann
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Gonzalo Camarillo
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Christian Huitema
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… lionel.morand
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Kazuho Oku
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Markus.Amend
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Gonzalo Camarillo
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Kevin
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… lionel.morand
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Apostolis Salkintzis
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Jana Iyengar
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Waqar Zia
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Markus.Amend
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Mikkel Fahnøe Jørgensen
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Markus.Amend
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Mikkel Fahnøe Jørgensen
- RE: New Liaison Statement, "LS on ATSSS Phase 2 c… Markus.Amend
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Roberto Peon
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Jana Iyengar
- RE: [External] Re: New Liaison Statement, "LS on … Apostolis Salkintzis
- Re: [External] Re: New Liaison Statement, "LS on … Spencer Dawkins at IETF
- Re: New Liaison Statement, "LS on ATSSS Phase 2 c… Behcet Sarikaya
- Draft response to New Liaison Statement, "LS on A… Lars Eggert
- Re: Draft response to New Liaison Statement, "LS … Behcet Sarikaya
- Re: Draft response to New Liaison Statement, "LS … Ian Swett
- Re: Draft response to New Liaison Statement, "LS … Lucas Pardue
- Re: Draft response to New Liaison Statement, "LS … Behcet Sarikaya
- RE: Draft response to New Liaison Statement, "LS … Waqar Zia
- Re: Draft response to New Liaison Statement, "LS … Lars Eggert
- Re: Draft response to New Liaison Statement, "LS … Jana Iyengar
- RE: Draft response to New Liaison Statement, "LS … Flinck, Hannu (Nokia - FI/Espoo)
- Re: Draft response to New Liaison Statement, "LS … Lars Eggert
- Re: Draft response to New Liaison Statement, "LS … Spencer Dawkins at IETF
- RE: Draft response to New Liaison Statement, "LS … Flinck, Hannu (Nokia - FI/Espoo)
- Re: Draft response to New Liaison Statement, "LS … Spencer Dawkins at IETF
- Re: Draft response to New Liaison Statement, "LS … Behcet Sarikaya