Subject: Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10

From: Nagesh shamnur <[email-masked]>
Date: Fri, 12 Jul 2019 13:14:44 +0000

Hi Med,
	I have a question regarding this point " 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)." MP_PRIO option with 'b' bit can be used to achieve the same,  then why need new option?

Regards,
Nagesh S

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 12 July 2019 17:18
To: [email-masked]
Subject: multipathtcp Digest, Vol 125, Issue 10

Send multipathtcp mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/multipathtcp
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of multipathtcp digest..."

Today's Topics:

   1. Re: Fw: New Version Notification for
      draft-hoang-mptcp-sub-rate-limit-00.txt ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Jul 2019 11:47:28 +0000
From: <[email-masked]>
To: Viet Hoang Tran <[email-masked]>, multipathtcp
	<[email-masked]>
Subject: Re: [multipathtcp] Fw: New Version Notification for
	draft-hoang-mptcp-sub-rate-limit-00.txt
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="utf-8"

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

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

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

[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNzA5MTY0MDM2ZXBjbXM1cDQ3YzY2MzJiNTM3MmQ0MDliYjI2YTMwMGNlYTMzYmUzZSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/20190712/1e2caade/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 33527 bytes
Desc: image001.png
URL: <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/20190712/1e2caade/attachment.png>

------------------------------

Subject: Digest Footer

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

------------------------------

End of multipathtcp Digest, Vol 125, Issue 10
*********************************************

---

From: <[email-masked]>
Date: Mon, 15 Jul 2019 05:28:27 +0000

Hi Nagesh, 

The subtlety here is that this case is not a backup one that can be managed with the current definition of b-bit (see the discussion with Olivier). 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Nagesh shamnur
> Envoyé : vendredi 12 juillet 2019 15:15
> À : [email-masked]
> Objet : Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10
> 
> Hi Med,
> 	I have a question regarding this point " 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)." MP_PRIO option with 'b'
> bit can be used to achieve the same,  then why need new option?
> 
> Regards,
> Nagesh S
> 
> ([email-masked])
> 
> 
> 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).
> 
> [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.r
> aj&do=bWFpbElEPTIwMTkwNzA5MTY0MDM2ZXBjbXM1cDQ3YzY2MzJiNTM3MmQ0MDliYjI2YTMw
> MGNlYTMzYmUzZSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__]
> URL:
> <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/2019071
> 2/1e2caade/attachment.html>
> URL:
> <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/2019071
> 2/1e2caade/attachment.png>
>