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

From: <[email-masked]>
Date: Wed, 10 Jul 2019 16:14:10 +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)

S3.2
" 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. 

Thanks,
phil

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Viet Hoang Tran
Sent: 09 July 2019 10:05
To: multipathtcp <[email-masked]>
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.
Thanks,

Hoang & Olivier

________________________________________
From: [email-masked] <[email-masked]>
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

Abstract:
   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
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 10 Jul 2019 16:24:48 +0000

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

This is a very first step to initiate some discussion. Hoang has a 
prototype implementation that works on Linux.

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

This is another possible approach that probably does not require any 
IETF work. The client could use a token bucket configured at the planned 
rate on the monitored interface and mark the packets that are outside 
this rate with the CE bit. The server would then adjust its transmission 
rate based on the ECN feedback. There would obvisouly be some delay 
between the marking and the reaction of the server and this would 
require ECN support on the hosts (not on the routers inside the network)

> - how could the capping limit apply to all MPTCP traffic sent to the mobile client (ie many connections, potentially with many servers)?

The solution SRL would not apply in this case.

> - reflect user preferences (eg for this app at this moment I'm prepared to use up more of my mobile data)

We could consider changing the SRL during the lifetime of a connection

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

Then you'd argue for middleboxes to either inform hosts or worse inject 
MPTCP options

> - potentially reflect knowledge /preferences about relative costs (eg satellite is much more expensive than wired DSL. I guess this info is reasonably static)

Should be stored on the client

> - mobile client requests server to prefer low latency subflow

This is another metric which could be exchanged

> - work in the case with a proxy (converter)

A converter would behave as an MPTCP server

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

The main question is whether you want a solution that operates on a per 
subflow basis or on a per interface basis on the client for long downloads.

> Does this maximum rate applies to both directions? Can you clarify the text please.

No, we use it to cap the window of the sender. The receiver indicates 
the maximum through that the sender can send over this subflows

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

That's a possibility. Madhan suggested to include a HMAC in the SRL 
option, which could protect some scenarios, but I agree that this could 
open new security details.

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

It would be possible to add a time in seconds in the option to indicate 
for how many seconds the limit applies.

Olivier