Subject: [multipathtcp] q about addr id=0 issue in address management

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 3 Aug 2015 22:27:00 -0700

Hi,
I might miss something as I am not an implementor of MPTCP, but I have
a very naive question about addr id=0 issue in the address management
draft.

I think I understand that the issue forces a Multipath TCP
implementation to at least store the address identifier of the initial
subflow for each connection. But, it seems to me that this can be done
by one octet variable.
I am personally not very sure if this is too expensive. I will
appreciate if someone could elaborate on this point.

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 03 Aug 2015 23:08:28 -0700

Hello Yoshifumi,

> subflow for each connection. But, it seems to me that this can be done

indeed, additional state has to be stored on a per-subflow basis to make
sure that we are able to track the address-id. Storing this additional state
is not a big deal in my opinion.

The complexity comes rather from the handling of address-events in the stack
as one has to take into account that the initial address does not need to be
advertised again
(https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285).

Also, when an address disappears, the stack has to take into account that
this address might actually be the one that has been used for the initial
subflow. In Linux we maintain a global address-table with unique address-ids
per local address, and special-case around the initial subflow.
So, when an address disappears, we have to look through all subflows to see
whether there are subflows that use this address with a different
address-id.

> appreciate if someone could elaborate on this point.

I agree that we should not introduce a change to the protocol spec to slightly
reduce the implementation's complexity.

If we could include the address-id in the MP_CAPABLE it would be great as it
would be a small change to the protocol and fit the design of MP_JOIN as
well.
But I can understand that we don't want to reduce the entropy - although I'm not
convinced that this is really a big deal as we would still have 110 bits of
entropy for the HMAC.

Cheers,
Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 7 Aug 2015 00:26:36 -0700

Hi Christoph,

> whether there are subflows that use this address with a different

Thanks, I think I understand.
But, I'm not very sure how much performance gain we can get by this.
However, I also think reducing the entropy might not be a big deal.
--
Yoshi

---

From: Alan Ford <[email-masked]>
Date: Fri, 7 Aug 2015 08:41:05 +0100

Hi Christoph,

> is not a big deal in my opinion.

Surely it's per-connection state not per-subflow? Identifying which of your subflows has id=0 for this particular connection?

> (https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285).

I don't know the code here, but surely this test applies irrespective of identifier?

> whether there are subflows that use this address with a different

Ah, I get this one :(

If an address came back, how would you know it's the initial one and thus should have id=0? Well, that's not actually a scenario I had considered so far in general. The spec is not explicit as to whether the identifiers should be the same if an interface is removed and later comes back.

Would it add extra problems if, in that case, it was said that new identifiers could be used? The main reason for the address identifier is simply to identify subflow ends when the IP address may have bee changed by a NAT. Plus, implying it would be the same adds extra semantics to an IP address. If you moved networks, or from wifi to wired, but had the same IP address, you may actually not want the far end to think it's the same.

In this scenario I think you would be fine issuing a new address ID for a new interface, even if the IP address is the same as the previously-lost initial subflow. And then this would go away. I am happy to clarify this in the spec if you don't think it would cause any additional implementation issues?

Regards,
Alan

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 10 Aug 2015 14:52:48 -0700

> Surely it's per-connection state not per-subflow? Identifying which of your subflows has id=0 for this particular connection?

For each subflows we have to store the local address-id that belongs to the
subflow's local IP-address. Thus, it's a per-subflow state.

> I don't know the code here, but surely this test applies irrespective of identifier?

The code I linked is specific to the fact that address-ids of initial
subflows are 0.

The problem is that we would otherwise announce the same address as the one
from the initial subflow, but with another address-id. From the peer's
point-of-view this then looks like a different address and he will try to
establish a subflow to this address. We will then end up with two subflows
that go over the same path.

If the address-id of the initial subflow would be explicit, re-announcing
this address would not result in a duplicate subflow on the same path,
because the address-id is already known to the end-host, and thus he will
not try to establish yet another subflow to this IP.

> In this scenario I think you would be fine issuing a new address ID for a new interface, even if the IP address is the same as the previously-lost initial subflow. And then this would go away. I am…

That's what we do in the implementation. If an address comes back up again,
it gets assigned a different address-id, irregardless of for what it has
been used in the past.

Yes, from my point-of-view it is fine to clarify this in the spec.

Cheers,
Christoph

---

From: Alan Ford <[email-masked]>
Date: Tue, 11 Aug 2015 13:18:19 +0100

Hi Christoph,

On 10 August 2015 at 22:52, Christoph Paasch <[email-masked]> wrote:

> > Surely it's per-connection state not per-subflow? Identifying which of
> your subflows has id=0 for this particular connection?
>

Why do you need an address ID for every subflow? You can use a global
IP-to-ID mapping table in general, but each connection has a value that
says that IP/ID foo is in fact ID 0 for this connection.

> > > (
> https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285
> ).
> >

Understood, and yes that is the intended behaviour when using id=0.

Is this really a problem? It's a simple check!

> If an address came back, how would you know it's the initial one and thus
> should have id=0? Well, that's not actually a scenario I had considered so
> far in general. The spec is not explicit as to whether the identifiers
> should be the same if an interface is removed and later comes back.
> >
> > Would it add extra problems if, in that case, it was said that new
> identifiers could be used? The main reason for the address identifier is
> simply to identify subflow ends when the IP address may have bee changed by
> a NAT. Plus, implying it would be the same adds extra semantics to an IP
> address. If you moved networks, or from wifi to wired, but had the same IP
> address, you may actually not want the far end to think it's the same.
> >
> > In this scenario I think you would be fine issuing a new address ID for
> a new interface, even if the IP address is the same as the previously-lost
> initial subflow. And then this would go away. I am happy to clarify this in
> the spec if you don't think it would cause any additional implementation
> issues?
>

 Great thanks I will clarify that.

Regards,
Alan