Re: [multipathtcp] 6824bis -11 review

[Alan Ford <[e-mail]>]

Hi Rahul,

Comments inline...

> On 29 Jul 2018, at 04:17, Rahul Arvind Jadhav <[e-mail]> wrote:
> 
> Thanks Alan for clarifying. 
> But I’m still not clear about this. Please find my comments [RJ] inline.
>  
> On 28 Jul 2018, at 18:19, Alan Ford <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 3. Section 3.4.1. Address Advertisement 
>  "A host can send an ADD_ADDR message with an already assigned Address
>  ID, but the Address MUST be the same as previously assigned to this
>  Address ID, and the Port MUST be different from one already in use
>  for this Address ID."
> [RJ]: Didn't understand the rationale for allowing reuse of Address ID only for port change and not for IP change.
> 
> I cannot recall the rationale here either.
> 
> Furthermore - as written - this would seem to prevent retransmission. Which is crazy.
> 
> If nobody can recall the reason for this I would suggest we remove it.
>  
> Having looked at the text again here, I think I can recall the rationale. But we need to consider whether this is actually the intended behaviour.
>  
> Address ID was originally designed to provide a mechanism whereby a client behind a NAT could refer to its address without using the IP address, which would be altered by the NAT. This would allow a client, whose wifi interface had disappeared, to tell the far end over its cellular interface that it had gone, by referring to the Address ID it had used in the MP_JOIN, in the REMOVE_ADDR.
>  
> There is a secondary use here which I realise we haven’t explicitly stated. If a client declared its private address in ADD_ADDR, but also sent a MP_JOIN with the same address ID, but naturally a different address, the far end would say “ah, these addresses don’t match, so I should not bother attempting to connect to the Address in the ADD_ADDR”. This is an optimisation but one that should probably be mentioned.
>  
> [RJ] The far end here matches the Address ID, identifies the ADD_ADDR context, and uses the received source address .. May be the far end should keep this newly learnt IP address within the ADD_ADDR context for future MP_JOIN once this sub-flow closes? As I understand, Address ID alone is the primary-key for matching anyways.

Yes, the intention is that the source address from a MP_JOIN can be used for future connections, creating or updating the mapping to the Address ID. Which makes me realise we probably need the ‘C’ bit on the MP_JOIN. But that’s an aside.

>  
> So the point is that Address ID refers purely to the address, and not to the address + port pair. Therefore a new port can be advertised in a new ADD_ADDR using the same Address ID.
>  
> [RJ] I’m not sure about this interpretation. My thinking was that Address ID refers purely to the sub-flow possibility on an interface without any dependence on address + port. Address and port are parameters for the Address ID which might possibly change in the future.

For the purposes of MPTCP, I’m not sure how interface and address are different here.

>  
> So we should clarify this:
>  
> a) retransmitting an ADD_ADDR with same ID, address, and port is fine
> b) this could permit the far end to trigger another connection attempt
> [RJ] a & b is clear from existing text
>  
> 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.

> d) to reassign an address ID you must first REMOVE_ADDR
> [RJ] This also I don’t get. Why should it be necessary to do a REMOVE_ADDR to change an IP address for an existing ID? If a ADD_ADDR refers to an existing ID with a new Address then can’t this simply override the IP address for that ID? 
>  
> Another way to put this question, In which case a receiver after matching the Address ID (for MP_JOIN or ADD_ADDR) will depend on matching against the address field and what is achieved by matching the address field? 
>  
> By allowing to override an IP address in the existing ID, a REMOVE_ADDR + ADD_ADDR cycle which requires at-least one RTT would be saved. Secondly, the implementation becomes lot more simpler (for me this is the major motivation).

Again, see the example above. It is my view that it is removes ambiguity for a sender to have a unique ID to address mapping.

Best regards,
Alan