Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"

Kazuho Oku <kazuhooku@gmail.com> Tue, 01 December 2020 10:29 UTC

Return-Path: <kazuhooku@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 8FDE63A10CA; Tue, 1 Dec 2020 02:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FM0UwVprtSuC; Tue, 1 Dec 2020 02:29:36 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 B0B8D3A10C7; Tue, 1 Dec 2020 02:29:36 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id d8so1029579ioc.13; Tue, 01 Dec 2020 02:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uAvXd58taN36EVwSOVlRYR3u8vIgmR9hWitdSnalgJQ=; b=I3GAN//OlTVP4CN2qFRsiL4oO1geOpu4coTJXi0HghZz+Dmg24b4RVu42Z88f/pg+E GuOQGuLqm3LUMyLKzrBkvxKzCMqGUZ4aTUvpho988WcBhRrL1aBpfmmtZy/zxaE2ZQmY FU+RX1lWQ4qKWXmVELUcHjjp6vvCTL62qjn5m0n6htI8sMGgwDY3GsiA6SmcEe0Yt7V4 DFDv7+Nmk/zEb98RbhBZKZCpNH10j2dnS1MXO7sIqYmKyLi9QIPDZDTdAUwfyhtpvomK VVH4QFKSpLqaodgJG+UD6AcAN9zYM5YJm9lUbfWtvWjZz5aJqZVTQep+1d5pU+aHNvwz /CdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uAvXd58taN36EVwSOVlRYR3u8vIgmR9hWitdSnalgJQ=; b=nRLn8OGijVlHfNhJxZUx4MrihAVvdt7AX3fORc6pXG8C6pPOpxNydAoE0Z568RjcW7 qBvfeCpzH0XN0RuBcbuO4Rs8v1dmf01o4fT8aF5c984rDU6hp4ClNYooPppR1UQclQyL kMcn3O786SuSdv6QV8xb35mVyQAvyvl6VL0bO0dvKy2TLscM87dOfqgPpUBBd0FbI6JA Tw6sFII0oea1Zu37cpHCtW2MTC7Jl07PQcg1U41DlUnF/WDiYbhu/ae6kMTdvqfiYFS/ Txk1UaEiJo5NBaTYNLoR0Sx/itxD4uwPMS9MjFyJXnb21MiQI6y7mV8ZLAoWhRVpaMFJ hQtA==
X-Gm-Message-State: AOAM531TSyq2JJGmyzGfXVB693MiuQ2Tu4hI9JgWGgXH0jC0xBKmt+ZU Zc4hiWOAJkaoqGNtfDVjlTU6JMoHY/83YxTrT8U=
X-Google-Smtp-Source: ABdhPJwZmCTpeTLDSNdLhjMrSyh4CtT9LosTNm5Y8LX8H16yP9sEKkk+U/aQkM/fIIBh1sXTzNDO4q8400Wrbig+1N0=
X-Received: by 2002:a6b:fb19:: with SMTP id h25mr1804144iog.200.1606818575949; Tue, 01 Dec 2020 02:29:35 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <7047_1606815783_5FC61027_7047_384_1_6B7134B31289DC4FAF731D844122B36E3A64B1F1@OPEXCAUBM41.corporate.adroot.infra.ftgroup>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 01 Dec 2020 19:29:24 +0900
Message-ID: <CANatvzwjyfrzoX6vA4S81hABQXcpYCJ7DWEDYBnNnRLFGWMgXg@mail.gmail.com>
Subject: Re: New Liaison Statement, "LS on ATSSS Phase 2 conclusions"
To: lionel.morand@orange.com
Cc: Marten Seemann <martenseemann@gmail.com>, Liaison Statement Management Tool <statements@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>, "3GPPLiaison@etsi.org" <3GPPLiaison@etsi.org>, "chair@ietf.org" <chair@ietf.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Lars Eggert <lars@eggert.org>, QUIC Discussion List <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000070247605b5649a52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kSv92A6xAFzp2LxgbkCxQv4et5w>
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: Tue, 01 Dec 2020 10:29:39 -0000

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