Archive

On 03/08/2016 18:11, Alan Ford wrote:
> 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.
The idea here is, with the load balancing in mind, we *really* want the
ADD_ADDR to be delivered, and sending it multiple times doesn't really
guarantee that it will be delivered.
> 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.
Retransmit it a few times, and if not echoed, we could know that it
hasn't been delivred.
Because there's the case where the ADD_ADDR is received but the client
doesn't elect to open a subflow on this address.
With the echo bit, if such thing happen basically you would know "ok, he
received my add_addr but doesn't want to establish a subflow for now",
otherwise you won't be able to tell the difference between a lost
ADD_ADDR and this case.

I agree with the dupacks 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