Re: [multipathtcp] Regarding rate control at a subflow level
<philip.eardley@bt.com> Tue, 18 June 2019 09:45 UTC
Return-Path: <philip.eardley@bt.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 BF209120100 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Jun 2019 02:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 BsuJFm_GDR5Z for <multipathtcp@ietfa.amsl.com>; Tue, 18 Jun 2019 02:45:10 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8910D1200F8 for <multipathtcp@ietf.org>; Tue, 18 Jun 2019 02:45:09 -0700 (PDT)
Received: from tpw09926dag03e.domain1.systemhost.net (10.9.202.18) by BWP09926080.bt.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 18 Jun 2019 10:44:41 +0100
Received: from tpw09926dag06g.domain1.systemhost.net (10.9.202.29) by tpw09926dag03e.domain1.systemhost.net (10.9.202.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 10:45:06 +0100
Received: from bwp09926080.bt.com (10.36.82.111) by tpw09926dag06g.domain1.systemhost.net (10.9.202.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 18 Jun 2019 10:45:06 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.52) by smtpe1.intersmtp.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 18 Jun 2019 10:44:40 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=euQkdtydyDgacnhNSPNbN3p9FfspCprQDPqB0XQUFhg=; b=MUVxhwaGFFXKsJGSodJcAVdHiO6hZfmlKoJ8baH9oW3fznptIlKTZp1MpqPjEgaEfZpKJjM6lr+8iedThqOu1qP+g33M0T//DJ/60G6uubrm3PwHY/naEHDz7BaOlFXlKtZE1SwGbjm8z7AZGr6TWSSY+3Rrr9I6tAOidJ3iBx4=
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1930.GBRP123.PROD.OUTLOOK.COM (20.179.128.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Tue, 18 Jun 2019 09:45:05 +0000
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::d0d4:e85d:d101:97f0]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::d0d4:e85d:d101:97f0%7]) with mapi id 15.20.1987.014; Tue, 18 Jun 2019 09:45:05 +0000
From: philip.eardley@bt.com
To: nagesh.shamnur@huawei.com, cpaasch=40apple.com@dmarc.ietf.org, olivier.bonaventure@uclouvain.be
CC: multipathtcp@ietf.org, ashutosh.prakash@huawei.com
Thread-Topic: [multipathtcp] Regarding rate control at a subflow level
Thread-Index: AdUMWULM15YYbMauQ2OybE7pkHW5IQAPgMiAAJ7rTAAB/BSx4AAbSJeAAJ2MIhAACavsgALqxxHA
Date: Tue, 18 Jun 2019 09:45:04 +0000
Message-ID: <LNXP123MB2587FB78BF5AC2BB256E4A66EBEA0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
References: <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <20190520135014.GG41806@MacBook-Pro-64.local> <LO2P123MB1965EA246F2652E9D5C47731EB180@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM> <4AC96705FB868F42B2075BA50F806DEB569B1298@dggema524-mbx.china.huawei.com> <LO2P123MB1965E1FF05CB40AC39F8B36AEB140@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM> <4AC96705FB868F42B2075BA50F806DEB569B1748@dggema524-mbx.china.huawei.com>
In-Reply-To: <4AC96705FB868F42B2075BA50F806DEB569B1748@dggema524-mbx.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com;
x-originating-ip: [193.113.37.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cdd0a7b4-9268-4cc4-aafb-08d6f3d1a451
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1930;
x-ms-traffictypediagnostic: LNXP123MB1930:
x-ms-exchange-purlcount: 1
x-antispam-2: 1
x-microsoft-antispam-prvs: <LNXP123MB1930B57ECAC21C7B19ED04ACEBEA0@LNXP123MB1930.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 007271867D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(346002)(376002)(136003)(189003)(199004)(13464003)(8936002)(9686003)(7736002)(66476007)(66946007)(64756008)(66556008)(66446008)(14454004)(478600001)(26005)(76116006)(2501003)(305945005)(73956011)(316002)(14444005)(3846002)(6116002)(71190400001)(71200400001)(186003)(66066001)(966005)(256004)(446003)(68736007)(476003)(11346002)(486006)(5660300002)(53936002)(6436002)(25786009)(33656002)(81156014)(2906002)(102836004)(110136005)(6506007)(52536014)(81166006)(86362001)(6246003)(229853002)(76176011)(53546011)(6306002)(7696005)(55016002)(8676002)(4326008)(99286004)(74316002)(54906003)(20673002); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1930; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: vbvpK3OIgS8aTUqfHW3DSbHg/B/Z+wIIflG9KS+50Pc3eJ0Q58j51xQV+KQpVqXZzTML4uqtHjekBzMifB8SFpmTX3jFKP1TOMPKIoai9DthDX1T2WmdAtZu75nEHITh67mMaul6wDpwJa8719hux+/muExW5iwz1ojcINPorYrKz4ukZg30JtU0X2CxAwdbL3mJWs9ZJY/E+ASCFgH6tU9hMJtCvb+NxHnUTi5dbLscipCNwtr5zW83LMVx5xkSwZDavhJ29Sg8UvE6UBmVOPTQYIXlfQWXjsQtcaz/Tlzefa7ehBgau1qnl67aKxgfuWNodcBSSGp/nukvv0Z4E+azA+LeTFKNlT0fGLvin1J1iow6p+o0LjTyc80cJI4lmnqIjh772+mwZQn73WeYR92vNjAG9Z/H273GeITzk8c=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cdd0a7b4-9268-4cc4-aafb-08d6f3d1a451
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2019 09:45:04.9264 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1930
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6570
X-NAI-Spam-Version: 2.2.0.9309 : core <6570> : inlines <7107> : streams <1824834> : uri <2857341>
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/WQe-FnuB6O7sAL66mKbwGkscE9A>
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: Tue, 18 Jun 2019 09:45:14 -0000
Nagesh, Thanks, interesting to hear about an upstream use case. Would be good to explore the scenario in a bit more detail. As you say, the congestion control algorithm can be used to stop one connection starving others (ie server / network-side drop packets to slow down a connection). I think you're hinting that this may not be good enough in all scenarios (<< but there can be cases where the application decides to limit the bandwidth to avoid possibly overload kind of scenarios.>>) - would you explain this a bit more please? I'm trying to understand what benefit we might gain from some extra signalling (whether of preferences, a rate to limit to, or whatever) and therefore whether it's something we should think about doing. Thanks phil ps Sorry for delay, been away. -----Original Message----- From: Nagesh shamnur [mailto:nagesh.shamnur@huawei.com] Sent: 03 June 2019 14:07 To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com> Subject: RE: [multipathtcp] Regarding rate control at a subflow level Hi Phil, The idea is about controlling the rate on the uplink rather than the downlink and the decision to limit the bandwidth is made at the server since, server can control the downlink traffic rate to all the clients connected to it, but the uplink limit needs to be pushed to the client. Regards, Nagesh S -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: 03 June 2019 15:46 To: Nagesh shamnur <nagesh.shamnur@huawei.com>; cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com> Subject: RE: [multipathtcp] Regarding rate control at a subflow level Nagesh, Could you explain your scenario a bit more please? Not sure I get it right. Is this about uplink? Is the application decision to limit the bandwidth made at the client or at the server, and does the network have a role (either in the decision making or supplying info)? Thanks phil -----Original Message----- From: Nagesh shamnur [mailto:nagesh.shamnur@huawei.com] Sent: 31 May 2019 06:19 To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com> Subject: RE: [multipathtcp] Regarding rate control at a subflow level Hi Phil, I am glad the problem is being discussed upon. One more possible usecase is for load balancing to achieve one or a set of clients doesn't hog the entire bandwidth available on the server side. Though the links to server supports the bandwidth but still chooses to limit the bandwidth. I agree, this is left best to be dealt with congestion control algorithm to achieve the bandwidth sharing, but there can be cases where the application decides to limit the bandwidth to avoid possibly overload kind of scenarios. Regards, Nagesh S -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: 30 May 2019 23:23 To: cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>; Nagesh shamnur <nagesh.shamnur@huawei.com> Subject: RE: [multipathtcp] Regarding rate control at a subflow level I think the use case a hybrid operator could be interested in is the following. Similar to Alexander's use case. We want to provide a particular customer with broadband access that is faster than their DSL alone can provide, for instance to meet some minimum rate to meet a target of say 20Mbps. The rate can't quite be met by DSL, therefore cellular or even satellite is used as a top-up. DSL capacity is much cheaper than cellular /satellite, therefore the ideal scheduler would favour DSL. It would react reasonably quickly to increased total load above the DSL rate (but not so fast that the instantaneous rate from a variable rate source 'kicks in' the cellular when the rate over a slightly longer time can be met by DSL). Note that the DSL rate is not completely static. It supports deployments with a proxy in the home gateway and in the network (under the control of the operator), and deployments where there's only the proxy in the network (ie MPTCP is in the multi-interface phone). Possible to ensure that an individual flow goes over only one access. Downward direction (from network to house) more important than upward. In a long-running session using a lot of bandwidth, because the amount of other traffic varies, it may be that this session sometimes uses just the DSL and sometimes is spread over both accesses. On a minor point, ideally a speed test should measure the rate correctly (I don’t mean the scheduler identifies a speed test and favours it; rather, ideally the speed test shouldn’t eg measure just the DSL rate - alternatively re-define the speed test). So in terms of Olivier's question below, I think this means that the limit is about the total and not per subflow. In terms of mechanism, I'm open to whatever is most suitable. I'm very interested if the best method would mean that ideally some new functionality is added to the MPTCP standard (and by implication to MP-QUIC). Best wishes, phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch Sent: 20 May 2019 14:50 To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be> Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>; Nagesh shamnur <nagesh.shamnur@huawei.com> Subject: Re: [multipathtcp] Regarding rate control at a subflow level 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 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp
- [multipathtcp] Regarding rate control at a subflo… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Olivier Bonaventure
- Re: [multipathtcp] Regarding rate control at a su… Alexander Frömmgen
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Christoph Paasch
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … philip.eardley
- Re: [multipathtcp] (4) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… Gregory Detal
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] (4) Regarding rate control at … philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Olivier Bonaventure
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (4) Regarding rate control at … philip.eardley
- Re: [multipathtcp] (2) (4) Regarding rate control… Madhan Raj Kanagarathinam