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

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure <
[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