Re: [multipathtcp] Submitted drafts

[Alan Ford <[e-mail]>]

Hi all,

On 10 July 2015 at 21:57, Olivier Bonaventure <
[e-mail]> wrote:

> 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.
>>
>>
This issue puzzles me, is this really such a big issue? I haven't
implemented this myself of course, but as I understand it, you just want to
use a single table for all address-to-addressID mappings.

OK, fine. But you already have connection-level state (for the key etc), so
is it really too complex to e.g. have a single byte in your
connection-level state that points to the index on your global mapping
table? That seems much more simple and much more reliable than a
potentially unreliable signal!


> 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.
>
>
Definitely thumbs-down for that I'm afraid!


> (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.


That seems an interesting idea. We can certainly remove IPVer (as you say
it's implied by length now). It was only relevant when we could put
multiple addresses in one option - before we had the HMAC. Having flags
could be useful - I like to idea of reliability like this. We could use the
same trick on REMOVE_ADDR.

Incidentally, if we end up bumping the MPTCP version for the syncookies
support (and I think this is a good idea - I'm awaiting an updated draft to
comment in more detail on this one), then we can also put ADD_ADDR2 back to
its rightful place as ADD_ADDR :)

Regards,
Alan