Re: [multipathtcp] (2) Regarding rate control at a subflow level

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Mon, 20 May 2019 06:26 UTC

Return-Path: <madhan.raj@samsung.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F29120132 for <multipathtcp@ietfa.amsl.com>; Sun, 19 May 2019 23:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.784
X-Spam-Level:
X-Spam-Status: No, score=-4.784 tagged_above=-999 required=5 tests=[BASE64_LENGTH_79_INF=1.502, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samsung.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x174mUbqUDWz for <multipathtcp@ietfa.amsl.com>; Sun, 19 May 2019 23:26:38 -0700 (PDT)
Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154971200CC for <multipathtcp@ietf.org>; Sun, 19 May 2019 23:26:37 -0700 (PDT)
Received: from epcas5p3.samsung.com (unknown [182.195.41.41]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20190520062635epoutp048fc0e75b0f53e8b3041602f8f00c2c56~gUCX821GV1071110711epoutp04X for <multipathtcp@ietf.org>; Mon, 20 May 2019 06:26:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20190520062635epoutp048fc0e75b0f53e8b3041602f8f00c2c56~gUCX821GV1071110711epoutp04X
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1558333595; bh=kuYKysBtjktV1GE06ehDWd9J5VxYUJt2dQc/Xip5N+M=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=N4fDLxGGoETcWQ0uZejKwokDoxuOXyUg3Wqkvfoi62X9Wnev9zW/zZoZIDH5cD/G2 Iu7xUUUQI7G8Gb4rUVHjMw0qMiv6kHECyEfIiGTmbDkDkjkSQMZUE+lYrelt+EBVAU wRuGAgwa3LQOcWX7CsxA64PTLf1AS9IKjdp592KI=
Received: from epsmges5p3new.samsung.com (unknown [182.195.42.75]) by epcas5p4.samsung.com (KnoxPortal) with ESMTP id 20190520062634epcas5p4e6b44b9cc651dff46dfb53bebe45e899~gUCXsQRJz0197801978epcas5p48; Mon, 20 May 2019 06:26:34 +0000 (GMT)
X-AuditID: b6c32a4b-78bff70000000fe3-bb-5ce2489a4f1b
Received: from epcas5p4.samsung.com ( [182.195.41.42]) by epsmges5p3new.samsung.com (Symantec Messaging Gateway) with SMTP id 82.C9.04067.A9842EC5; Mon, 20 May 2019 15:26:34 +0900 (KST)
Mime-Version: 1.0
Reply-To: madhan.raj@samsung.com
Sender: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
From: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
To: Nagesh shamnur <nagesh.shamnur@huawei.com>
CC: =?UTF-8?B?QWxleGFuZGVyIEZyw7ZtbWdlbg==?= <Alexander@froemmgen.de>, Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>, Ashutosh prakash <ashutosh.prakash@huawei.com>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20190520062634epcms5p1578632bf8a791eefe970bb7678e96625@epcms5p1>
Date: Mon, 20 May 2019 11:56:34 +0530
X-CMS-MailID: 20190520062634epcms5p1578632bf8a791eefe970bb7678e96625
Content-Type: multipart/related; boundary="----A7-x9CE59QCrcSgqtOiajmZLGCydb42Lb.hnBVsLL39ZVrmn=_4703_"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsWy7bCmlu4sj0cxBqtfGVks2HqW2eLHLWmL z6uvs1nMe3GJ1eJGww8WB1aPexu6mD1ajrxl9Viy5CeTx6tj31kCWKK4bFJSczLLUov07RK4 MtpbTzAWnDnOWNE36zN7A+P+o4xdjJwcEgImEj+72pi6GLk4hAR2M0pcmdjI3sXIwcErICjx d4cwSI2wgIfE5C2TweqFBBQk9l7ZyQQRt5Lon32TFcRmE7CQWLh5G1hcREBPYm5fGyPITGaB J4wSyztOM0Ms45WY0f6UBcKWlti+fCvYUE4BB4nmS21QcVGJm6vfssPY74/NhzpURKL13lmo OYISD37uhorLSNye+oIFZJmEwGxGiaPLHkM5mxklGi/3s0FUmUss+zGNDeIzX4kpW3hAwiwC qhJ72ycwQZS4SGzYtw2snFkgU+Ly+z1MEDafRO/vJ0wwD+yYB2OrSCydcxjqICmJ/093QR3t IfHx1VY2SIh2Mknc+7KQZQKj3CxEoM5CsgLC1pBonTOXHcJWlJjS/RDKFpfYf6WNGVNcXeLU niXMCxjZVzFKphYU56anFpsWGOellusVJ+YWl+al6yXn525iBCchLe8djJvO+RxiFOBgVOLh 9Zj+MEaINbGsuDL3EKMEB7OSCK+x+v0YId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryTWK/GCAmk J5akZqemFqQWwWSZODilGhiLZaZvybIu8qnpdn340yaktPtLwpmn9ZmLWmrqVh0wPmflXGRa 5BAfpBbxlttnS/1OjUcyalmrKjo1xJYZmahffLjy6LbnAo1n2Y95lXUGz0zdt2DtoU0LJbK2 7MkRNHx0qGm3WcvHtRURWT/4ipNeWkRYZmxY8mdH+AuLZTOypk8Rm/he/qESS3FGoqEWc1Fx IgA1BX62PgMAAA==
X-CMS-RootMailID: 20190518191703epcas1p24eaa19af192057d9f2808cbd49fa7aab
References: <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de> <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <CGME20190518191703epcas1p24eaa19af192057d9f2808cbd49fa7aab@epcms5p1>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/ntrlIr8tjGD94ZpPHvRWQNZB_Is>
Subject: Re: [multipathtcp] (2) Regarding rate control at a subflow level
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 06:26:41 -0000

Dear Nagesh,

 

So, while going through the discussion archives, could
only find that, the peer(server) can throttle the speed for the entire
connection by publishing a smaller receiver window rather than for a
particular subflow. I feel, it would be a good idea if the peers can
exchange this information using the control packets.

 

>> There are quite some research going on SBR and related areas. But if there has to options exchanged (or control), it has to be secured to protect from mangling. Another challenge is that estimating the bandwidth and frequent changing might also be overhead in wireless.

In my research work, to control the same, we throttle the UE RTT by introducing additional delay and controlling the path manager. There are few methods of ACK throttling as well which might help the same. So I would suggest indirect control instead of direct option exchanged.

 

Regards,

Madhan

 

 

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

Sender : Alexander Frömmgen <Alexander@froemmgen.de>;

Date : 2019-05-19 00:47 (GMT+5:30)

Title : Re: [multipathtcp] Regarding rate control at a subflow level

 

Hi,

We experimented with different schedulers that implement related behaviour, e.g., to only use cellular data if a target throughput can't be provided otherwise and only transfer the fraction of data on the cellular path that is required to achieve the target throughput (which is effectively a kind of dynamic rate limiting). See https://progmp.net" rel="nofollow">https://progmp.net for further information.

Best,

Alexander

Am 17. Mai 2019 11:59:54 MESZ schrieb Olivier Bonaventure <olivier.bonaventure@uclouvain.be>;:
Dear Nagesh,

                Greetings. In case of Mobile deployments of MPTCP,
though the data rates are getting cheaper, still it would be wise not to
run the cellular path to full limit but to throttle to a certain extent
considering cost in mind or if server wants to limit the client at
subflow level, then I couldn’t find the support for the same in the
specification.

We have developed several prototypes that include this capability in the
Linux kernel.

So, while going through the discussion archives, could
only find that, the peer(server) can throttle the speed for the entire
connection by publishing a smaller receiver window rather than for a
particular subflow. I feel, it would be a good idea if the peers can
exchange this information using the control packets.

We could imagine an MPTCP option that provides the maximum rate on a
per-subflow level, but I was wondering whether the use case is not to
limit the bandwidth on the smartphone at the link level (i.e. multiple
tcp connections or udp flows) and not at the subflow level. Could you
precise your use case for the subflow level ?

Thanks


Olivier
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp" rel="nofollow">https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

 


http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNTIwMDYyNjM0ZXBjbXM1cDE1Nzg2MzJiZjhhNzkxZWVmZTk3MGJiNzY3OGU5NjYyNSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__" border="0" width="0" height="0">