Re: [multipathtcp] 6824bis -11 review

[Alan Ford <[e-mail]>]

Hi Rahul, all,

> 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?

Best regards,
Alan