Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt
<mohamed.boucadair@orange.com> Fri, 12 July 2019 14:12 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 CE6621200F9 for <multipathtcp@ietfa.amsl.com>; Fri, 12 Jul 2019 07:12:40 -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 R_lW9rb7SQ9K for <multipathtcp@ietfa.amsl.com>; Fri, 12 Jul 2019 07:12:39 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35901200F3 for <multipathtcp@ietf.org>; Fri, 12 Jul 2019 07:12:38 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45lZd05LSgz7tfV; Fri, 12 Jul 2019 16:12:36 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 45lZd03wsXzCqkS; Fri, 12 Jul 2019 16:12:36 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 16:12:36 +0200
From: mohamed.boucadair@orange.com
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, Viet Hoang Tran <hoang.tran@uclouvain.be>, multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt
Thread-Index: AQHVNZlcK3DLtHMqM0iF5nfYK+VfKKbB/4UAgAB/WQCABGUYAIAAFF+AgAARoZA=
Date: Fri, 12 Jul 2019 14:12:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EACB234@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <DB7PR03MB42663A746B38EB94C2E26298EBF10@DB7PR03MB4266.eurprd03.prod.outlook.com> <156259608386.1077.9941810334684359467.idtracker@ietfa.amsl.com> <CGME20190709090506epcas2p3869fa7b28ff83bc7101823d00443397d@epcms5p4> <20190709164036epcms5p47c6632b5372d409bb26a300cea33be3e@epcms5p4> <787AE7BB302AE849A7480A190F8B93302EACB063@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <a6d7de83-5caf-32a1-29e5-1b766f815397@uclouvain.be>
In-Reply-To: <a6d7de83-5caf-32a1-29e5-1b766f815397@uclouvain.be>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/dG4MkgqykUUROhnhUlzxN9S3DKk>
Subject: Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt
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: Fri, 12 Jul 2019 14:12:41 -0000
Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De : Olivier Bonaventure [mailto:olivier.bonaventure@uclouvain.be] > Envoyé : vendredi 12 juillet 2019 15:00 > À : BOUCADAIR Mohamed TGI/OLN; Viet Hoang Tran; multipathtcp > Objet : Re: [multipathtcp] Fw: New Version Notification for draft-hoang- > mptcp-sub-rate-limit-00.txt > > Med, > > > 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). > > This would be a variation of the backup bit, with a different semantics. > There are different possible semantics, the current one says: > - don't use the backup subflow unless there is an active one > Other semantics could be: > - don't use the backup subflow as long as the delay on the active one is > below <250msec (this is roughly what Apple does with Wifi assist) > - don't use the backup subflow as long as the throughput of the active > one is above 1 Mbps [Med] Yes, the issue is how to unambiguously identify which semantic is associated with a single bit. For the sake if interoperability, more than one bit is needed to cover these cases. > > > ·“here is my suggested inbound traffic distribution ratio among > > established subflows”. > > As a percentage between the different subflows of an existing connection > ? [Med] Yes, typically. The main difficulty of such an approach is that the number of subflows > changes over time and client and servers might have a different view on > the number of subflows that are active. There are many corner cases that > make this difficult to implement in general. [Med] For the hybrid access case or within DCs, the number of subflows is not supposed to change that much. > > I think that a rate limit (typically on the cellular interface) covers > many of these use cases > > > ·“here is the maximum data that can be placed in a given subflow”. > > In bytes ? We could imagine an option that indicates that a given > connection can receive up to x MBytes and after that it will be released. [Med] OK, thanks. > > > Olivier
- [multipathtcp] Fw: New Version Notification for d… Viet Hoang Tran
- Re: [multipathtcp] Fw: New Version Notification f… Madhan Raj Kanagarathinam
- Re: [multipathtcp] Fw: New Version Notification f… Olivier Bonaventure
- Re: [multipathtcp] Fw: New Version Notification f… mohamed.boucadair
- Re: [multipathtcp] Fw: New Version Notification f… Olivier Bonaventure
- Re: [multipathtcp] Fw: New Version Notification f… mohamed.boucadair