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

Alexander Frömmgen <Alexander@froemmgen.de> Sat, 18 May 2019 19:16 UTC

Return-Path: <Alexander@froemmgen.de>
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 AD9971200EF for <multipathtcp@ietfa.amsl.com>; Sat, 18 May 2019 12:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlVuS1jlQdnZ for <multipathtcp@ietfa.amsl.com>; Sat, 18 May 2019 12:16:49 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B239120019 for <multipathtcp@ietf.org>; Sat, 18 May 2019 12:16:48 -0700 (PDT)
Received: from [10.198.14.170] ([2.247.246.170]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) 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: <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be>
References: <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----M5RRUQVOD9Z7KB1KNKKB513O8SMWAI"
Content-Transfer-Encoding: 7bit
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, Nagesh shamnur <nagesh.shamnur@huawei.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
CC: Ashutosh prakash <ashutosh.prakash@huawei.com>
From: =?ISO-8859-1?Q?Alexander_Fr=F6mmgen?= <Alexander@froemmgen.de>
Message-ID: <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/4l3ovQM8jfjPBJOtykayyk5SGck>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level
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: Sat, 18 May 2019 19:16:52 -0000

Hi,

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 https://progmp.net for further information.

Best,

Alexander 

Am 17. Mai 2019 11:59:54 MESZ schrieb Olivier Bonaventure <olivier.bonaventure@uclouvain.be>;:
>Dear Nagesh,
>> 
>>                  Greetings. In case of Mobile deployments of MPTCP, 
>> though the data rates are getting cheaper, still it would be wise not
>to 
>> run the cellular path to full limit but to throttle to a certain
>extent 
>> 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
>the 
>Linux kernel.
>
>> So, while going through the discussion archives, could 
>> only find that, the peer(server) can throttle the speed for the
>entire 
>> 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 ?
>
>Thanks
>
>
>Olivier
>
>_______________________________________________
>multipathtcp mailing list
>multipathtcp@ietf.org
>https://www.ietf.org/mailman/listinfo/multipathtcp