[multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 10 June 2018 09:18 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 B90A5130E23 for <multipathtcp@ietfa.amsl.com>; Sun, 10 Jun 2018 02:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 FDaxQTyvIk2x for <multipathtcp@ietfa.amsl.com>; Sun, 10 Jun 2018 02:18:17 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9794D1292F1 for <multipathtcp@ietf.org>; Sun, 10 Jun 2018 02:18:17 -0700 (PDT)
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com []) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CE3EE27834B for <multipathtcp@ietf.org>; Sun, 10 Jun 2018 18:18:14 +0900 (JST)
Received: by mail-io0-f178.google.com with SMTP id g7-v6so20565733ioh.11 for <multipathtcp@ietf.org>; Sun, 10 Jun 2018 02:18:14 -0700 (PDT)
X-Gm-Message-State: APt69E0YNppw8loDiw4/b/SG9BHygVTdCxvbtzg1LgQvTNeJhhGmEgYd iAWQQWkrGSYJz0jM5DVJ1StFTSiCdbEttOr1c4o=
X-Google-Smtp-Source: ADUXVKKVm1RyaaIJioNJ/JPRTkkzGx4AhlXTYMU0CyZfhPtOmnKbbI14mklmD8gB+5gXLnyarzv3VheYfCtn14CwkHc=
X-Received: by 2002:a6b:3446:: with SMTP id b67-v6mr6513190ioa.6.1528622293613; Sun, 10 Jun 2018 02:18:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 02:18:13 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 10 Jun 2018 02:18:13 -0700
X-Gmail-Original-Message-ID: <CAO249yfimumoe5hpEXGLJyR5YzsuhJf3sNOzVfsvi5Vm4PVYaw@mail.gmail.com>
Message-ID: <CAO249yfimumoe5hpEXGLJyR5YzsuhJf3sNOzVfsvi5Vm4PVYaw@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce8228056e461c12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/f_awx-vhyZtRLZ7hKFOmZsBYxPs>
Subject: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis
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: Sun, 10 Jun 2018 09:18:20 -0000

Although I am still reading the draft, I have a few comments on 6824bis.

1: Section 3.5
    "If Host A wants to fore the closure of an MPTCP connection, it has two
different options:"
       -> It might be better if there are some descriptions about why we
have 2 options here. Also, a simple guidance of choosing them might be

   "if a host receives a packet with a valid MP_FASECLOSE option.."
       -> It seems that the rest of paragraph only explains the behavior
for Option A. If so, I think this should be stated to avoid confusions.

2:  As we have removed AddrID from MP_PRIO, we have a certain problem in
the situations like the followings.

Let's say a server has two address S1, S2 while the client is behind FW.
Since the client is behind firewall, the server uses ADD_ADDR to send the
info of S2 through S1, but it wants S2 to be used as a backup.

In this case, if MP_PRIO has addr id field, the server is able to specify
S2 is a backup. However, since MP_PRIO doesn't have addr id any more, all
the server can do is to wait until the client establishes the connection
with S2. But, this connection doesn't look what the server wants.
I guess using 1 bit in ADD_ADDR might solve the issue.