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

[Christoph Paasch <[e-mail]>]

Hello Yoshi,

On 26/08/19 - 00:31:20, Yoshifumi Nishida wrote:
> Hi Christoph,
> 
> On Wed, Aug 21, 2019 at 9:30 AM Christoph Paasch <[e-mail]> wrote:
> 
> > Hello,
> >
> > jumping in on this thread a bit late. Please see inline:
> >
> > On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote:
> > > 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.
> >
> > Here, it would be nice to be able to close the cellular subflow. The reason
> > is the following: If we are not sending any packets on that cellular
> > subflow
> > (because we set the SRL to 0), after some time the subflow will become
> > dis-functional because the NAT/Firewall-mapping has expired.
> >
> > So, keeping subflows at 0 for an extended period will cause trouble.
> >
> 
> I think it's ok for an implementation to close the subflow here if they
> prefer.
> But, I am not sure if we need to standardize this behavior.
> 
> I think if the client really wants not to use cellular, it can just close
> the subflow by itself.

The problem is that the client can only do half-closed subflow by sending a FIN.

The way one would do this is: Set SRL to 0. Wait for quite a bit until
the subflow "calmed down". Send a FIN and see that the sequence-number in
the corresponding ACK of the peer is the same as the rcv_nxt [1]. This indicates
that the peer stopped sending. Now, the client can close the subflow with a
RST.

[1] If that's not the case, it means the peer hasn't reached SRL-0 yet. Now
the client can just wait and eventually kill the flow with a RST and hope
that no data-in-flight is being lost that way.

> I am guessing sending SRL 0 could mean something more. For example, the
> client wants to use the cellular for sending as it will send very small
> amount, but not for receiving due to the volume of data, or the client
> wants to stop using the cellular for a certain amount of time.  In the
> latter case, the client will need to send keep-alive at a certain period to
> avoid NAT timeout, though.

Agreed - that is the main use-case of SRL 0.


What is missing for my use-case is a way for the client to tell
the server to gracefully close the subflow. The reason for that can simply
be because WiFi has improved again and cell isn't needed anymore. The
current way to signal that is by killing the subflow with a RST which
results in loss of the in-flight-data. That loss degrades the overall
connection-quality as the data needs to be retransmitted over WiFi again.


Using SRL-0 is a half-baked way to get there. It allows to "calm down" the
subflow but isn't yet 100% safe as the client never knows when the server
actually reached the 0-rate.
Ideally, if we could use one of the reserved bits of the SRL-option
for that it would achieve the same goal.


Cheers,
Christoph