Subject: [multipathtcp] q about remove addr behavior

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Jun 2017 21:04:49 -0700

Hi,
In the Chicago meeting, I remember Joseph mentioned an issue on linux which
close all subflows that use an IP address when rem addr for it has been
received.

(page 13 in https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-
sessa-channel-bonding-of-low-rate-links-using-mptcp-for-
airborne-flight-research-00.pdf)

As far as I read 6824bis draft, this behavior seems not to be recommended.
But, do we need more specific guidance here?

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 22 Jun 2017 00:14:57 -0700

Hello,

> On Jun 21, 2017, at 9:04 PM, Yoshifumi Nishida <[email-masked]> wrote:
> In the Chicago meeting, I remember Joseph mentioned an issue on linux which close all subflows that use an IP address when rem addr for it has been received.
> 
> (page 13 in https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-channel-bonding-of-low-rate-links-using-mptcp-for-airborne-flight-research-00.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-channel-bonding-of-low-rate-links-using-mptcp-for-airborne-flight-research-00.pdf>)
> 
> As far as I read 6824bis draft, this behavior seems not to be recommended. But, do we need more specific guidance here?

true, in Linux we just close the subflow and do not send keepalives to check whether the subflow is really up or not.

I'm not sure if sending keepalives is the right thing to do. Basically, when the peer tells us that this subflow should be removed, why shouldn't a host trust its peer and do as as it says ?
The benefit of closing the subflow is that we can stop trying to send data on it and we free those resources. Lingering subflows is a serious problem on the server-side, when clients move away from a WiFi access-point.

Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 22 Jun 2017 11:26:33 -0700

Hi Christoph,

On Thu, Jun 22, 2017 at 12:14 AM, Christoph Paasch <[email-masked]>
wrote:

> In the Chicago meeting, I remember Joseph mentioned an issue on linux
> which close all subflows that use an IP address when rem addr for it has
> been received.
>
> (page 13 in https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-s
> essa-channel-bonding-of-low-rate-links-using-mptcp-for-airbo
> rne-flight-research-00.pdf)
>
> true, in Linux we just close the subflow and do not send keepalives to
> check whether the subflow is really up or not.
>
> I'm not sure if sending keepalives is the right thing to do. Basically,
> when the peer tells us that this subflow should be removed, why shouldn't a
> host trust its peer and do as as it says ?
> The benefit of closing the subflow is that we can stop trying to send data
> on it and we free those resources. Lingering subflows is a serious problem
> on the server-side, when clients move away from a WiFi access-point.
>

I am guessing it depends on how implementations are using remove addr
feature. We should avoid mixing up addresses and flows.
Even if a subflow is removed, it won't be wise to send remove addr when the
other subflows use the address.
The draft seems to presume a case where an IF has gone, but this kind of
events might not be easy to be caught at the TCP layer.
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 26 Jun 2017 23:03:27 -0700

Hello Yoshifumi,

> On Jun 22, 2017, at 11:26 AM, Yoshifumi Nishida <[email-masked]> wrote:
> On Thu, Jun 22, 2017 at 12:14 AM, Christoph Paasch <[email-masked] <mailto:[email-masked]>> wrote:
> Hello,
> 
>> On Jun 21, 2017, at 9:04 PM, Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:
> I am guessing it depends on how implementations are using remove addr feature. We should avoid mixing up addresses and flows. 
> Even if a subflow is removed, it won't be wise to send remove addr when the other subflows use the address.

yes, this is different from the way I understood your mails. You mean that we should have per-subflow identifiers instead of address-id's ?

> The draft seems to presume a case where an IF has gone, but this kind of events might not be easy to be caught at the TCP layer.

I'm not sure I follow you here. Can you clarify ?

My comment was with respect to the sentence in the draft:
For security purposes, if a host receives a REMOVE_ADDR option, it
   must ensure the affected path(s) are no longer in use before it
   instigates closure.

That's the part that we do not implement in Linux.

Cheers,
Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 29 Jun 2017 14:13:33 -0700

Hi Christoph,

On Mon, Jun 26, 2017 at 11:03 PM, Christoph Paasch <[email-masked]>
wrote:

>> As far as I read 6824bis draft, this behavior seems not to be
>> recommended. But, do we need more specific guidance here?
>>
>>
>> The benefit of closing the subflow is that we can stop trying to send
>> data on it and we free those resources. Lingering subflows is a serious
>> problem on the server-side, when clients move away from a WiFi access-point.
>>
>
> yes, this is different from the way I understood your mails. You mean that
> we should have per-subflow identifiers instead of address-id's ?
>

> That's the part that we do not implement in Linux.

Sorry. I was not clear enough. What I thought was what would be a trigger
for issuing remove addr in linux.
I understand linux does not have the part you mentioned.
But, if so, I guess triggering remove addr when a P2P interface has gone
might not be a very good idea..
--
Yoshi