Re: [multipathtcp] Multipath TCP Address advertisement 2/5 - Reliability

[Alan Ford <[e-mail]>]

Hi Yoshi,

Inline…

> On 4 Aug 2016, at 07:36, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi Fabien,
> 
> On Wed, Aug 3, 2016 at 8:47 AM, Fabien Duchêne <[e-mail] <mailto:[e-mail]>> wrote:
> Hello,
> 
> As agreed in Berlin during IETF96, I'm sending a series of emails to
> discuss the different contributions proposed
> inhttps://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/ <http://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/>
> 
> This is the part 2/5 : reliability.
> 
> In RFC6824, ADD_ADDR options can be attached to segments carrying data
> or pure acknowledgements.
> In practice, notably given the length of ADD_ADDR with IPv6 addresses
> and the HMAC, it is very likely that they will be often sent as pure
> acknowledgements.
> This implies that ADD_ADDR are sent unreliably, which could be
> problematic when the ADD_ADDR is required to allow the establishment of
> additional subflows, as in load balancing scenarios.
> We propose to rely on the "E" (Echo) flag in the ADD_ADDR option.
> This echo flag is used to acknolwedge a received ADD_ADDR by echoing it.
> If the acknowledgement is not received, the ADD_ADDR option will be
> retransmitted up to N times.
> 
> I have several comments on this. Please let me know if I miss something.
> 
> 1： Do we really need ADD_ADDR reliability in all cases? An end node might want to send ADD_ADDR for 'just in case' rather than for "I want you to use this" 
> BTW, I'm not sure if the draft tries to replace the current ADD_ADDR or to propose an additional ADD_ADDR option.

The argument is that by making it reliable, you only need to send it once to know it’s been received, even if the far end does not use it.

> 
> 2: The sender cannot be sure whether the info in ADD_ADDR will be used or not. It depends on the peer's decision.   
> I might prefer re-transmitting ADD_ADDR up to N times when the sender doesn't receive MP_JOIN to the address for a certain amount of time.
> 

As above, by making it reliable you only need to send it once to know it’s been received, even if the far end chooses not to use it.

I think I’m sold on this idea now, given the additional recent comments. I support this.

> 3: "the receiving host MUST return the exact option.." Although it is MUST, can we always do this? There might be a situation where there is no option space or no segment to send.  

I would assume the same rules as ADD_ADDR are followed, so it’s sent on a duplicate ACK in that case.

Regards,
Alan