[multipathtcp] comments on draft-samar-mptcp-socketapi-00

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 12 March 2018 22:32 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 D22B5127010 for <multipathtcp@ietfa.amsl.com>; Mon, 12 Mar 2018 15:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0XB7sTt5eGqS for <multipathtcp@ietfa.amsl.com>; Mon, 12 Mar 2018 15:32:11 -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 F36AA12422F for <multipathtcp@ietf.org>; Mon, 12 Mar 2018 15:32:10 -0700 (PDT)
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 958E629C3F4 for <multipathtcp@ietf.org>; Tue, 13 Mar 2018 07:32:07 +0900 (JST)
Received: by mail-wr0-f169.google.com with SMTP id l8so2958766wrg.5 for <multipathtcp@ietf.org>; Mon, 12 Mar 2018 15:32:07 -0700 (PDT)
X-Gm-Message-State: AElRT7FieyVvN1IIXg6hIiijtJxgqYfAGkEc1wk9fOnc2cEe1w3HSUPp w6t2LyrAVLgWE4ToaqEMUykx/qX26dx5Fyd3WPk=
X-Google-Smtp-Source: AG47ELshJzbAl7t/KpV/SHwj9C4aBPCDqQf92EQkpLFoaUJQpOWaaVC9S8UvFOCjKF7wDiysS4JGn+L+6LzXYzusbEI=
X-Received: by 10.223.133.70 with SMTP id 64mr7904943wrh.164.1520893925164; Mon, 12 Mar 2018 15:32:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.169.23 with HTTP; Mon, 12 Mar 2018 15:32:04 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 12 Mar 2018 15:32:04 -0700
X-Gmail-Original-Message-ID: <CAO249yeVB3oG3VFmGtYWPMmCANPwSZ_0Jo8nN2nXPD7zGod+4A@mail.gmail.com>
Message-ID: <CAO249yeVB3oG3VFmGtYWPMmCANPwSZ_0Jo8nN2nXPD7zGod+4A@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/O8Z1RUUYpCFn_tuE9N9BLaHYF2c>
Subject: [multipathtcp] comments on draft-samar-mptcp-socketapi-00
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Mar 2018 22:32:13 -0000

Hello,
I've read  draft-samar-mptcp-socketapi-00. I think it focuses on an
interesting point.
I have listed my comments below.


1:  "The first important step to set the subflow priority is to get the
      list of available subflows. This can be performed using the
     "MPTCP_GET_SUB_IDS" socket option defined by Hensman et al"

  -> In my understanding, MPTCP_GET_SUB_IDS only returns ID and its priority.
      I guess we might also need to use "MPTCP_GET_SUB_TUPLE".
     Otherwise, I'm not sure how we can determine the path has proper
priority or not.


2:  My very personal preference is to have prio variable rather than
low_prio and use prio=0
     for backup, prio>=1 for higher priority. Because I'm not sure how
to use low_prio>1 much.
     If this is used as a flag, I think we don't need to use 16bits.
     But, I guess this would be a comment on
draft-hesmans-mptcp-socket rather than this draft.


3:  The active and backup lists contain 4 tuples. But, if a subflow
gets disconnect and
     we try to reconnect, can we always use the same 4 tuples used before?
     For example, SO_REUSE_ADDR may not be set or IP addr my be changed.


Thanks,
--
Yoshi