Re: [multipathtcp] Submitted drafts

[Olivier Bonaventure <[e-mail]>]

Christoph,


>>>> * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-
>>>> 00.txt
>>
>> This draft includes a slight modification of the handling of the address
>> identifier for the initial subflow. Comments from other implementors would
>> be useful on this draft.
>
> I agree with section 2.1 that having a different address-ID for the
> initial subflow is very cumbersome. An implementation has to store the local
> address-id's within the state-machine of each subflow. It would be much
> easier if we could have a fully global address-table.
>
> However, I'm not sure whether it is good to solve it through an empty
> ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets
> combined with data, we have an issue with unidirectional streams. And
> communicating this ADD_ADDR-option reliably to the peer is here in this case
> even more important than for the "regular" ADD_ADDR option.
>
> It would be better if we could put the address-ID inside the MP_CAPABLE.
> Maybe we can use 8 bits of the key?

Then the entropy for the key is lower because it is reduced to 56 bits.

>
> (also, a little nit: Adding the IPVer within this ADD_ADDR-option is not
> necessary and will bring issues in NAT64-environments).

Agreed.

An alternative is to use the same approach as in
https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt

to make ADD_ADDR reliable

We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented 
and replace it with a set of flags.

                           1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+-------+-------+---------------+
       |     Kind      |     Length    |Subtype| ABCD  |  Address ID   |
       +---------------+---------------+-------+-------+---------------+
       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
       +-------------------------------+-------------------------------+
       |   Port (2 octets, optional)   |                               |
       +-------------------------------+                               |
       |                      Truncated HMAC (8 octets)                |
       |                               +-------------------------------+
       |                               |
       +-------------------------------+



For example, the A flag could be set to zero when a host announces a new 
address. The host that receives an ADD_ADDR2 with the A flag set to zero 
must set the A flag to one and  return it to acknowledge it.

A host should retransmit the ADD_ADDR2 option up to n times if it wants 
to ensure that the ADD_ADDR2 option is delivered reliably.

This would work for the ADD_ADDR2 option that does not contain any 
address and has thus a total length of 32 bits.

Olivier