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

Madhan Raj Kanagarathinam <> Fri, 21 June 2019 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 499491201CB for <>; Fri, 21 Jun 2019 02:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.286
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yfcM98lq-lXv for <>; Fri, 21 Jun 2019 02:06:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C076E120052 for <>; Fri, 21 Jun 2019 02:06:43 -0700 (PDT)
Received: from (unknown []) by (KnoxPortal) with ESMTP id 20190621090640epoutp02eb7d4f2af267f68af7c2cf7c519508da~qK3SfmZiO0293302933epoutp02A for <>; Fri, 21 Jun 2019 09:06:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 20190621090640epoutp02eb7d4f2af267f68af7c2cf7c519508da~qK3SfmZiO0293302933epoutp02A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (unknown []) by (KnoxPortal) with ESMTP id 20190621090640epcas5p42fe4522273fdaf6435af082bb78ce212~qK3SG344H1621516215epcas5p4u; Fri, 21 Jun 2019 09:06:40 +0000 (GMT)
X-AuditID: b6c32a4b-78bff70000000fe3-17-5d0c9e2000d7
Received: from ( []) by (Symantec Messaging Gateway) with SMTP id 1C.71.04067.02E9C0D5; Fri, 21 Jun 2019 18:06:40 +0900 (KST)
Mime-Version: 1.0
Sender: Madhan Raj Kanagarathinam <>
From: Madhan Raj Kanagarathinam <>
To: "" <>, "" <>, "" <>
CC: "" <>
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-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_"
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> <> <> <20190520135014.GG41806@MacBook-Pro-64.local> <CGME20190620152441epcas2p2a9a0e02ecaf4b48e0b5d725130c130ac@epcms5p4>
Archived-At: <>
Subject: Re: [multipathtcp] (2) Regarding rate control at a subflow level
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 : <>

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

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


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)


Ps Sorry, I missed this one.

-----Original Message-----
From: multipathtcp [] On Behalf Of Christoph Paasch
Sent: 20 May 2019 14:50
To: Olivier Bonaventure <>
Cc:; Ashutosh prakash <>; Nagesh shamnur <>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level


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.


multipathtcp mailing list
multipathtcp mailing list" border="0" width="0" height="0">