Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt

Matt Joras <matt.joras@gmail.com> Tue, 02 June 2020 16:34 UTC

Return-Path: <matt.joras@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 26FBF3A0D4D for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 09:34:50 -0700 (PDT)
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, 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 rprT9Cvp5mN7 for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 09:34:47 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 D07293A0DC3 for <quic@ietf.org>; Tue, 2 Jun 2020 09:34:27 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id e1so1057273vkd.1 for <quic@ietf.org>; Tue, 02 Jun 2020 09:34:27 -0700 (PDT)
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=TjKRzpcasSMBURlt8qxicwvNa7YN1BqFr6H14fr2dl8=; b=Q24EXJbd1WhXmk61Z1/WH4vebhIZ9AQNx0AQUKoVTFoeVZbj/5Vc8Gn9euivgvfrnB NLhx5KD/5lZsV6OEQQiLk6zke6pEK9EWQGC1JO35EwjJ4u1xUqwHi7Lyf2hJV0YV+IOd d/0mlp8aVtwwIRga8R9n6BksfiftEkeLC0YS/k/WkTuZ34k21+ZLsrb6DCxA/XMqc1Lq PEBzWRzxAUF9bUGqdci2Xw9UubsMwmRuXo2m8j07V2hOHozRYiLAhyb168SOXw3IZeX7 BMFB7W6a1P13W1akyvXyu0YfZco8uuHfYC5LlqY1CDGAZ7Eo+2cqFMUoS4Nr9ad/dcc8 QbMw==
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=TjKRzpcasSMBURlt8qxicwvNa7YN1BqFr6H14fr2dl8=; b=U4OyMv95fPIz4mHaOSuryX87gpN5hFy3rf7dTHdEJqlYAul0NoYeUM8B3Epcy1c4nL zTfGoHJIqa+MheVPrSPcOGrztVQSqvd7Lz6l3EoheoeMB9sBEiEggqZXNu2WFdwN0n/Q L1/uRRuHlV6qa90GRTDykd8sCs41XkjP9pJtiOidEfGtc2cqoow19wRpMKXYEvb6Bs6V l0pP+iTRlEecNmYsNvwwIgxV+EffNM5tBF8/OcAFds0m3pGCn2j4ZqRPaih0XrHtJsRN Zb/W72w6ZJA5M3JOiItAdLjBPr87yUgSfAFZJWDsszVDTO282MBbdqMjPtHWT1jIhvKR 5bNQ==
X-Gm-Message-State: AOAM533Ncjg5h3JGnRphqMKeFo4lBy2Xbnz6b0/EvH7yNqNuy0+EgEiv ZrJwaaFTWu5CtIsreHmMIxkel6/YPgt1rFFJbFI=
X-Google-Smtp-Source: ABdhPJxxRnScVuRW39HqSxZr0Ha4XuLG+GAiBqKL10Bc71Uw86+ipDxgBcwr5UI66+jONH4g1khk0FlaIBoMGGxewjA=
X-Received: by 2002:a05:6122:34:: with SMTP id q20mr5032505vkd.66.1591115666654; Tue, 02 Jun 2020 09:34:26 -0700 (PDT)
MIME-Version: 1.0
References: <159084638843.27466.7915766554130545967@ietfa.amsl.com> <CAKKJt-eHQtgjc-zuO7vrGZ1Q2c7=3hetOb0FyqnEmbTDu1Uwuw@mail.gmail.com>
In-Reply-To: <CAKKJt-eHQtgjc-zuO7vrGZ1Q2c7=3hetOb0FyqnEmbTDu1Uwuw@mail.gmail.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Tue, 2 Jun 2020 09:34:14 -0700
Message-ID: <CADdTf+iBRLu20OH-WTEmo=e7WZ8Ce5QVP+_LWO09u6LxjCPe2g@mail.gmail.com>
Subject: Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b88bb05a71c7cc9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FK5w6Cqy5okXzzPbD75GIws3Ukk>
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, 02 Jun 2020 16:34:57 -0000

On Tue, Jun 2, 2020 at 4:39 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Dear QUIC,
>
> Several of us submitted this draft (which I emphasize has no special
> status in IETF, 3GPP, or between IETF and 3GPP).It's being used as one of
> the inputs to SA2#139E, which is underway now (and that also doesn't give
> it any special status)..
>
> We are, of course, interested in comments, especially if we've gotten
> something wrong about QUIC, directions for MP-QUIC, or apparent gaps.
>
> The QUIC chairs have told us this is an appropriate thing to discuss on
> the QUIC mailing list - we did ask.
>
Thank you very much for producing and sharing this document, I agree it is
appropriate for this forum. The diagrams in the document are especially
helpful.

That being said, I have a lot of concerns about the feasibility and
usefulness of the schemes in this document. I wonder if this usage of QUIC
is in the spirit of many QUIC deployments, or if it potentially hinders an
application's usage of QUIC. Correct me if I am wrong, but it seems one of
the core tenets of these schemes is that user applications on mobile
devices would have their flows to servers transparently tunneled over a
multipath transport and then "untunneled" for the final transit to the
server. One of the benefits of QUIC in practice is the ability to
potentially bring the transport implementation "closer" to the application
than was traditionally possible with TCP. One useful signal to applications
is the transport's knowledge of the underlying path state. By transparently
tunneling a QUIC connection over multiple paths this signal is lost. This
has practical implications; the congestion controller used by the transport
cannot proactively act on network switching signals, and the application
cannot proactively adjust its behavior either. As a trivial example, an ABR
streaming video application may detect that the underlying path has
switched and subsequently adjust the bandwidth. One could imagine partially
getting around this problem by implementing a channel on the UE (i.e. some
sort of API) through which the information about the underlying path state
is conveyed to the QUIC transport which is being tunneled. However, this
doesn't address the loss of information for the server. Additionally, I
would argue that if this UE informational channel exists there is no need
to tunnel QUIC traffic at all -- the QUIC transport being utilized directly
by the application can manage its use of the underlying network interfaces.

Said another way, I think it would be useful to further discuss why these
problems need to be solved in "the network" itself rather than focusing on
making QUIC "natively" capable of optimally navigating 5G networks.


>
> Best,
>
> Spencer, but not just Spencer
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Sat, May 30, 2020 at 8:46 AM
> Subject: New Version Notification for
> draft-bonaventure-quic-atsss-overview-00.txt
> To: SungHoon Seo <sh.seo@kt.com>om>, Olivier Bonaventure <
> Olivier.Bonaventure@uclouvain.be>gt;, Qing An <anqing.aq@alibaba-inc.com>om>,
> Markus Amend <markus.amend@telekom.de>de>, Andreas Kassler <
> andreas.kassler@kau.se>gt;, Spencer Dawkins <spencerdawkins.ietf@gmail.com>om>,
> Mohamed Boucadair <mohamed.boucadair@orange.com>om>, Quentin De Coninck <
> quentin.deconinck@uclouvain.be>gt;, Mirja Kuehlewind <
> mirja.kuehlewind@ericsson.com>gt;, Olivier Bonaventure <
> olivier.bonaventure@uclouvain.be>gt;, Nicolas Keukeleire <
> nicolas.keukeleire@tessares.net>gt;, Maxime Piraux <
> maxime.piraux@uclouvain.be>
>
>
>
> A new version of I-D, draft-bonaventure-quic-atsss-overview-00.txt
> has been successfully submitted by Olivier Bonaventure and posted to the
> IETF repository.
>
> Name:           draft-bonaventure-quic-atsss-overview
> Revision:       00
> Title:          3GPP Access Traffic Steering Switching and Splitting
> (ATSSS) - Overview for IETF Participants
> Document date:  2020-05-30
> Group:          Individual Submission
> Pages:          29
> URL:
> https://www.ietf.org/internet-drafts/draft-bonaventure-quic-atsss-overview-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bonaventure-quic-atsss-overview/
> Htmlized:
> https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bonaventure-quic-atsss-overview
>
>
> Abstract:
>    This document briefly presents the Access Traffic Steering,
>    Switching, and Splitting (ATSSS) service being specified within the
>    3rd Generation Partnership Project (3GPP).  The ATSSS service
>    provides network support for multihomed devices to select a path for
>    transmission (steer), move traffic from one path to another (switch),
>    or use multiple paths simultaneously (split).  TS 23.501 specifies an
>    ATSSS architecture for TCP traffic.
>
>    This document presents a snap-shot of the ongoing discussion in the
>    3GPP to enable ATSSS for non-TCP traffic, based on the use of QUIC,
>    and assesses to what extent IETF specifications can be used to meet
>    the ATSSS design goals.  Apparent gaps are also documented.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
Matt Joras