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

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier, Hi Viet,

Thanks for the explanations,

On Mon, Jul 15, 2019 at 8:53 AM Olivier Bonaventure <
[e-mail]> wrote:

> Yoshi,
>
> > I've read this draft and have some questions and comments.
>
> Thanks for your 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.
>
> 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.
>

OK. I will wait for the updates.


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