[multipathtcp] 答复: Possible future items for mptcp WG

Kangjiao <kangjiao@huawei.com> Thu, 12 July 2018 03:39 UTC

Return-Path: <kangjiao@huawei.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 84DA6130DCD for <multipathtcp@ietfa.amsl.com>; Wed, 11 Jul 2018 20:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tGKGu8s08bsx for <multipathtcp@ietfa.amsl.com>; Wed, 11 Jul 2018 20:39:35 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 556DD130EB1 for <multipathtcp@ietf.org>; Wed, 11 Jul 2018 20:39:35 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 3568E57699C24 for <multipathtcp@ietf.org>; Thu, 12 Jul 2018 04:39:31 +0100 (IST)
Received: from DGGEMM401-HUB.china.huawei.com ( by lhreml705-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 04:39:32 +0100
Received: from DGGEMM514-MBX.china.huawei.com ([]) by DGGEMM401-HUB.china.huawei.com ([]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 11:39:27 +0800
From: Kangjiao <kangjiao@huawei.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Possible future items for mptcp WG
Thread-Index: AQHUA6+0vapSxC934kaBBPCOPQrT36SLGjgg
Date: Thu, 12 Jul 2018 03:39:26 +0000
Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8F@dggemm514-mbx.china.huawei.com>
References: <CAO249ycbh_rL+i310=UtVyE39=Yk+OSRWfcj1UyF=74VZwC8vw@mail.gmail.com>
In-Reply-To: <CAO249ycbh_rL+i310=UtVyE39=Yk+OSRWfcj1UyF=74VZwC8vw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8Fdggemm514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/n1EcAXL93OIuGgkAeJ4e1A6ki14>
Subject: [multipathtcp] 答复: Possible future items for mptcp WG
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 12 Jul 2018 03:39:40 -0000

Dear chair and all,

The scheduling algorithm plays an important role for the performance of MPTCP and has an impact to its deployment, and it is an important part in the code base.  But it has not been well documented in IETF.  Although most scheduling algorithms do not require protocol extension, it is useful to document some of them into experimental or informational categories.

draft-zuo-mptcp-scheduler/ draft-zuo-mptcp-degradation / draft-song-mptcp-owl have discussed such problem, and I am glad to share more of our experience in future.

Best regards,

发件人: multipathtcp [mailto:multipathtcp-bounces@ietf.org] 代表 Yoshifumi Nishida
发送时间: 2018年6月14日 15:17
收件人: multipathtcp <multipathtcp@ietf.org>
主题: [multipathtcp] Possible future items for mptcp WG

Hello everyone,

Phil and I have been discussing the next step for the WG.
After we finish 6824bis, we won't have active WG items as the proxy work will be discussed at tcpm WG.
One suggestion might be to close the WG or to put it in dormant state, however, we are thinking there still might be some more working items as we've seen interesting presentations for new ideas, experiment results and so on at the meetings and on the ML.

Below is the list of potential working items from the chairs' point of view.
Please let us know if you think some of them are important items for the WG (and your willingness to contribute if possible) or there are some more items, or this is not something we should work on, etc.

Also, if you have some opinions on the status of the WG or suggestions to the chairs, please let us hear!

We appreciate your feedback

Yoshi & Phil

1: API extensions (This is already in our charter)

2: Feature extensions
    a) robust initial setup
        proposed by Markus, also Kien presented a similar idea

    b) fast subflow setup
        proposed by Quentin

    c) security enhancement
        1) TLS

        2) Utilize proposals from tcpinc?

        3) Elliptic Curve Cryptography

    d) Solutions for operational issues
         1) how to handle nat64 issue proposed by Quentin
         2) how to handle load balancer proposed by Fabien, Christoph, Costin

3: Congestion Control (This topic itself should probably be discussed at ICCRG. But, it may trigger some updates of the protocol or APIs later)
     a) OLIA

     b) mptcp + BBR?
          presented by Jing