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

Christian Huitema <huitema@huitema.net> Tue, 02 June 2020 20:58 UTC

Return-Path: <huitema@huitema.net>
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 089BE3A0FE6 for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 13:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 E4NAzeCRo9d6 for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 13:58:03 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE553A0FE1 for <quic@ietf.org>; Tue, 2 Jun 2020 13:58:03 -0700 (PDT)
Received: from xse381.mail2web.com ([66.113.197.127] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jgDyt-000Oi0-On for quic@ietf.org; Tue, 02 Jun 2020 22:58:02 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49c3Mq15dzz1N9H for <quic@ietf.org>; Tue, 2 Jun 2020 13:21:11 -0700 (PDT)
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jgDPL-0002Ib-0l for quic@ietf.org; Tue, 02 Jun 2020 13:21:11 -0700
Received: (qmail 23616 invoked from network); 2 Jun 2020 20:21:10 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 2 Jun 2020 20:21:10 -0000
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Matt Joras <matt.joras@gmail.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
References: <159084638843.27466.7915766554130545967@ietfa.amsl.com> <CAKKJt-eHQtgjc-zuO7vrGZ1Q2c7=3hetOb0FyqnEmbTDu1Uwuw@mail.gmail.com> <CADdTf+iBRLu20OH-WTEmo=e7WZ8Ce5QVP+_LWO09u6LxjCPe2g@mail.gmail.com> <D2BBDD3C-89F7-43BF-B5C3-1EC5E8C69EBE@ericsson.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Subject: Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt
Message-ID: <72be8104-e738-136f-d05c-285fc49533dc@huitema.net>
Date: Tue, 2 Jun 2020 13:21:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <D2BBDD3C-89F7-43BF-B5C3-1EC5E8C69EBE@ericsson.com>
Content-Type: multipart/alternative; boundary="------------DB208CD9031F14F4D8EC05F7"
Content-Language: en-US
X-Originating-IP: 66.113.197.127
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhV31piCdLkRgHf gOdwi6+6aUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsTjVhN8wl5j0b4EVC2UUwdU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/YxFBjiwvt8YGG8KnqhbQXbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilZpnfSx1WjM8 Y221ho/pD3/YTgm/NnC/c8YEQ5zoBxO0OPaVMIQAyjx/8zuyzh/o8gJ3dmaBobK9d6GPrTwLmzrv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV240rHJtSVPlENYbD9JAuv2lDzAXPU1UvCyITFs2AML0Poh8JzgkVH7m09sItCDRNTRHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+06ejVsMqjCBuJMyJeyF7Ye08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5rkW9BQTGAfrK1gaoEyTjYXTD3o>
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 20:58:06 -0000

I think that we should be very clear that the primary goal for QUIC
multipath design is end-to-end. For example, a device might very well
have connection with 2 cellular networks, each providing their own
"advanced" services, and use end-to-end multipath to balance traffic
between the two networks.

We also have to consider multipath privacy. In the ATSSS setup, the
device is supposed to establish a connection with the mobile operator's
service even in cases when it is only connected to a Wi-Fi network. That
means disclosing connectivity and activity to the operator, just in case
a backup through cellular might be needed. This is definitely a
trade-off that many applications will not want to make. End to end
multipath alleviates that concern, because the network operators only
learn of the device's activity when the devices actually uses their network.

-- Christian Huitema

On 6/2/2020 12:44 PM, Mirja Kuehlewind wrote:
>
> Hi Matt,
>
>  
>
> thanks for the feedback. Please note that in ATSSS the UE can decide
> to use this multipath service, or not, e.g. if the server provides
> multipath support directly (or even do both but not sure how useful
> that is). However, using the network supported service can be
> beneficial for downlink traffic towards the UE as the network might
> have information about network state and potential needs to handover.
> This information can be shared with the UE, however, there is no
> protocol mechanism to share this information with the server. I
> believe we briefly mention this in the draft but I guess this
> discussion could definitely be more explicit.
>
>  
>
> Mirja
>
>  
>
>  
>
>  
>
> *From: *QUIC <quic-bounces@ietf.org> on behalf of Matt Joras
> <matt.joras@gmail.com>
> *Date: *Tuesday, 2. June 2020 at 18:36
> *To: *Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> *Cc: *IETF QUIC WG <quic@ietf.org>
> *Subject: *Re: New Version Notification for
> draft-bonaventure-quic-atsss-overview-00.txt
>
>  
>
>  
>
>  
>
> On Tue, Jun 2, 2020 at 4:39 AM Spencer Dawkins at IETF
> <spencerdawkins.ietf@gmail.com <mailto: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 <mailto: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 <mailto:sh.seo@kt.com>>, Olivier
>     Bonaventure <Olivier.Bonaventure@uclouvain.be
>     <mailto:Olivier.Bonaventure@uclouvain.be>>, Qing An
>     <anqing.aq@alibaba-inc.com <mailto:anqing.aq@alibaba-inc.com>>,
>     Markus Amend <markus.amend@telekom.de
>     <mailto:markus.amend@telekom.de>>, Andreas Kassler
>     <andreas.kassler@kau.se <mailto:andreas.kassler@kau.se>>, Spencer
>     Dawkins <spencerdawkins.ietf@gmail.com
>     <mailto:spencerdawkins.ietf@gmail.com>>, Mohamed Boucadair
>     <mohamed.boucadair@orange.com
>     <mailto:mohamed.boucadair@orange.com>>, Quentin De Coninck
>     <quentin.deconinck@uclouvain.be
>     <mailto:quentin.deconinck@uclouvain.be>>, Mirja Kuehlewind
>     <mirja.kuehlewind@ericsson.com
>     <mailto:mirja.kuehlewind@ericsson.com>>, Olivier Bonaventure
>     <olivier.bonaventure@uclouvain.be
>     <mailto:olivier..bonaventure@uclouvain.be>>, Nicolas Keukeleire
>     <nicolas.keukeleire@tessares.net
>     <mailto:nicolas.keukeleire@tessares.net>>, Maxime Piraux
>     <maxime.piraux@uclouvain.be <mailto: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 <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>  
>
> Matt Joras
>