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

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Fri, 21 June 2019 09:06 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 499491201CB for <multipathtcp@ietfa.amsl.com>; Fri, 21 Jun 2019 02:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.286
X-Spam-Level:
X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[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=unavailable 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 yfcM98lq-lXv for <multipathtcp@ietfa.amsl.com>; Fri, 21 Jun 2019 02:06:44 -0700 (PDT)
Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C076E120052 for <multipathtcp@ietf.org>; Fri, 21 Jun 2019 02:06:43 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20190621090640epoutp02eb7d4f2af267f68af7c2cf7c519508da~qK3SfmZiO0293302933epoutp02A for <multipathtcp@ietf.org>; Fri, 21 Jun 2019 09:06:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20190621090640epoutp02eb7d4f2af267f68af7c2cf7c519508da~qK3SfmZiO0293302933epoutp02A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1561108000; bh=qMqKSgL09b9Ak5ohFa3xi0t7m4eCg8M9By8lMZKcU5I=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=sT8eiuXwZrZCQCJrXFmbjAZ/mCmlzEr55C3rTUW3CvoVTeKir1YnMC86yMRVUvlVs pAxfGnb31cx+CoSApZa6OCr5sy37OqBWAKdqm8B76yukuKvGdJsyue6aLoGyELVbbO m4PcCP3Vpy2rEet4MVaaItl6czGwOaX9cDbQGZEM=
Received: from epsmges5p3new.samsung.com (unknown [182.195.42.75]) by epcas5p4.samsung.com (KnoxPortal) with ESMTP id 20190621090640epcas5p42fe4522273fdaf6435af082bb78ce212~qK3SG344H1621516215epcas5p4u; Fri, 21 Jun 2019 09:06:40 +0000 (GMT)
X-AuditID: b6c32a4b-78bff70000000fe3-17-5d0c9e2000d7
Received: from epcas5p1.samsung.com ( [182.195.41.39]) by epsmges5p3new.samsung.com (Symantec Messaging Gateway) with SMTP id 1C.71.04067.02E9C0D5; Fri, 21 Jun 2019 18:06:40 +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: "philip.eardley@bt.com" <philip.eardley@bt.com>, "cpaasch=40apple.com@dmarc.ietf.org" <cpaasch=40apple.com@dmarc.ietf.org>, "olivier.bonaventure@uclouvain.be" <olivier.bonaventure@uclouvain.be>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <LNXP123MB25872FB755F07346E3C7D9E9EBE40@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20190621090639epcms5p4412755578ee860c538f8f8be6f448506@epcms5p4>
Date: Fri, 21 Jun 2019 14:36:39 +0530
X-CMS-MailID: 20190621090639epcms5p4412755578ee860c538f8f8be6f448506
Content-Type: multipart/related; boundary="----qCNu4ryIZkz55TLTxA_Lidd3rDUo6HQwgC.m0y2-UB4.tSS.=_47099_"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsWy7bCmuq7CPJ5Yg0U7+S027jvCZvF59XU2 ixsNP1gslq1dwejA4tH2ZTKTx4llV1g9liz5yeTx6th3lgCWKC6blNSczLLUIn27BK6MY33r WAuOz2auWNmwlbWB8c0E5i5GTg4JAROJzd8XgdlCArsZJebN9Ohi5ODgFRCU+LtDGCQsLOAh MXnLZEaIEgWJvVd2MkHErST6Z99kBbHZBCwkFm7eBhTn4hAROMkoceD2T7AEs4CxxMOnHewQ u3glZrQ/ZYGwpSW2L98KNpRTIEZi0rXVUPeIStxc/ZYdxn5/bD4jhC0i0XrvLFSNoMSDn7sZ Qe6UEJCSuLWBG2SvhMBsRomjyx6zQDibGSUaL/ezQTSYSyz7MQ3M5hXwldj56BnYIBYBVYnT i85BDXWR+LaoEeroLIlJB++yQNh8Er2/nzDBPLBjHoytIrF0zmGoXimJ/093QR3tIfF/ziNm kCOEBK4ySVw68p11AqPcLESgzkKyAsLWkGidM5cdwlaUmNL9EMq2kZh9/RgLpriqxK8DS1gX MLKvYpRMLSjOTU8tNi0wzkst1ytOzC0uzUvXS87P3cQITj1a3jsYN53zOcQowMGoxMN7YBZ3 rBBrYllxZe4hRhWgWY82rL7AKMWSl5+XqiTCy5PDEyvEm5JYWZValB9fVJqTWnyIUZqDRUmc dxLr1RghgfTEktTs1NSC1CKYLBMHp1QDY3nFp+aG4B/xz/wPrpXkX/dQoX1iV0h9zctkdqNF ByqOm5zmET2y/d8eWzb9xndrVZwsQ1eHyfvcXe+8Kljm59nV1QfP6nB/dKspUShR0V6UveGi +YxZ5vvv2Mxt9uOUdj9vE/f14s4eEf7/uz7cjOFmXsrIaf992m5x69WNdpO+r5KbwMz1S4ml OCPRUIu5qDgRAChfPTRFAwAA
X-CMS-RootMailID: 20190620152441epcas2p2a9a0e02ecaf4b48e0b5d725130c130ac
References: <LNXP123MB25872FB755F07346E3C7D9E9EBE40@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <20190520135014.GG41806@MacBook-Pro-64.local> <CGME20190620152441epcas2p2a9a0e02ecaf4b48e0b5d725130c130ac@epcms5p4>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/2vhY1Zy6z--bBNCx27puxZsal5o>
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: Fri, 21 Jun 2019 09:06:49 -0000

Do other people think it's an important requirement to have graceful close of a subflow? (ie something better than sending TCP_RST on the subflow)

>> Its important for Smartphones for power saving in idle time (screen off).

 

 

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

Sender : philip.eardley@bt.com <philip.eardley@bt.com>

Date : 2019-06-20 20:54 (GMT+5:30)

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

 

Christoph,
Do other people think it's an important requirement to have graceful close of a subflow? (ie something better than sending TCP_RST on the subflow)

(If we do, then I guess we can discuss variety of possible mechanisms)

Thanks
Phil

Ps Sorry, I missed this one.

-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch
Sent: 20 May 2019 14:50
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>;
Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>;; Nagesh shamnur <nagesh.shamnur@huawei.com>;
Subject: Re: [multipathtcp] Regarding rate control at a subflow level

Hello,

On 17/05/19 - 09:59:54, Olivier Bonaventure wrote:
> 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 ?

another use-case for rate-control I see is when a client wants to tell a sender to gracefully close a subflow.

- Sending a TCP-RST results in packet-loss of the in-flight data.
- Reducing the window is going to stall the whole connection because the window is shared.
- Setting MP_PRIO also won't work because none might want to drain a secondary
  subflow even if the "primary" subflow is having severe packet-loss.

Thus, a "maximum-rate" option on a per-subflow level would allow to send the rate to 0, which would drain the subflow.


Christoph

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
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=bWFpbElEPTIwMTkwNjIxMDkwNjM5ZXBjbXM1cDQ0MTI3NTU1NzhlZTg2MGM1MzhmOGY4YmU2ZjQ0ODUwNiZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__" border="0" width="0" height="0">