Subject: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

From: Viet Hoang Tran <[email-masked]>
Date: Tue, 9 Jul 2019 09:04:48 +0000

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

---

From: Madhan Raj Kanagarathinam <[email-masked]>
Date: Tue, 09 Jul 2019 22:10:36 +0530

Dear Hoang,

>> Subflow Rate Limit Option

How about considering HMAC over the SRL option. Such an option might prone the attackers to throttle the speed.

Though Section 5 discusses about the Security Considerations, throttling to lower value (non zero) might reduce the bandwidth of specific user.

Regards,

Madhan

--------- Original Message ---------

Sender : Viet Hoang Tran <[email-masked]>

Date : 2019-07-09 14:35 (GMT+5:30)

Title : [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

Hoang & Olivier

Abstract:

The IETF Secretariat

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 9 Jul 2019 16:43:24 +0000

Hello,
> How about considering HMAC over the SRL option. Such an option might 
> prone the attackers to throttle the speed.

That's indeed a possibility. We could reuse what has been done for the 
ADD_ADDR option. It would prevent injection of fake information by 
off-path attackers but not by attackers/middleboxes that reside on the 
initial path.

Olivier

---

From: <[email-masked]>
Date: Fri, 12 Jul 2019 11:47:28 +0000

Hi Hoang, all,

Thank you for igniting this work.

FWIW, we used to have this requirement in draft-nam-mptcp-deployment-considerations (with cellular networks in mind):

   “For cases where some access networks are subject to a volume quota,
   it is desirable to support a signal to indicate to a remote peer how
   it must place data into available subflows”.

The rate-limit option as currently defined may not be adequate. I would like an option which allows to tell a remote peer, for example:

·         to use a given subflow only where there is a need to grab more resources (that is, don’t use this subflow if data can be placed on other subflows).

·         “here is my suggested inbound traffic distribution ratio among established subflows”.

·         “here is the maximum data that can be placed in a given subflow”.

Did you consider those schemes?

Cheers,
Med

--------- Original Message ---------

Thanks,

Hoang & Olivier

IETF repository.

Revision:       00

Pages:          6

Abstract:

   subflow basis.

The IETF Secretariat

[email-masked]

[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNzA5MTY0MDM2ZXBjbXM1cDQ3YzY2MzJiNTM3MmQ0MDliYjI2YTMwMGNlYTMzYmUzZSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__]

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 12 Jul 2019 13:00:24 +0000

Med,

> FWIW, we used to have this requirement in 
> draft-nam-mptcp-deployment-considerations (with cellular networks in mind):
> 
> The rate-limit option as currently defined may not be adequate. I would 
> like an option which allows to tell a remote peer, for example:
> 
> ·to use a given subflow only where there is a need to grab more 
> resources (that is, don’t use this subflow if data can be placed on 
> other subflows).

This would be a variation of the backup bit, with a different semantics. 
There are different possible semantics, the current one says:
- don't use the backup subflow unless there is an active one
Other semantics could be:
- don't use the backup subflow as long as the delay on the active one is 
below <250msec (this is roughly what Apple does with Wifi assist)
- don't use the backup subflow as long as the throughput of the active 
one is above 1 Mbps

> ·“here is my suggested inbound traffic distribution ratio among 
> established subflows”.

As a percentage between the different subflows of an existing connection 
? The main difficulty of such an approach is that the number of subflows 
changes over time and client and servers might have a different view on 
the number of subflows that are active. There are many corner cases that 
make this difficult to implement in general.

I think that a rate limit (typically on the cellular interface) covers 
many of these use cases

> ·“here is the maximum data that can be placed in a given subflow”.

In bytes ? We could imagine an option that indicates that a given 
connection can receive up to x MBytes and after that it will be released.

Olivier

---

From: <[email-masked]>
Date: Fri, 12 Jul 2019 14:12:35 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:[email-masked]]
> Envoyé : vendredi 12 juillet 2019 15:00
> À : BOUCADAIR Mohamed TGI/OLN; Viet Hoang Tran; multipathtcp
> Objet : Re: [multipathtcp] Fw: New Version Notification for draft-hoang-
> mptcp-sub-rate-limit-00.txt
> 
> Med,
> 

[Med] Yes, the issue is how to unambiguously identify which semantic is associated with a single bit. For the sake if interoperability, more than one bit is needed to cover these cases. 

> ?

[Med] Yes, typically. 

 The main difficulty of such an approach is that the number of subflows
> make this difficult to implement in general.

[Med] For the hybrid access case or within DCs, the number of subflows is not supposed to change that much. 

> connection can receive up to x MBytes and after that it will be released.

[Med] OK, thanks.