Re: [multipathtcp] 6824bis -11 review

[Yoshifumi Nishida <[e-mail]>]

Hi Rahul,

Thanks for bringing up an interesting point before we finalize the draft!
I put my comments in lines.

On Wed, Aug 8, 2018 at 8:20 AM, Rahul Arvind Jadhav <[e-mail]
> wrote:

> Please find my response [RJ3] inline.
>
>
>
> Best,
>
> Rahul
>
>
>
>
>
> On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav <[e-mail]>
> wrote:
>
>
>
> c) sending a new ADD_ADDR with same ID + address and different port is fine
>
> [RJ] again this is what the text already says, but I’m not still clear
> about this. Why ID + address has to match? Only ID should be enough.
>
>
>
> Consider:
>
>
>
> a) ADD_ADDR comes in saying ID=2, addr=10.0.0.1 (private)
>
> b) MP_JOIN comes in saying ID=2, addr=8.9.10.11 (public)
>
> c) ADD_ADDR comes in saying ID=2, addr=192.168.0.1
>
>
>
> What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this
> mean the subflow created in (b) is now no longer valid?
>
>
>
> By keeping the address / ID mapping, if an address is lost, then so is the
> subflow.
>
>
>
> [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it as
> an UPDATE? Because ID remains same. Subflow created in (b) remains valid
> (not sure if I’m missing anything here, I see no reason to lose this
> subflow).
>
> In step ( c), the receiver can override Address field in context to ID=2
> to the new addr (192.168.0.1) ……   8.9.10.11 is kept separately as the
> learnt actual rcvd IP (from MP_JOIN) in the same context ID=2. We have to
> agree that an implementation needs to maintain this IP separately in
> context to ID=2 anyways.
>
> So if we do an explicit REMOVE+ADD, the end result is the same as this
> UPDATE (but with much less overhead & impl ease).
>
>
>
> I would be interested in hearing from other implementers here… Is there an
> issue with “updating” using ADD_ADDR?
>
>
>
> Given we say that REMOVE_ADDR should not remove a subflow if it’s still
> alive, we have precedent for implying a subflow can exist to an address
> which does not have an Address ID - to - IP address mapping.
>
>
>
> So given that, does updating, as Rahul suggests, cause a problem?
>
>
>
>
>
> Hmm.. I am wondering why we want to re-use the same address ID while we
> have 0-255 values for it?
>
> Do we have some advantage for it? I thought picking up a new ID would be
> safer and simpler..
>
>
>
> [RJ3]: Thanks for covering this angle. Now if we do not re-use the same
> address ID then the scenarios are different. What happens when REMOVE_ADDR
> sent for previous ID is ignored because the flow is active on the receiver?
> The new ADD_ADDR with new ID will result in new ID getting added on the
> receiver. This requires more state across multiple IDs, and requires more
> messaging since REMOVE_ADDR has to done. And there is still an uncertainty
> regarding what happens if the REMOVE_ADDR is ignored because the old flow
> is active. Thus this is not simpler.
>
> ADD_ADDR doing an update on existing ID is easier to implement and
> requires less messaging.
>
> There are advantages with an update on existing ID unless other
> implementers have some other angle to cover.
>

Yes, if we pick up a new ID, mptcp stack will maintain multiple IDs until
we find the old path is not active anymore. But, I think this is ok as
these are different paths.

Please correct me if I'm wrong, but It seems to me that when we update the
flow, it is expected to inherit the state of the flow in this approach.
But, in this case, I'm not very sure if this is right thing to do. When
address has been changed, I guess the state of the path might be changed as
well..
Also, when we try to update an ID, what if the old flow with the ID is
still active? I think we should not remove it and keep it until closed.


>
> As Alan mentioned, when we try to "update" the address ID, we will have to
> keep both addresses until we confirm that old one is not used anymore.
>
> Also, in the case described above, what will happen if (b) was delayed and
> arrived after (c)?
>
>
>
> [RJ3] I’m not sure what is meant by, “confirm that old one is not used
> anymore”. A receiver anyways is ready to receive an MP_JOIN from source
> address not advertised in the ADD_ADDR.
>
> Considering update is used,.. in the scenario above, if MP_JOIN (b)
> arrives after ADD_ADDR update (c) is issued, it would not result in any
> mishap imo.
>

Sorry. I was not clear enough. "confirm" means that checking if the subflow
is already closed or not by following what is described Section 3.4.2. This
may take a certain time as we might need to wait for timeout.

About race condition case, I am thinking about an example like this.
(a) ADD_ADDR comes in saying ID=2, addr=10.0.0.1 (private)
(b) MP_JOIN comes in saying ID=2, addr=8.9.10.11 (public)  (internal
10.0.0.1)
(c) ADD_ADDR comes in saying ID=2, addr=9.10.11.12 (public)

In this case, when a node sent (b), ID=2 is associated with internal
address 10.0.0.1
But, after that, the node learned he got new addr 9.10.11.12 which is
public. So, he decided to replace ID=2 for some reasons. (because the
current ID=2 has significant delay?)
Now, because of significant delay in the ID=2 path, (b) has arrived after
(c). How to handle this kind of case is not very clear to me yet.

Thanks,
--
Yoshi