Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

Olivier Bonaventure <> Fri, 12 July 2019 13:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF34E1200C5 for <>; Fri, 12 Jul 2019 06:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sUGRJVzp5XFJ for <>; Fri, 12 Jul 2019 06:00:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09CBA120045 for <>; Fri, 12 Jul 2019 06:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p7ZLEdbPmnv0iqwgNMJKALfGqtyyoWnd1r9xKG8tHlI=; b=QzfJVHBWM63mmGVROOL69EN8gxZ3IjEkWlXvddBjWOUZvy0tpcYvez/n6arnj6ug0wekQD1ckbtyhvUR0dY8SoX6Lc4xITDpP8UMdvdME8RB9+/2CaUtUfKGryfj9aOtoNgbMBljGA9qQu0nYZN1SKFFXw4V6soR8nEWFUiqbog=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 12 Jul 2019 13:00:25 +0000
Received: from ([fe80::9537:894:b343:bced]) by ([fe80::9537:894:b343:bced%5]) with mapi id 15.20.2052.020; Fri, 12 Jul 2019 13:00:24 +0000
From: Olivier Bonaventure <>
To: "" <>, Viet Hoang Tran <>, multipathtcp <>
Thread-Topic: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt
Date: Fri, 12 Jul 2019 13:00:24 +0000
Message-ID: <>
References: <> <> <CGME20190709090506epcas2p3869fa7b28ff83bc7101823d00443397d@epcms5p4> <20190709164036epcms5p47c6632b5372d409bb26a300cea33be3e@epcms5p4> <787AE7BB302AE849A7480A190F8B93302EACB063@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EACB063@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Reply-To: Olivier Bonaventure <>
Accept-Language: en-US
Content-Language: en-US
x-clientproxiedby: LO2P265CA0424.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::28) To (2603:10a6:209:2e::28)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:6a8:308f:2:31e0:ad7b:2e7c:22c7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6a14d2a2-cc47-42e3-74cf-08d706c8e793
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR03MB5973;
x-ms-traffictypediagnostic: AM6PR03MB5973:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00963989E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(189003)(199004)(51444003)(66446008)(71190400001)(52116002)(5660300002)(229853002)(53936002)(256004)(6246003)(305945005)(66556008)(6116002)(7736002)(64756008)(6512007)(66476007)(3450700001)(66946007)(478600001)(14444005)(786003)(102836004)(2501003)(36756003)(71200400001)(46003)(110136005)(43066004)(99286004)(76176011)(446003)(14454004)(31696002)(68736007)(15650500001)(476003)(31686004)(486006)(11346002)(81166006)(316002)(25786009)(6436002)(6506007)(86362001)(186003)(8936002)(8676002)(6486002)(2906002)(81156014)(2616005)(386003)(46800400005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR03MB5973;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 8pKkrrgLi/AUISgTRO0I8E2ykLOjIRI0h4NdwA11yBWIfgqkk216fslPnvaqONFPGYoP4P3BMp8gCMd7gVNRGRZhcaG0lq3ryXyljQifhABiP3l7EpQKQVksNPxq98HRhSC2vYlYuAsimINxjkuhsT9uerElxRiGs7DuQVluwMCv2hGJuDWryr6u9TnU5o6dGh/K42N+wuUQP6IkjBN8kAmvCijAsol2CVNUEj6ePtko0vMxGtpy7IJMB7KVgdmUUvR8W2c0N+hHFAUfq4XrC91aPTvK/Q6U6GDixGNg4dq5BtyT/gU56LW/Mocukb2CI+fBfqdHOlu3kB5loOxcNvCa7pvVyPAbDfrDphAl5VqK4eYh39OAcusAxBCpYgrX+hj6Vcq6gpgcrScBcst9CDEoJH0Rd3fpVrcIa206/q0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a14d2a2-cc47-42e3-74cf-08d706c8e793
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 13:00:24.7409 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB5973
Archived-At: <>
Subject: Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2019 13:00:31 -0000


> 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

> ·“here is my suggested inbound traffic distribution ratio among 
> established subflows”.

As a percentage between the different subflows of an existing connection 
? 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.

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.