Re: [multipathtcp] Regarding rate control at a subflow level

Alexander Frömmgen <> Sat, 18 May 2019 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD9971200EF for <>; Sat, 18 May 2019 12:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XlVuS1jlQdnZ for <>; Sat, 18 May 2019 12:16:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B239120019 for <>; Sat, 18 May 2019 12:16:48 -0700 (PDT)
Received: from [] ([]) by (mreue010 []) with ESMTPSA (Nemesis) id 1M3lsh-1hSttu0dcp-000pzX; Sat, 18 May 2019 21:16:37 +0200
Date: Sat, 18 May 2019 21:16:32 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----M5RRUQVOD9Z7KB1KNKKB513O8SMWAI"
Content-Transfer-Encoding: 7bit
To: Olivier Bonaventure <>, Nagesh shamnur <>, "" <>
CC: Ashutosh prakash <>
From: Alexander Frömmgen <>
Message-ID: <>
X-Provags-ID: V03:K1:FyC8fb6ZsAcdjNNvayGXLlU+Fpln1nJC/2OpfkolFq8DeIvirLH KluhoxpvszPbc25kmlzW5crMR4nXaGIX1Ts7gATyxfvSWQX6/W9lfF0nCP+5IhxsmJ4VOJd PFV8VOenj3aQl6VqKPoFoXt2I2+lK3rrFbXZXsNdqf1TZFOK+OYxDQ/0HHWSMeXIhwIlAWb Iw6b9y9rQFqOOn6ehFkdA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:5A2R10q/UOI=:pyD6w2Z6Q7FVD288585Am5 ST/sVVbMd8Hg89SqnTQvrjN7fK6hJoIiqaXGctvD4UsbCHm/HkcgEaK2UXA8N5+bqcC97TnSw cpTNk+EJPVKQsTGgjRLFDT7wAjRRT+R/yT67ODLHJWm1auZ/Rl9V8UhCfZGzZil4UU0SbNCv+ Cz9kFMFm3B5nNi7MuEuVvTNSnXb07MqabSgr67kqN7E44aHmCEM94XYEy8C199wdqQG8ZD2Ii 0P+y/4Wya4RdGwY5tSkA7jEvhk4XMw7Ljdl9x6PdQe0XvnjCEqKLxovGXgIYQtb1ggBV2X1un V26+tHIZf71F1QyXXDLLBxSBR0BGLtR+Hta6tW/zD+j+JfqTbqAC4cQi/J4tzOA+mHUYrh3I1 21m0S1Lb+/2R5Od/E/kwXBCJP1RGcTLBvAaRHE/4f0lEcGclJqMef8Fzds6acnFXDT9j/4uUB WMCuttMbRYd4PJ5KzpjfWjIMIrhxZTvaVHfOfqmRliqa0esAlLq6uf1jAGb5M9/8QyBwWlS4n ile/ZrSK0dUwun4zSouc69VUqvdwJ6Vh2PnTJA7gi6u5kXIkp+BgFoOfEDn2piykohb982eou vpDwSBRsvAySdspphxlb6fngsOMTzbD16xXtEPxICDb02wQDkq7xJyaL5HSg+S703RGMuEhqD DdR+5y4tNUHiPLm44RdA27YmA5Ia7YzNmvdRar5/SWSf0lvxAWynypD6w9nLsVewFhuoYo30Z pGyPzj18eb39tJcP5P6BY6aXIXPRngzhmpK3vi9Dh0gE6KX7qf243JJgqVg=
Archived-At: <>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level
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: Sat, 18 May 2019 19:16:52 -0000


We experimented with different schedulers that implement related behaviour, e.g., to only use cellular data if a target throughput can't be provided otherwise and only transfer the fraction of data on the cellular path that is required to achieve the target throughput (which is effectively a kind of dynamic rate limiting). See for further information.



Am 17. Mai 2019 11:59:54 MESZ schrieb Olivier Bonaventure <>:
>Dear Nagesh,
>>                  Greetings. In case of Mobile deployments of MPTCP, 
>> though the data rates are getting cheaper, still it would be wise not
>> run the cellular path to full limit but to throttle to a certain
>> considering cost in mind or if server wants to limit the client at 
>> subflow level, then I couldn’t find the support for the same in the 
>> specification. 
>We have developed several prototypes that include this capability in
>Linux kernel.
>> So, while going through the discussion archives, could 
>> only find that, the peer(server) can throttle the speed for the
>> connection by publishing a smaller receiver window rather than for a 
>> particular subflow. I feel, it would be a good idea if the peers can 
>> exchange this information using the control packets.
>We could imagine an MPTCP option that provides the maximum rate on a 
>per-subflow level, but I was wondering whether the use case is not to 
>limit the bandwidth on the smartphone at the link level (i.e. multiple 
>tcp connections or udp flows) and not at the subflow level. Could you 
>precise your use case for the subflow level ?
>multipathtcp mailing list