IETF Logo Mail Archive

[multipathtcp] Regarding rate control at a subflow level

Nagesh shamnur <nagesh.shamnur@huawei.com> Fri, 17 May 2019 02:37 UTC

Return-Path: <nagesh.shamnur@huawei.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 0255712033D for <multipathtcp@ietfa.amsl.com>; Thu, 16 May 2019 19:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0w8RynhzDDZZ for <multipathtcp@ietfa.amsl.com>; Thu, 16 May 2019 19:37:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4501200A1 for <multipathtcp@ietf.org>; Thu, 16 May 2019 19:37:16 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8C7B18B35B9A9CBD086C for <multipathtcp@ietf.org>; Fri, 17 May 2019 03:37:13 +0100 (IST)
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 17 May 2019 03:37:13 +0100
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 17 May 2019 03:37:12 +0100
Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 17 May 2019 03:37:12 +0100
Received: from DGGEMA524-MBX.china.huawei.com ([169.254.7.71]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0415.000; Fri, 17 May 2019 10:37:02 +0800
From: Nagesh shamnur <nagesh.shamnur@huawei.com>
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
CC: Ashutosh prakash <ashutosh.prakash@huawei.com>
Thread-Topic: Regarding rate control at a subflow level
Thread-Index: AdUMWULM15YYbMauQ2OybE7pkHW5IQ==
Date: Fri, 17 May 2019 02:37:01 +0000
Message-ID: <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.156.80]
Content-Type: multipart/alternative; boundary="_000_4AC96705FB868F42B2075BA50F806DEB56995EF6dggema524mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/c2V_ceeM1RYAxNwbC-3WdgmgHxo>
Subject: [multipathtcp] 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: Fri, 17 May 2019 02:37:18 -0000

Dear MPTCP Group,
                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. 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.
                Any thoughts?

Regards,
Nagesh S

v2.23.0 | Report a Bug | By Email