IETF Logo Mail Archive

Re: [multipathtcp] Fwd: New Version Notification for draft-duchene-mptcp-add-addr-00.txt

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 17 July 2016 08:48 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 F027712D1AE for <multipathtcp@ietfa.amsl.com>; Sun, 17 Jul 2016 01:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 KluMg8CXPpS6 for <multipathtcp@ietfa.amsl.com>; Sun, 17 Jul 2016 01:48:25 -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 3DCF912B02B for <multipathtcp@ietf.org>; Sun, 17 Jul 2016 01:48:24 -0700 (PDT)
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B3F3727828C for <multipathtcp@ietf.org>; Sun, 17 Jul 2016 17:48:22 +0900 (JST)
Received: by mail-vk0-f43.google.com with SMTP id w127so147143507vkh.2 for <multipathtcp@ietf.org>; Sun, 17 Jul 2016 01:48:22 -0700 (PDT)
X-Gm-Message-State: ALyK8tL5rviLGTn3fyPHAUi6HkPVGKiwC0ocaxPlyToZFvvbmdmNSRdlO3mknTbAy9BOzworoFj6YQCGJJzi3w==
X-Received: by 10.159.36.15 with SMTP id 15mr12500490uaq.79.1468745301253; Sun, 17 Jul 2016 01:48:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.164 with HTTP; Sun, 17 Jul 2016 01:48:20 -0700 (PDT)
In-Reply-To: <31308e25-f968-443c-2839-c5ddda22f2fa@uclouvain.be>
References: <20160708153425.32046.92545.idtracker@ietfa.amsl.com> <31308e25-f968-443c-2839-c5ddda22f2fa@uclouvain.be>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 17 Jul 2016 01:48:20 -0700
X-Gmail-Original-Message-ID: <CAO249ydbnTNB1=fm+Maen+2wx08znzix7i_tSfK28Q+=C4QtMQ@mail.gmail.com>
Message-ID: <CAO249ydbnTNB1=fm+Maen+2wx08znzix7i_tSfK28Q+=C4QtMQ@mail.gmail.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Content-Type: multipart/alternative; boundary="001a113cd586f267f50537d0e91a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/5MacaaLhEvwiy8LNsxCMt76fwyI>
Cc: multipathtcp <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-duchene-mptcp-add-addr-00.txt
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jul 2016 08:48:28 -0000

Hi Oliver, Fabien,

I've read the draft and I am having the following comments on the draft.

1: Reliability
    DSS option doesn't have to be set on all data packets. So, I think
there'll be a good chance to use ADD_ADDR in data packets in most cases.
Also, I am not very sure if we really need to echo back the option for
reliability. Can't we just send ADD_ADDR several times when we are not sure?

2:Backup
   I think MP_PRIO can be sent from other flow by using address id. Isn't
it possible to send ADD_ADDR and MP_PRIO almost the same time?

3: Priority
   I might want to know the use case of this. I would like to know how
having multiple priority can be useful.

4: Path Diversity
   I think path diversity can be varied by routing. Even if two addresses
use the same interface, they might be forwarded to different routes. We
might not be sure if they share common resources.

5: Load Balancing
   A question would be if we want to allocate a flag in MP_CAPABLE for a
single use case.
   I am wondering if we can utilize MP_PRIO to indicate that this is a
"no_join" path, which will be easier for allocating resource.

Thanks,
--
Yoshi


On Mon, Jul 11, 2016 at 4:44 AM, Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> FYI,
>
> This draft describes several issues related to the advertisement of
> addresses in Multipath TCP and explains the bit proposed during the load
> balancing discussion at the interim meeting
>
> A new version of I-D, draft-duchene-mptcp-add-addr-00.txt
> has been successfully submitted by Fabien Duchene and posted to the
> IETF repository.
>
> Name:           draft-duchene-mptcp-add-addr
> Revision:       00
> Title:          Multipath TCP Address Advertisement
> Document date:  2016-07-08
> Group:          Individual Submission
> Pages:          13
> URL:
> https://www.ietf.org/internet-drafts/draft-duchene-mptcp-add-addr-00.txt
>
>
>
> Abstract:
>    Multipath TCP [RFC6824] defines the ADD_ADDR option that allows a
>    host to announce its addresses to the remote host.  In this document
>    we propose some improvements to this mechanism.
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

v2.23.0 | Report a Bug | By Email