Re: [multipathtcp] 6824bis -11 review

[Christoph Paasch <[e-mail]>]

On 31/07/18 - 13:07:06, Alan Ford wrote:
> 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?

I haven't yet implemented MPTCP path-management in a way that both sides can
trigger the creation of a subflow - which is the scenario we are concerned
about here.


If we would try to do this, I think we should always "believe" the latest
information that we are receiving. In the above scenario, this would mean
that (c) would update the Address-ID to IP mapping.

Yes, it's a private IP and probably not routable - but that simply means
that there is an implementation-bug on the client as he should not have
announced the IP in the first place.

Should (c) trigger a removal the subflow established in (b) ? I don't think
so. As long as the subflow is working fine,... we should keep it. Only
REMOVE_ADDR should trigger an explicit removal.

That's just my opinion.


Christoph