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

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 15 Jul 2019 01:40:38 -0700

Hi,
I've read this draft and have some questions and comments.

1: I am wondering how to calculate and limit the sending rate of subflow.
    I think adjusting window size wouldn't be very accurate. But, we don't
want to perform expensive processing for this purpose.
2: I think this is one way information and servers don't need to send SRL
option to clients. But, the draft says "a host MUST NOT send more than
three SRL options on connection where it has not received any SRL option"
Does this mean senders need to send SRL options?
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.

Thanks,
--
Yoshi

---

From: Viet Hoang Tran <[email-masked]>
Date: Mon, 15 Jul 2019 10:12:57 +0000

Hi Yoshi,

Thanks for the comments,

On 15 Jul 2019, at 10:40, Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

1: I am wondering how to calculate and limit the sending rate of subflow.
    I think adjusting window size wouldn't be very accurate. But, we don't want to perform expensive processing for this purpose.

My experiment using this mechanism had pretty accurate results.
We can rely on TCP pacing instead, but even Linux before 4.20 also used a similar mechanism to implement TCP pacing:
  https://lwn.net/Articles/766564/

2: I think this is one way information and servers don't need to send SRL option to clients. But, the draft says "a host MUST NOT send more than three SRL options on connection where it has not received any SRL option" Does this mean senders need to send SRL options?
It is my editorial mistake. I will remove  “ where it has not received any SRL option”.
But related to this, it is probably useful if the server could acknowledge the SRL policy acceptance, e.g. by echoing the option with a flag set to the client.

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.

This use case is not clear for now, I will remove it.

Thanks,
Hoang

Thanks,
--
Yoshi
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 15 Jul 2019 15:53:00 +0000

Yoshi,

> I've read this draft and have some questions and comments.

Thanks for your comments.

>      I think adjusting window size wouldn't be very accurate. But, we 
> don't want to perform expensive processing for this purpose.

The pragmatic approach is that it is possible to use window clamping and 
update the clamp value every time the rtt is updated. This is not as 
precise as a token bucket for example, but I don't think that the use 
cases that we have require this type of precision

> 2: I think this is one way information and servers don't need to send 
> SRL option to clients. But, the draft says "a host MUST NOT send more 
> than three SRL options on connection where it has not received any SRL 
> option" Does this mean senders need to send SRL options?

We'd like to limit the amount of SRL options that are sent, but another 
comment suggested to indicate a duration for the SRL value. This would 
require regular transmissions of the SRL option. This part of the text 
will need to be updated.

> 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.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 15 Jul 2019 23:45:04 -0700

Hi Olivier, Hi Viet,

Thanks for the explanations,

> require regular transmissions of the SRL option. This part of the text

OK. I will wait for the updates.

> 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.
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 16 Jul 2019 09:31:22 +0000

Yoshi,

> 2: client doesn't want sender to send more data, but wants to receive 
> data on the fly.
> I think RST will work for 1: and we can use FIN for 3 > So, in my understanding, this approach tries to address 2:.

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.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 16 Jul 2019 23:31:57 -0700

Hi Olivier,

On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure <
[email-masked]> wrote:

> > I think RST will work for 1: and we can use FIN for 3 > So, in my
> understanding, this approach tries to address 2:.

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

---

From: Viet Hoang Tran <[email-masked]>
Date: Tue, 23 Jul 2019 20:13:06 +0000

Hi Yoshi,

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

On 23 Jul 2019, at 15:35, Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Olivier,

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

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