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

<> Tue, 18 June 2019 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B02ED120412 for <>; Tue, 18 Jun 2019 03:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lNjR_fxzCBYo for <>; Tue, 18 Jun 2019 03:14:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25E2A120100 for <>; Tue, 18 Jun 2019 03:14:58 -0700 (PDT)
Received: from ( by ( 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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 11:14:54 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 18 Jun 2019 11:14:54 +0100
Received: from ( by ( 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;; 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 ( by LNXP123MB1900.GBRP123.PROD.OUTLOOK.COM ( 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
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: <> <> <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
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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 ( 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-Transport-CrossTenantHeadersStamped: LNXP123MB1900
X-NAI-Spam-Flag: NO
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: : core <6570> : inlines <7107> : streams <1824836> : uri <2857347>
Archived-At: <>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jun 2019 10:15:03 -0000

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.


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.