Re: [multipathtcp] Multipath TCP options

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

On Thu, Oct 2, 2014 at 12:15 AM, Olivier Bonaventure <
[e-mail]> wrote:

> Yoshifumi,
>
>
>>     Your suggestion triggers a more fundamental question that we have
>>     not yet discussed on this mailing list. Currently, all Multipath TCP
>>     options are defined in RFC6824. In the future, it can be expected
>>     that new types of options will be proposed.
>>
>>     For the sake of discussion, let us consider that we define a new
>>     MPTCP timestamp option. Since it was not defined in RFC6824, we
>>     could have hosts that support the new timestamp option and hosts
>>     that do not support it. How do we "negotiate" the utilisation of
>>     this new option on an MPTCP connection. I see three possible ways :
>>
>>       - we change the version number of MPTCP so that the new version is
>>     RFC6824+timestamp. If this version is negotiated during the initial
>>     handshake (note that since we have only defined version 0 of MPTCP,
>>     we have not yet fully specified how the negotiation of a version
>>     would be done), then timestamp can be used. Otherwise we use only
>>     RFC6824 and thus no timestamps on this connection
>>
>>       - we keep version 0 of MPTCP, but define a new TCP option that
>>     enables the negotiation of the MPTCP timestamp option during the
>>     three-way handshake. This would consumme more space in the initial
>>     handshake
>>
>>       - we keep version 0 of MPTCP and specify that the options that are
>>     not defined in RFC6824 could be used in the future, but if a host
>>     receives an MPTCP option that it does not understand, it should
>>     silently ignore the MPTCP option.
>>
>>
>> If we can presume this is similar to the current timestamp options,  I
>> personally think the last one is enough.
>> This is because you'll put the timestamp options in some data packets
>> and results will be returned in the options in the ack packets.
>> No new transmission logic will be required for this option exchange as
>> we can utilize normal data and ack exchanges.
>> (I believe there is no need to put timestamp if you don't have data to
>> send or don't receive data)
>> If we don't see the option in the ACK at all, we can presume the option
>> cannot be used for some reason.
>> So, I don't see the needs to change the current semantics for this. In
>> case of other options, we might want to think about other ways such as
>> late negotiation as you mentioned.
>>
>
> A timestamp MPTCP option would be purely informational. If it does not get
> through, the data transfer is not affected. If we invent something like
> window scale, then the data transfer could be affected and we would need to
> take care.
>
> I would suggest to at least plan for future MPTCP options in RFC6824bis
> with a note to developers which could read :
>
> This document defines the semantics and the processing of the following
> Multipath TCP options :
>
>    +-------+--------------+----------------------------+---------------+
>    | Value |    Symbol    |            Name            |   Reference   |
>    +-------+--------------+----------------------------+---------------+
>    |  0x0  |  MP_CAPABLE  |      Multipath Capable     |  Section 3.1  |
>    |  0x1  |    MP_JOIN   |       Join Connection      |  Section 3.2  |
>    |  0x2  |      DSS     | Data Sequence Signal (Data |  Section 3.3  |
>    |       |              |    ACK and data sequence   |               |
>    |       |              |          mapping)          |               |
>    |  0x3  |   ADD_ADDR   |         Add Address        | Section 3.4.1 |
>    |  0x4  |  REMOVE_ADDR |       Remove Address       | Section 3.4.2 |
>    |  0x5  |    MP_PRIO   |   Change Subflow Priority  | Section 3.3.8 |
>    |  0x6  |    MP_FAIL   |          Fallback          |  Section 3.6  |
>    |  0x7  | MP_FASTCLOSE |         Fast Close         |  Section 3.5  |
>    +-------+--------------+----------------------------+---------------+
>
>                       Table 2: MPTCP Option Subtypes
>
>    Values 0x8 through 0xe are currently unassigned.  The value 0xf is
>    reserved for Private Use within controlled testbeds. Extensions to this
> specification might define new MPTCP option subtypes. An implementation
> that receives an unknown MPTCP option in any segment SHOULD silently ignore
> this MPTCP option and continue to process the segment.
>
>
> If we do not clarify the handling of these unknown MPTCP options, we might
> end up in a situation where some MPTCP implementations (or worse MPTCP
> aware middlebxes) drop segments that contain an unknown MPTCP option, or
> worse close MPTCP connections where an unknown MPTCP option has been
> received.
>
> We probably also need to think whether we need to change the version of
> MPTCP if we change the semantics of one of the defined options. There is
> already an interesting use case with the ADD_ADDR option.
>
> In RFC6824, this MPTCP option is defined as
>
>                            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| IPVer |  Address ID   |
>       +---------------+---------------+-------+-------+---------------+
>       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
>       +-------------------------------+-------------------------------+
>       |   Port (2 octets, optional)   |
>       +-------------------------------+
>
>                  Figure 12: Add Address (ADD_ADDR) Option
>
>
> while RFC6824bis adds a HMAC :
>
>                           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| IPVer |  Address ID   |
>       +---------------+---------------+-------+-------+---------------+
>       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
>       +-------------------------------+-------------------------------+
>       |   Port (2 octets, optional)   |                               |
>       +-------------------------------+                               |
>       |                      Truncated HMAC (8 octets)                |
>       |                               +-------------------------------+
>       |                               |
>       +-------------------------------+
>
>
> The two can be easily distinguished by looking at the length field.
> However, consider a host that implements exactly RFC6824. How should it
> react to the reception of an ADD_ADDR option in the RFC6824bis format ?


I think the new add addr message will be ADD_ADDR2, so I believe that
strict 6824 implementations will discard the options when they see them.
But, as far as I've checked, I couldn't find the sentence in RFC6824 that
states unknown subtype option must be ignored. Maybe we'd better add this
kind of sentences in the bis draft. Also, the bis draft should mention the
behavior when they receives old ADD_ADDR messages.

Like ADD_ADDR case, I think changing subtype can be an option to change the
semantics, while we might need to worry about available subtypes.
OTOH, I'm thinking that if we will have options like window-scale which
requires tight synchronizations between both ends, we might need to think
about something which leads to changing version number.

Thanks,
--
Yoshi