Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00

[Viet Hoang Tran <[e-mail]>]

Hi Yoshi,

Thank you for elaborating your question, please find my answer inline.

On 23 Jul 2019, at 15:35, Yoshifumi Nishida <[e-mail]<mailto:[e-mail]>> wrote:

Hi Viet,

Yes, Sorry that I was not clear enough. In my understanding, in order to control the rate for the server, the server needs to cap the window size.
My point was if client adjusts the advertised window size to the server, the transmission rate from the server can be controlled to some extents. (not sure how much, though)
There might be limitations, but I would like to understand how it is feasible for client to control the transmission rate from the server.

Yes, in Linux, the server caps the congestion window using cwnd_clamp (an existing field in tcp_sock)
 whose already has the semantic as the upper limit of effective congestion window.

Adjusting advertised window size on the client side may work for regular TCP.
But I think it won’t work for MPTCP since all MPTCP subflows share the same receive window.
 If the client limits the advertised window, it would affect the total rate of all subflows.
I am also not sure if the receivers are allowed to reduce the receive window with
an amount lower than acked data over that duration.

An alternative client way is dropping packets (or create 3 dup acks as you mentioned),
but the effects are really dependant on which congestion controller the server is using,
which in turn is not in the client’s control.

Thanks,
-
Hoang

Sorry if I overlook something.
--
Yoshi





On Tue, Jul 23, 2019 at 1:17 AM Viet Hoang Tran <[e-mail]<mailto:[e-mail]>> wrote:
Hi Yoshi,

I guess I did not understand your question about the client/server window clamp, and 3 duplicate ACKs.
Would you mind to restate your question?

Thanks!
- Hoang

On 17 Jul 2019, at 08:31, Yoshifumi Nishida <[e-mail]<mailto:[e-mail]>> wrote:

Hi Olivier,

On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure <[e-mail]<mailto:[e-mail]>> wrote:
Yoshi,

>      > 3: I am still not very sure the usage of SRL options for graceful
>      > subflow closing. I might want to see some texts in the draft to
>      > understand how this can be better than FIN exchange on subflows.
>
>     When a client sends a FIN, it indicates that it will not send data
>     anymore on this subflow. When it sends a SRL option with 0, it
>     indicates
>     to the server that it does not want to receive anymore data on this
>     subflow. We can provide some text if we agree on this use case.
>
> Right. I can image the following 3 situations on the client side.
>
> 1: client doesn't need to receive any more packets from server
> 2: client doesn't want sender to send more data, but wants to receive
> data on the fly.
> 3: client wants to close the connection when sender finishes sending data
>
> I think RST will work for 1: and we can use FIN for 3 > So, in my understanding, this approach tries to address 2:.
> I just would like to understand how much this kind of situations happen.

Consider a video or audio streaming application running on a smartphone.
Smartphone has WiFi and cellular but user wants to limit use of cellular
and force server to use low quality when streaming over cellular.
When smartphone is attached to both WiFi and cellular, it can send SRL
with a bandwidth of 0 over cellular.
If the smartphone moves, and leaves WiFi, then it could send a SRL at 1
Mbps to limit throughput.

This dynamic control of the throughput on the incoming subflows would
work well if a client can adapt its SRL to the current network conditions.

OK. I think this would be a nice example for the usages of SRL and I understand.
But, I am thinking that it might not be helping graceful closing much.
Anyway, the closing is not a major part of the draft. I personally think removing it might be a choice when we don't have strong use cases.
--
Yoshi