Re: [multipathtcp] q about remove addr behavior

[Christoph Paasch <[e-mail]>]

Hello Yoshifumi,

> On Jun 22, 2017, at 11:26 AM, Yoshifumi Nishida <[e-mail]> wrote:
> On Thu, Jun 22, 2017 at 12:14 AM, Christoph Paasch <[e-mail] <mailto:[e-mail]>> wrote:
> Hello,
> 
>> On Jun 21, 2017, at 9:04 PM, Yoshifumi Nishida <[e-mail] <mailto:[e-mail]>> 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.
> 
> 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