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

[Olivier Bonaventure <[e-mail]>]

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.

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

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)

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

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 target contractual rate)

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 has a shorter-term & finer-grained impact than SRL)

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.

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

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

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

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