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) > > > > > > >
- [multipathtcp] MPTCP WG minutes - draft philip.eardley
- Re: [multipathtcp] MPTCP WG minutes - draft Yoshifumi Nishida