Re: [multipathtcp] q about remove addr behavior

[Yoshifumi Nishida <[e-mail]>]

Hi Christoph,

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

> 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]>
> wrote:
>
>> Hello,
>>
>> On Jun 21, 2017, at 9:04 PM, Yoshifumi Nishida <[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-s
>> essa-channel-bonding-of-low-rate-links-using-mptcp-for-airbo
>> rne-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.
>

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