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

[Madhan Raj Kanagarathinam <[e-mail]>]

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 : [e-mail] <[e-mail]>

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:[e-mail]] On Behalf Of Christoph Paasch
Sent: 20 May 2019 14:50
To: Olivier Bonaventure <[e-mail]>
Cc: [e-mail]; Ashutosh prakash <[e-mail]>; Nagesh shamnur <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp