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

<philip.eardley@bt.com> Thu, 20 June 2019 15:24 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 3A0411200C1 for <multipathtcp@ietfa.amsl.com>; Thu, 20 Jun 2019 08:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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, SPF_PASS=-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 zRIylrSWnjxW for <multipathtcp@ietfa.amsl.com>; Thu, 20 Jun 2019 08:24:25 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45689120086 for <multipathtcp@ietf.org>; Thu, 20 Jun 2019 08:24:25 -0700 (PDT)
Received: from tpw09926dag10g.domain1.systemhost.net (10.9.202.45) by BWP09926079.bt.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 20 Jun 2019 16:24:20 +0100
Received: from tpw09926dag07e.domain1.systemhost.net (10.9.202.34) by tpw09926dag10g.domain1.systemhost.net (10.9.202.45) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Jun 2019 16:24:22 +0100
Received: from bwp09926077.bt.com (10.36.82.108) by tpw09926dag07e.domain1.systemhost.net (10.9.202.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 20 Jun 2019 16:24:22 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.53) by smtpe1.intersmtp.com (10.36.82.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 20 Jun 2019 16:24:18 +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=O8YL6iI+zuk4poLD88WZ/yMHX7ArT+cNVxtKXnZa/1k=; b=V/+PIax1FiYeVQAEAKNKYSXWzmrtHkvfU4pDY5VFWqtc4jF1eYrMvfDRUZxKldaU94jy6h9XVEmpanC9GDHIlmZndeLEbVP2EU1U0duor4LKHE2R8BPcZHUGOo2he6so4iYndDHGCs+azqZ6wbQJj8kB/7wRD2OW6FM8+PmVrsU=
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2282.GBRP123.PROD.OUTLOOK.COM (20.179.128.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Thu, 20 Jun 2019 15:24:18 +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; Thu, 20 Jun 2019 15:24:18 +0000
From: <philip.eardley@bt.com>
To: <cpaasch=40apple.com@dmarc.ietf.org>, <olivier.bonaventure@uclouvain.be>
CC: <multipathtcp@ietf.org>, <ashutosh.prakash@huawei.com>, <nagesh.shamnur@huawei.com>
Thread-Topic: [multipathtcp] Regarding rate control at a subflow level
Thread-Index: AdUMWULM15YYbMauQ2OybE7pkHW5IQAPgMiAAJ7rTAAGGheMoA==
Date: Thu, 20 Jun 2019 15:24:18 +0000
Message-ID: <LNXP123MB25872FB755F07346E3C7D9E9EBE40@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>
In-Reply-To: <20190520135014.GG41806@MacBook-Pro-64.local>
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: 12f47f1d-d915-48ae-e034-08d6f5935cd6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2282;
x-ms-traffictypediagnostic: LNXP123MB2282:
x-ms-exchange-purlcount: 1
x-antispam-2: 1
x-microsoft-antispam-prvs: <LNXP123MB2282D35B47676EC496F52C96EBE40@LNXP123MB2282.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0074BBE012
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(136003)(366004)(189003)(199004)(13464003)(9686003)(7696005)(25786009)(55016002)(6246003)(102836004)(64756008)(66946007)(66556008)(76176011)(66446008)(966005)(76116006)(5660300002)(71190400001)(33656002)(66476007)(71200400001)(26005)(316002)(73956011)(14444005)(186003)(256004)(6506007)(3846002)(81156014)(74316002)(81166006)(8676002)(305945005)(8936002)(229853002)(2906002)(54906003)(53546011)(52536014)(6116002)(7736002)(6436002)(11346002)(14454004)(476003)(486006)(6306002)(99286004)(110136005)(86362001)(4326008)(478600001)(68736007)(66066001)(53936002)(446003)(20673002); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2282; 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: 7XMkUM5ernu+fdJ+sBtiUoBT5QrckEtK4CTg8mxL/wXqVtKeJ5u199Y0U+PdgkK2cq+mbcpKpQmA2ZpY7WDsAy/sy4K8ear1zHh+9FnQXP2K9LzKLM59i76EeL8aBkoWDe8Hi3gm/U6oGZnQD79bX5iLI0ULDQg01oY4Ji046HU9YJ0VZ4XyDBwJrVeVbrn799TXpZnQ1f8/Zu435apNDAil5aEsrCpOGAvtD6yImwztbB/pBzrFMGXXiT12swvAV38qLVF8sWHAmmxAninIUb/ADAoax2dD85FKQVi/qF/dqxAKnz0svNuUJO8OfxnYN2mgRZO8UX01xtYGuWkxYx+/jHr24jCfqf8mEXvk0e7/aorsop9ewDWzlp4m9v75i6iSwB5CNnHz7zrfX/ZMmcRrcFjryX44HSNklQm7tNw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 12f47f1d-d915-48ae-e034-08d6f5935cd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 15:24:18.5377 (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: LNXP123MB2282
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Report: 5 Rules triggered * 0.1 -- GEN_SPAM_FEATRE * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6573
X-NAI-Spam-Version: 2.2.0.9309 : core <6573> : inlines <7107> : streams <1825047> : uri <2858233>
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/s_0pEQ8PTHKePQZ8FKxeh5cLLQo>
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: Thu, 20 Jun 2019 15:24:28 -0000

Christoph,
Do other people think it's an important requirement to have graceful close of a subflow? (ie something better than sending TCP_RST on the subflow)

(If we do, then I guess we can discuss variety of possible mechanisms)

Thanks
Phil

Ps Sorry, I missed this one.

-----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