[multipathtcp] Comments on "Multipath TCP Subflow Rate Limit Option"

<philip.eardley@bt.com> Wed, 10 July 2019 16: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 2716F120026 for <multipathtcp@ietfa.amsl.com>; Wed, 10 Jul 2019 09:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RH87b117fI57 for <multipathtcp@ietfa.amsl.com>; Wed, 10 Jul 2019 09:15:23 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCE412019D for <multipathtcp@ietf.org>; Wed, 10 Jul 2019 09:15:18 -0700 (PDT)
Received: from tpw09926dag12f.domain1.systemhost.net ( by BWP09926084.bt.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 10 Jul 2019 17:14:50 +0100
Received: from tpw09926dag18h.domain1.systemhost.net ( by tpw09926dag12f.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 17:14:11 +0100
Received: from bwp09926082.bt.com ( by tpw09926dag18h.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 10 Jul 2019 17:14:11 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com ( by smtpe1.intersmtp.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 10 Jul 2019 17:14:10 +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=corq8GfEaC0LjEYWitmpa3NNidjgNrtadtDEfk0VYrc=; b=RypOpkPx1XlUQ4aGwYTQag8Uq/d2Nz6ty9lKVNQeBHiMm4iT0wL/M670d5Vg+6tlwPwEmBrHteGgKh9rqlGqteHBzuVVhoUCxHGiUkQ4GB4/CAncTSpwhxC0bv8XwmdQwZilg+4Kq8703OQgf7BhhqefXe9Nl96sbUmGbRkHIR0=
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ( by LNXP123MB2425.GBRP123.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Wed, 10 Jul 2019 16:14:10 +0000
Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2052.020; Wed, 10 Jul 2019 16:14:10 +0000
From: <philip.eardley@bt.com>
To: <hoang.tran@uclouvain.be>, <multipathtcp@ietf.org>
Thread-Topic: Comments on "Multipath TCP Subflow Rate Limit Option"
Thread-Index: AdU2/8vSPos2fqteTbOgM2LaoDzklg==
Date: Wed, 10 Jul 2019 16:14:10 +0000
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com;
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dfb76223-61ed-4b9b-ddcb-08d70551a448
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2425;
x-ms-traffictypediagnostic: LNXP123MB2425:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <LNXP123MB2425962CC0E0EF698AF14E12EBF00@LNXP123MB2425.GBRP123.PROD.OUTLOOK.COM>
x-antispam-2: 1
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0094E3478A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(189003)(199004)(51914003)(13464003)(66066001)(476003)(52536014)(486006)(81166006)(6116002)(110136005)(305945005)(68736007)(966005)(6506007)(8676002)(81156014)(86362001)(66574012)(53546011)(102836004)(478600001)(99286004)(3846002)(5660300002)(7696005)(25786009)(71200400001)(6306002)(55016002)(256004)(76116006)(53936002)(74316002)(2906002)(71190400001)(66446008)(64756008)(66556008)(6436002)(66946007)(14444005)(9686003)(66476007)(8936002)(561944003)(7736002)(186003)(316002)(33656002)(26005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2425; 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: Dxe0ze+40p8eiJ7zvvog1428kr4B2NPbX2iDb4oC8rsJvQm/imdSx0SrD02QQzKGUrl+xyx7M2Q/1z4c0vfitEKfulFamxnYU7i1IDwGJ+eyKAJ3NNu7MrgzQ7qsQ5cYwPX8D3d1EhHHc9EtlYK5o4e9g4kgg8RJcrCpNAVT2WnwmVtpK/byGDLPKe7OMV4zw4BXAJ1Azz9SJgZ7Cfc7qv9ERg3tamISMARD8QLO4Cb6zESJHU3wbbrNK4BcYSPpjJqDh6ZRZWfF6F1jZ2V9mkPLQZBOdkpX4s7rDHS122WJUiKKj1t7UaXwKNnZfGV7uVONt2Hegxa1wVWFIdvRDdSiGQ5K9yuOtKRd7sBUWByCsM9oqaZOW2jDkd4+a4xWWCr+z9p/G+lrypqss2HjUI4b2uDgKjadMhINbdHXTd0=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dfb76223-61ed-4b9b-ddcb-08d70551a448
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 16:14:10.1853 (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: LNXP123MB2425
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Report: 3 Rules triggered * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6587
X-NAI-Spam-Version: : core <6587> : inlines <7116> : streams <1826960> : uri <2865996>
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/yJs2jcJ3rEMsLFa87PRQrfDBWOo>
Subject: [multipathtcp] Comments on "Multipath TCP Subflow Rate Limit Option"
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: Wed, 10 Jul 2019 16:15:28 -0000

Hoang & Olivier,

Thanks for the very interesting proposal https://datatracker.ietf.org/doc/html/draft-hoang-mptcp-sub-rate-limit (I haven't read your other draft yet)

Section 1 Introduction
<< mobile users want to limit the monetary cost of
   using cellular networks or to avoid running out of their mobile data
   quota.  Smartphones can easily rate limit their upstream bandwidth,
   but unfortunately, most smartphone applications mainly receive data.
   For these applications, a rate limit must happen on the server side.
   This rate limit could be enforced by the application, e.g. by
   selecting a specific video coding scheme, but applying it at the
   transport layer would be more generic and could be done from the
   system level automatically.
I agree with your statement about (one) problem. 
What I'm not sure about is whether a "Subflow Rate Limit" is the best way of solving the problem. We should do some analysis compared with other options and suggestions, in case they're simpler /have wider applicability.
In the analysis we should include the basic approach of ECN marking (or dropping) packets to reduce the sending rate (and the disadvantages of doing that - eg reduce connection window) 

I'd also have on my list of nice-to-meet requirements something that would offer more flexibility that a simple limit on bitrate, for instance:-
- how could the capping limit apply to all MPTCP traffic sent to the mobile client (ie many connections, potentially with many servers)?
- reflect user preferences (eg for this app at this moment I'm prepared to use up more of my mobile data)
- potentially reflect operator preferences /knowledge (eg at the moment the DSL has a low throughput so operator needs to allow more to be sent on the mobile interface, in order to hit a 20Mbps target contractual rate) 
- potentially reflect knowledge /preferences about relative costs (eg satellite is much more expensive than wired DSL. I guess this info is reasonably static)
- mobile client requests server to prefer low latency subflow
- work in the case with a proxy (converter)

Is there a mechanism or combination of mechanisms (Sub Rate Limit and others) that can meet these goals? Would a "preference indicator" be useful? (ie something which is sent more frequently and has a shorter-term & finer-grained impact than SRL)

" Note that the SRL option is an indicative value.  Upon reception of
   this option, the receiver SHOULD set the maximum rate on the subflow
   over which the option was received."
Does this maximum rate applies to both directions? Can you clarify the text please. 

S5 Security Considerations
"However, manipulating this
   option doing not open new attacks compared to the ones documented in
   [RFC6181] [RFC7430]."
I'm not convinced this is true. For instance, if the attacker declares a Subflow Rate Limit of close to 0 and a very large Subflow Rate Limit on the other path of the same connection, I don't think this is the same as an attacker that drops packets on one path. The latter attack would slow down the total traffic rate, the former may not. Also, the latter attack is something the attacker has to continue to do, whilst the former involves sending a single message only (at least it seems that the impact of the SRL msg lasts for the lifetime of the connection, or until another SRL option is sent). 

Actually, you could make some comment about how long the SRL option is expected to have an impact. 


-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Viet Hoang Tran
Sent: 09 July 2019 10:05
To: multipathtcp <multipathtcp@ietf.org>
Subject: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

We submitted two drafts on  Subflow Rate Limit Option and  Inactivity Time Option (https://tools.ietf.org/html/draft-hoang-mptcp-inactivity-time-00)

Feedbacks and suggestions are more than welcomed.

Hoang & Olivier

From: internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Monday, 8 July 2019 16:28
To: Viet Hoang Tran; Olivier Bonaventure; Olivier Bonaventure
Subject: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

A new version of I-D, draft-hoang-mptcp-sub-rate-limit-00.txt
has been successfully submitted by Viet-Hoang Tran and posted to the IETF repository.

Name:           draft-hoang-mptcp-sub-rate-limit
Revision:       00
Title:          Multipath TCP Subflow Rate Limit Option
Document date:  2019-07-08
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-hoang-mptcp-sub-rate-limit-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hoang-mptcp-sub-rate-limit/
Htmlized:       https://tools.ietf.org/html/draft-hoang-mptcp-sub-rate-limit-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hoang-mptcp-sub-rate-limit

   This document defines a new MPTCP Option that enables hosts to
   request their peers to limit the maximum transfer rate on a per-
   subflow basis.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

multipathtcp mailing list