Re: [multipathtcp] 6824bis -11 review

[Rahul Arvind Jadhav <[e-mail]>]

Please find my response [RJ3] inline.

Best,
Rahul


On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav <[e-mail]<mailto:[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.

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.