[multipathtcp] Possible future items for mptcp WG

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 14 June 2018 07: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 2082C1310D9 for <multipathtcp@ietfa.amsl.com>; Thu, 14 Jun 2018 00:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wfdmNve3Gavy for <multipathtcp@ietfa.amsl.com>; Thu, 14 Jun 2018 00:16:45 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E880F1310D3 for <multipathtcp@ietf.org>; Thu, 14 Jun 2018 00:16:44 -0700 (PDT)
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com []) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 68D3E278375 for <multipathtcp@ietf.org>; Thu, 14 Jun 2018 16:16:42 +0900 (JST)
Received: by mail-io0-f172.google.com with SMTP id d22-v6so6107437iof.13 for <multipathtcp@ietf.org>; Thu, 14 Jun 2018 00:16:42 -0700 (PDT)
X-Gm-Message-State: APt69E0LDzynAWHIR9Pi9rlQUIhLHy1aen5Y+vDJd/8E3R+7WDiHCnP+ oP+p8hEcj6YRCW3ooYT5SDBtQx7tkVOwQQqxhII=
X-Google-Smtp-Source: ADUXVKLwBBaNhw+bGfqlC57m+3jVP/BqBNIMbBNCPiN5c4/tXMHlh+UjLGoKM0zRHImCRu+CFS3ietiEobYL3A+pzYY=
X-Received: by 2002:a6b:9654:: with SMTP id y81-v6mr1196057iod.237.1528960601315; Thu, 14 Jun 2018 00:16:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 00:16:40 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Thu, 14 Jun 2018 00:16:40 -0700
X-Gmail-Original-Message-ID: <CAO249ycbh_rL+i310=UtVyE39=Yk+OSRWfcj1UyF=74VZwC8vw@mail.gmail.com>
Message-ID: <CAO249ycbh_rL+i310=UtVyE39=Yk+OSRWfcj1UyF=74VZwC8vw@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008464da056e94e17d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/B_ij7ASXdLUtGzmk3J39EamxJpA>
Subject: [multipathtcp] Possible future items for mptcp WG
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.26
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, 14 Jun 2018 07:16:52 -0000

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,

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