Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10

<mohamed.boucadair@orange.com> Mon, 15 July 2019 05:28 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 31929120075 for <multipathtcp@ietfa.amsl.com>; Sun, 14 Jul 2019 22:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ALhmPdLW-Dfi for <multipathtcp@ietfa.amsl.com>; Sun, 14 Jul 2019 22:28:30 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C48F120074 for <multipathtcp@ietf.org>; Sun, 14 Jul 2019 22:28:30 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 45nBrr43ssz4wXW; Mon, 15 Jul 2019 07:28:28 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 45nBrr3CLtz1xpr; Mon, 15 Jul 2019 07:28:28 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 15 Jul 2019 07:28:28 +0200
From: <mohamed.boucadair@orange.com>
To: Nagesh shamnur <nagesh.shamnur@huawei.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: multipathtcp Digest, Vol 125, Issue 10
Thread-Index: AQHVOKekdmqLj3wk7U6pOv8FBDy0NabG8QQggAQ3zGA=
Date: Mon, 15 Jul 2019 05:28:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAD4CBB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <mailman.1484.1562932056.8637.multipathtcp@ietf.org> <2c70c4c508744700b19379179f5ecea0@huawei.com>
In-Reply-To: <2c70c4c508744700b19379179f5ecea0@huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/mvqbJIC5zTSOsrTisQV5K6fxSj8>
Subject: Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Jul 2019 05:28:32 -0000

Hi Nagesh, 

The subtlety here is that this case is not a backup one that can be managed with the current definition of b-bit (see the discussion with Olivier). 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Nagesh shamnur
> Envoyé : vendredi 12 juillet 2019 15:15
> À : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10
> 
> Hi Med,
> 	I have a question regarding this point " to use a given subflow only
> where there is a need to grab more resources (that is, don?t use this
> subflow if data can be placed on other subflows)." MP_PRIO option with 'b'
> bit can be used to achieve the same,  then why need new option?
> 
> Regards,
> Nagesh S
> 
> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> multipathtcp-request@ietf.org
> Sent: 12 July 2019 17:18
> To: multipathtcp@ietf.org
> Subject: multipathtcp Digest, Vol 125, Issue 10
> 
> Send multipathtcp mailing list submissions to
> 	multipathtcp@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/multipathtcp
> or, via email, send a message with subject or body 'help' to
> 	multipathtcp-request@ietf.org
> 
> You can reach the person managing the list at
> 	multipathtcp-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of multipathtcp digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Fw: New Version Notification for
>       draft-hoang-mptcp-sub-rate-limit-00.txt
> (mohamed.boucadair@orange.com)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 12 Jul 2019 11:47:28 +0000
> From: <mohamed.boucadair@orange.com>
> To: Viet Hoang Tran <hoang.tran@uclouvain.be>be>, multipathtcp
> 	<multipathtcp@ietf.org>
> Subject: Re: [multipathtcp] Fw: New Version Notification for
> 	draft-hoang-mptcp-sub-rate-limit-00.txt
> Message-ID:
> 	<787AE7BB302AE849A7480A190F8B93302EACB063@OPEXCAUBMA2.corporate.adro
> ot.infra.ftgroup>
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Hoang, all,
> 
> Thank you for igniting this work.
> 
> FWIW, we used to have this requirement in draft-nam-mptcp-deployment-
> considerations (with cellular networks in mind):
> 
>    ?For cases where some access networks are subject to a volume quota,
>    it is desirable to support a signal to indicate to a remote peer how
>    it must place data into available subflows?.
> 
> The rate-limit option as currently defined may not be adequate. I would
> like an option which allows to tell a remote peer, for example:
> 
> ?         to use a given subflow only where there is a need to grab more
> resources (that is, don?t use this subflow if data can be placed on other
> subflows).
> 
> ?         ?here is my suggested inbound traffic distribution ratio among
> established subflows?.
> 
> ?         ?here is the maximum data that can be placed in a given
> subflow?.
> 
> Did you consider those schemes?
> 
> Cheers,
> Med
> 
> --------- Original Message ---------
> 
> Sender : Viet Hoang Tran <hoang.tran@uclouvain.be>
> 
> Date : 2019-07-09 14:35 (GMT+5:30)
> 
> Title : [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-
> sub-rate-limit-00.txt
> 
> 
> 
> We submitted two drafts on  Subflow Rate Limit Option and
> 
>  Inactivity Time Option (https://tools.ietf.org/html/draft-hoang-mptcp-
> inactivity-time-00)
> 
> 
> 
> Feedbacks and suggestions are more than welcomed.
> 
> Thanks,
> 
> 
> 
> Hoang & Olivier
> 
> 
> 
> ________________________________________
> 
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> 
> Sent: Monday, 8 July 2019 16:28
> 
> To: Viet Hoang Tran; Olivier Bonaventure; Olivier Bonaventure
> 
> Subject: New Version Notification for draft-hoang-mptcp-sub-rate-limit-
> 00.txt
> 
> 
> 
> A new version of I-D, draft-hoang-mptcp-sub-rate-limit-00.txt
> 
> has been successfully submitted by Viet-Hoang Tran and posted to the
> 
> IETF repository.
> 
> 
> 
> Name:           draft-hoang-mptcp-sub-rate-limit
> 
> Revision:       00
> 
> Title:          Multipath TCP Subflow Rate Limit Option
> 
> Document date:  2019-07-08
> 
> Group:          Individual Submission
> 
> Pages:          6
> 
> URL:            https://www.ietf.org/internet-drafts/draft-hoang-mptcp-
> sub-rate-limit-00.txt
> 
> Status:         https://datatracker.ietf.org/doc/draft-hoang-mptcp-sub-
> rate-limit/
> 
> Htmlized:       https://tools.ietf.org/html/draft-hoang-mptcp-sub-rate-
> limit-00
> 
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hoang-mptcp-
> sub-rate-limit
> 
> 
> 
> 
> 
> Abstract:
> 
>    This document defines a new MPTCP Option that enables hosts to
> 
>    request their peers to limit the maximum transfer rate on a per-
> 
>    subflow basis.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> _______________________________________________
> 
> multipathtcp mailing list
> 
> multipathtcp@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> [cid:image001.png@01D538B4.F419FBF0]
> 
> [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.r
> aj&do=bWFpbElEPTIwMTkwNzA5MTY0MDM2ZXBjbXM1cDQ3YzY2MzJiNTM3MmQ0MDliYjI2YTMw
> MGNlYTMzYmUzZSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__]
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/2019071
> 2/1e2caade/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.png
> Type: image/png
> Size: 33527 bytes
> Desc: image001.png
> URL:
> <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/2019071
> 2/1e2caade/attachment.png>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> 
> ------------------------------
> 
> End of multipathtcp Digest, Vol 125, Issue 10
> *********************************************
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp