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

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: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.
Thanks,

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

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
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp