Re: [multipathtcp] MPTCP WG minutes - draft

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 19 April 2019 20:16 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE91200E6 for <multipathtcp@ietfa.amsl.com>; Fri, 19 Apr 2019 13:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 TjYhpi0UpjGZ for <multipathtcp@ietfa.amsl.com>; Fri, 19 Apr 2019 13:16:25 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E4012004A for <multipathtcp@ietf.org>; Fri, 19 Apr 2019 13:16:23 -0700 (PDT)
Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E697A29C06C for <multipathtcp@ietf.org>; Sat, 20 Apr 2019 05:16:20 +0900 (JST)
Received: by mail-wm1-f49.google.com with SMTP id z11so7349042wmi.0 for <multipathtcp@ietf.org>; Fri, 19 Apr 2019 13:16:20 -0700 (PDT)
X-Gm-Message-State: APjAAAU7ZDKPRpn4FmDyoY1RUqJcpJxlR19d/09rFPit+hmFbDUkiArg RiVJnfNkwzPqsAQUsDunkCKQA0axMM+NyGxCHss=
X-Google-Smtp-Source: APXvYqxslP3d2hJj7DoLrfm/SOzDQ3y/GvpPcKf7Q3vgmuAuEQnj+SpdU7aEV593zaiUsRhf+1ck8ahnXNp1olBkfXA=
X-Received: by 2002:a7b:c94c:: with SMTP id i12mr3793875wml.115.1555704978690; Fri, 19 Apr 2019 13:16:18 -0700 (PDT)
MIME-Version: 1.0
References: <LO2P123MB1965B4686737AFF0B42288BEEB240@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P123MB1965B4686737AFF0B42288BEEB240@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 19 Apr 2019 13:16:06 -0700
X-Gmail-Original-Message-ID: <CAO249yeAcxRFk+qHM1qqMeZ1DBb-vnhum2vNsFSybE-BDtyeZQ@mail.gmail.com>
Message-ID: <CAO249yeAcxRFk+qHM1qqMeZ1DBb-vnhum2vNsFSybE-BDtyeZQ@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a15af00586e7ca39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/bwkU-ZkvhdFAPmcE5ZvZxIgIJo0>
Subject: Re: [multipathtcp] MPTCP WG minutes - draft
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 20:16:30 -0000

Hi,
I've uploaded a draft minute on the following URL.

https://datatracker.ietf.org/doc/minutes-104-mptcp/

Please let us know if you have correction or questions, etc.
Thanks!
--
Yoshi & Phil



On Tue, Apr 16, 2019 at 3:05 AM <philip.eardley@bt.com>; wrote:

> Here are the draft minutes for our WG meeting in Prague. Please let us
> know any corrections.
>
> Thank-you to the minute takers – I think Anna & Xavier, please shout if I
> remember wrong!
>
> Thanks
>
> Phil & Yoshi
>
> --
>
>
>
> 1. WG status (chair)
>
>
>
> 2. Implementation news (Christoph)
>
> - Now have approval to open source the handshake
>
> - Mainline Linux kernel: growing community (RedHat, Intel, Thesaurus),
> making progress, will get there eventually, have support from Linux
> maintainers
>
> - Apache traffic server allows to enable MPTCP
>
>
>
> 3. Deployment updates
>
> 3.1. Results from the monitoring of MPTCP-based hybrid access networks -
> Olivier Bonaventure
>
> See slides for overview of talk
>
>
>
> Q & A
>
>
>
> Q Use of transparent proxy, do you need converter (Rahul Jadhav)
>
> A. CPE sees all the traffic, no need there. HAG may use a converter or be
> transparent. With transparent proxy on the HAG, all traffic must go
> through the HAG. Otherwise use a converter.
>
>
>
> Q. Can converter be extended with policy support for scheduling (Rahul
> Jadhav)
>
> A. Network operators control the policy
>
>
>
> Q. Shown employment is not consistent with 3GPP Rel 16 (Florin Baboescu?)
>
>
>
> Q. Specific scheduler used in deployment (Marcus Amend)
>
> A. Scheduler and path manager prioritize DSL network
>
>
>
> Q. In results, could you get 1G with single TCP flows. (Marcus Amend)
>
> A. Was with multiple flows
>
>
>
> Q. CPU overhead? (Marcus Amend)
>
> A. Really depend on the CPE
>
>
>
> Q. Need complement to TCP? It is hard to explain to customers if the
> benefit is for TCP only, this is why we propose a multipath UDP to
> complement MPTCP (Marcus Amend)
>
> A. BBF does also GRE approach, will see how QUIC will be supported
>
>
>
> Q. What is the issue with using MPTCP for tunneling IP traffic (Florin
> Baboescu?)
>
> A. MPTCP will give you reliability and delay for applications that do not
> need it.
>
>
>
> 3.2. Multi-path Transport Deployment on Smartphone Apps - Zhen Cao
>
> See slides for overview of talk
>
>
>
> Q & A
>
>
>
> Q. Can set ECN CE mark on the path you do not want the server to use (to
> implicitly tell server which path is preferred, eg toll-free) (Lars
> Eggert)
>
> Does ECN work with MPTCP? (Zhen)
>
> Yes (Stuart Cheshire)
>
> Using ECN will reduce the cwnd for when you need it (Anna Brunstrom)
>
> Need this functionality for other things (Marcus Amend)
>
> Do not need more functionality in MPTCP (Lars)
>
> Need to better understand the problem before we decide solution
>
> More discussion on the mailing list would be helpful, there were already a
> thread discussing this;
>
>
>
> Q. Why do you need MPTCP for mice flow.
>
> A. For better latency
>
>
>
> Q. Low latency path should naturally be the "best" path selected, so will
> not need anything special for path management to handle this (Lars)
>
> A. Ok, got your point; At least we agree on the scenario and the problem
> exists.
>
> Q  How often does this happen (Ben)
>
> A. With full mesh all the time
>
>
>
> Q. ATSSS slide not fully correct, only cover Rel. 15. (Florin)
>
> A. Thanks, please send them to the list as the group is not fully aware
> of what's happening in 3GPP.
>
>
>
>
>
> 4. Individual drafts
>
> 4.1. Initial-Path Selection for Connection Establishment in Multipath TCP
> - Jianjian Zhu
>
> See slides for overview of talk
>
>
>
> Q & A
>
> Q. This caching is already discussed in bis draft (Alan Ford)
>
>
>
> Q. RSSI is not enough, suggest to look at MAMS draft (Florin)
>
> Q CQI is what we use in mobile (Chris Seal)
>
>
>
> Q Selection of initial interface important, but is independent of MPTCP.
> There is the same problem in QUIC. This should not be designed for MPTCP
> only. (Christoph)
>
> This is happy eyeballs in narrow scope, please look at that if not famili
> ar. WiFi assist to prefer one interface. (Stuart Cheshire)
>
> Yes, this should be general solution. There will be PIPC side meeting
> (performance implications of path characteristics). (Zhen)
>
> Agree, it is a general issue, but think we should not limit multipath
> protocols to single path at start-up (Marcus)
>
> Keying attacks is a problem for happy eyeballs in MPTCP context (Alan Ford)
>
>
>
>
>
> 4.2. Generic Path-Manager Support with eBPF - Viet-Hoang Tran (remote)
>
> See slides for overview of talk
>
>
>
> Q & A
>
>
>
> 4.3. 5G Session Continuity Support in MPTCP - Xavier de Foy 5.
>
> See slides for overview of talk
>
>
>
> Q & A
>
>
>
> Q Multi-access PDN is introduced in 3GPP Rel. 16, not well mapped to
> talk, also all terminals know their address (Florin)
>
> A. Need to support continuity of addresses known at client but not at
> server
>
>
>
> Q. Key proposal is communicating session continuity type to remote peer? (
> Sri)
>
> A. Not really, it is one of the possible solutions but there are other
> options
>
> Q. This information is not enough, need additional information, need to
> analyze
>
> A. Actually in this particular solution the initial IP address index is
> also communicated to the remote peer, not only the session continuity type.
>
>
>
> Q Any data quantifying when you do nothing (Lars Eggert)
>
> A. No
>
> Q. Suggest we discuss this when we have data and know if there is a problem
>
> Q. Do you plan to get data (Phil)
>
> A. Do not have access to 5G network yet
>
> Any data even simulation may be useful, start with data (Lars)
>
>
>
> Q. For 3GPP we have clear items that have priority, would like to have
> focus on this, this is not one of them (Florin)
>
> Let's talk later to see how to best convey this to group (Phil)
>
>
>
>
>
> 5. Potential future topics for WG
>
> 5.1. Brief summary of Monday’s side meeting
>
> 5.2. TAPS multipath support – Anna Brunstrom
>
> 5.3. Open discussion
>
>
>
> Welcome input on API. Open issue on improving granularity of info (Apple
> use enum and 3 modes eg interactive, aggregation) (Tommy)
>
> Path manager and scheduler is a challenge because you often have two
> competing goals, reduce cost and improve performance. Ok on the client you
> can make this trade-off, but needs to be communicated to the server. We
> currently know who we talk to and configure a policy for a particular
> service, This is not a general solution, so some signalling from client to
> server would be very useful. (Christoph)
>
> Have you tried using ECN approach suggested by Lars? (Phil)
>
> Can perhaps support throughput, but does not work for latency (Christoph)
>
> Can we perhaps solve some of these issues in more general context, will
> apply to multipath QUIC as well at some time or any multipath protocol
>
> Think it is important to collect path scheduling algorithms in
> informational document (Markus)
>
> Issue is not only on handset, also on proxy that may implement load
> balancing scheme (Florin)
>
> Would be useful to tease this problem apart (Lars)
>
> Hear a lot of interesting issues, but they seem like research issues. Also
> some minor extensions, that could be done in tcpm. Also hear discussion on
> interfaces, this links to TAPS
>
> Not only research issues, also experiences from operational experience.
> Also need connection to BBF and 3GPP
>
> Can be handled in other groups (Mirja)
>
> Much easier if we have a group collecting MPTCP experts (Zhen)
>
> Concerned we are missing other experts here like congestion control.
> (Mirja)
>
>
>
> Do have issue if a terminal or proxy need to implement a policy, we have
> very clear requirements here. (Florin)
>
> For ATSSS we have a side channel for policies, right (Christoph)
>
> Issue is how to use the policy as I understand (Florin)
>
>
>
> Think we should have informational document on scheduling and path
> management for BBF and 3GPP to know. Do you think this is research? (Mark
> us)
>
> This topic is relevant for other protocols as well, we will find a home
> for this document (Mirja)
>
> Closing a wg is not a threat to close the work, perhaps we should have a
> general wg on multipath (Tommy)
>
> Agree a generic multipath group could be good. IEEE, 3GPP want to use
> IETF protocols, timeframe is ~ Dec 2019. (Florin)
>
> Do not understand why we should close a group when we have issues to solve
> (Zhen)
>
> Group has finished its charter, then we normally close. The mailing list
> can stay open. (Mirja)
>
>
>
>
>
>
>