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

<philip.eardley@bt.com> Tue, 18 June 2019 10:15 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 B02ED120412 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Jun 2019 03:15:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 lNjR_fxzCBYo for <multipathtcp@ietfa.amsl.com>; Tue, 18 Jun 2019 03:14:59 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E2A120100 for <multipathtcp@ietf.org>; Tue, 18 Jun 2019 03:14:58 -0700 (PDT)
Received: from tpw09926dag08h.domain1.systemhost.net (10.9.202.47) by BWP09926085.bt.com (10.36.82.116) 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 11:14:37 +0100
Received: from tpw09926dag09f.domain1.systemhost.net (10.9.202.40) by tpw09926dag08h.domain1.systemhost.net (10.9.202.47) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 11:14:54 +0100
Received: from bwp09926076.bt.com (10.36.82.107) by tpw09926dag09f.domain1.systemhost.net (10.9.202.40) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 18 Jun 2019 11:14:54 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.52) by smtpe1.intersmtp.com (10.36.82.107) 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 11:14:51 +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=RMSBKVxclKMTZMeRwc4W2ddAqT3rr3xelKDPXnMEbww=; b=jUMB/gRhFpYKiXOMNtt3ZmNgDNsLOQPlF4qCUBShwJcRBnCAs26AoHz8RVNjNuPxhvr3WGuvphXfJZyBNAvGLjkN0ukCVZswDhF+2wjtKEtFA2B1tJEucPyOyU/hIkxqk8rZ2v2P/+z5YBtW1+sCNMDCLQxyJAaAq3+SRt2rYwY=
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1900.GBRP123.PROD.OUTLOOK.COM (20.179.130.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.10; Tue, 18 Jun 2019 10:14:53 +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 10:14:53 +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: AdUMWULM15YYbMauQ2OybE7pkHW5IQAPgMiAAJ7rTAAFqepBoA==
Date: Tue, 18 Jun 2019 10:14:53 +0000
Message-ID: <LNXP123MB2587F15363C6152D573B5471EBEA0@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: 602120e9-5f35-4dde-9ea7-08d6f3d5ce86
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1900;
x-ms-traffictypediagnostic: LNXP123MB1900:
x-antispam-2: 1
x-microsoft-antispam-prvs: <LNXP123MB1900801D0F1334961787276BEBEA0@LNXP123MB1900.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 007271867D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39860400002)(396003)(136003)(189003)(199004)(33656002)(256004)(4326008)(99286004)(81166006)(476003)(8676002)(6436002)(6506007)(71200400001)(102836004)(71190400001)(81156014)(25786009)(66066001)(76176011)(229853002)(14444005)(5660300002)(8936002)(26005)(74316002)(305945005)(52536014)(316002)(86362001)(3846002)(64756008)(446003)(53936002)(11346002)(54906003)(76116006)(73956011)(68736007)(6246003)(66946007)(478600001)(66556008)(66476007)(55016002)(2906002)(9686003)(7736002)(186003)(14454004)(6116002)(486006)(7696005)(110136005)(66446008)(20673002); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1900; 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: mHYhISVay/FjMwqaCc+zjy7R5WidPeCoGFDWUCAFYdUh9bCXscgklZtyJhBPWtrFjyy7PoEMhL0ScnC3zJW61kgi52NAZ/3By9PEVRNAQzWMmHM1QI5EnMw9b6nPHJpmUzTpY1uyoY7NLXtFvmY1QSta5hKQDfq2/cme4wJYsYzFudrKAFu+2UcoBfnxxTut5BmgzrFS/B2SLDH80vwvoih1fulfrtHCp/BB5VakzTjMDOLKHkAUHPU3e8aYRY7B/bbELmFoDAU74AUQLztCgHG1MwYU2xsGtYLw2wg6+COVL7V4oKSrs1perFxnxpQNrWtBGcM4kkSN0LdvqRMCCMbegaFjzFdeYXuuAOGWOHJro7qFi2p+pUcwZ6Q6H1wbR8Eg0y4BYru/sAU5hjL7uKXBFiwKgRFDviM/w3DQs2E=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 602120e9-5f35-4dde-9ea7-08d6f3d5ce86
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2019 10:14:53.6447 (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: LNXP123MB1900
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 -- RV6570
X-NAI-Spam-Version: 2.2.0.9309 : core <6570> : inlines <7107> : streams <1824836> : uri <2857347>
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/vNdv5CmD_72eMVPEzV4SzIUvrq8>
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 10:15:03 -0000

Christoph, 
Coming back to your comment:

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

Can you explain the 3rd bullet please? I think "none" must be a typo (I assume for 'one' / you)
Not sure I get why the approach in the bis document doesn’t work? Surely if I set the B flag on a subflow then traffic is no longer sent on it, even if the other subflow is dropping a lot of packets? (but presumably this case would mean that the packet rate dropped a lot). 

<<
Another use of the MP_PRIO option is to set the 'B' flag on a subflow
   to cleanly retire its use before closing it and removing it with
   REMOVE_ADDR Section 3.4.2, for example to support make-before-break
   session continuity, where new subflows are added before the
   previously used ones are closed.
>>

Thanks
phil