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

Christoph Paasch <cpaasch@apple.com> Mon, 20 May 2019 13:50 UTC

Return-Path: <cpaasch@apple.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 B29C61200A1 for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 06:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 7dbLp8pDe7My for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 06:50:29 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DFD12006F for <multipathtcp@ietf.org>; Mon, 20 May 2019 06:50:29 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x4KDh5Cn023136; Mon, 20 May 2019 06:50:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=msGgwKczAC8iRcmUT48YcGbOuvFhh5Ig+FDw+UosC+k=; b=WncXHl4DoPVIpIkvsDuSQdAlp3BK2NNPcdDC51USANuEYnpZiG0zWdN1Gym4JN+AsJZf sY0CDCvV3mBjlffZ2Q2w4QV2W+8/3g3mqjflI8oCxa+uSDwF2PBdJNDMHpEkfdMOhKxY c00oHMFd7a9EZPX1jZJ0851C99IrIxqyWExPYOUHIz6nqF3VjWhDhNHJ3yHpUBKYO3M5 qF5rnHVthnt9vBeeQIKK7GVEXUp9r+Us4QBBtxvDDcVMn7RG+6/4SjNncJDyDLrItjs8 3vJDj9TwgFSCGVyGTRGmxo5py50IR8c8us06+F3a/5M/H2kTtCAQLOgWGJsHw1PDvpE4 LQ==
Received: from crk-mtap-sz03.euro.apple.com (crk-mtap-sz03.euro.apple.com [17.66.12.163]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2sjgq3yy7u-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 May 2019 06:50:23 -0700
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from crk-mmpp-sz03.euro.apple.com (crk-mmpp-sz03.euro.apple.com [17.66.12.165]) by crk-mtap-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PRT0090S2FUPU00@crk-mtap-sz03.euro.apple.com>; Mon, 20 May 2019 14:50:19 +0100 (IST)
Received: from process_milters-daemon.crk-mmpp-sz03.euro.apple.com by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PRT0030018II000@crk-mmpp-sz03.euro.apple.com>; Mon, 20 May 2019 14:50:18 +0100 (IST)
X-Va-A:
X-Va-T-CD: 898e848f874e09327ba6d50c279412d2
X-Va-E-CD: fa1b89b0552380aed154bca0ec78f78e
X-Va-R-CD: 41c7eaf6ea6aaf0e55ae76183796a6ac
X-Va-CD: 0
X-Va-ID: b1bbb152-b71f-4b78-aa93-0af25e00cdff
X-V-A:
X-V-T-CD: 898e848f874e09327ba6d50c279412d2
X-V-E-CD: fa1b89b0552380aed154bca0ec78f78e
X-V-R-CD: 41c7eaf6ea6aaf0e55ae76183796a6ac
X-V-CD: 0
X-V-ID: bf368377-5245-48ef-a8a3-e2b99e8f3e80
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-05-20_07:,, signatures=0
Received: from localhost ([17.235.194.130]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PRT008H02FQK1A0@crk-mmpp-sz03.euro.apple.com>; Mon, 20 May 2019 14:50:15 +0100 (IST)
Sender: cpaasch@apple.com
Date: Mon, 20 May 2019 14:50:14 +0100
From: Christoph Paasch <cpaasch@apple.com>
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>
Cc: Nagesh shamnur <nagesh.shamnur@huawei.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>, Ashutosh prakash <ashutosh.prakash@huawei.com>
Message-id: <20190520135014.GG41806@MacBook-Pro-64.local>
References: <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be>
In-reply-to: <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be>
User-Agent: Mutt/1.11.4 (2019-03-13)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_07:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/fyhIpWnXCr0sImRECGh8Lx1zWdc>
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: Mon, 20 May 2019 13:50:31 -0000

Hello,

On 17/05/19 - 09:59:54, Olivier Bonaventure wrote:
> 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 ?

another use-case for rate-control I see is when a client wants to tell a sender
to gracefully close a subflow.

- Sending a TCP-RST results in packet-loss of the in-flight data.
- Reducing the window is going to stall the whole connection because the window is shared.
- Setting MP_PRIO also won't work because none might want to drain a secondary
  subflow even if the "primary" subflow is having severe packet-loss.

Thus, a "maximum-rate" option on a per-subflow level would allow to send the
rate to 0, which would drain the subflow.


Christoph