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

From: Christoph Paasch <[email-masked]>
Date: Wed, 21 Aug 2019 09:29:48 -0700

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 <
> [email-masked]> 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.

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

Could the SRL-option have a bit that says "and when you reached 0-rate,
please close the subflow" ?

Sure, we could simply on the receiver-side, wait until the subflow quiesces
and then close it with a RST. However, if that RST gets lost, the subflow
will hang on the sender-side for quite a while.

Cheers,
Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 26 Aug 2019 00:31:20 -0700

Hi Christoph,

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

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 26 Aug 2019 10:31:03 -0700

Hello Yoshi,

> I think if the client really wants not to use cellular, it can just close

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.

> 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