Archive

I am neutral on the addition on this flag… We have spare bits, so could easily allocate this. But is it worth it? Although not explicitly written, I believe we had expected senders to send the ADD_ADDR option multiple times.

If the ADD_ADDR was not echoed, what would the sender do? Retransmit a few times I guess. I also guess it could learn that a path may not support duplicate ACKs with options.

It could be useful, but I do not feel strongly here… If this were an IETF room, I’d hum weakly ;-)

Regards,
Alan

> On 3 Aug 2016, at 16:47, Fabien Duchêne <fabien.duchene@uclouvain.be> 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/
> 
> 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.
> 
> Fabien
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

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