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

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

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

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

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
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp" rel="nofollow">https://www.ietf.org/mailman/listinfo/multipathtcp

_______________________________________________
multipathtcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp