Subject: [multipathtcp] Multipath TCP options

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 01 Oct 2014 17:59:24 +0200

Joe,

> FWIW, I don't think it's a good idea for MPTCP to use TCP options in a
> nonstandard manner. That would severely complicate option implementation.
>
> IMO, either use the option as it's defined - which may be overkill for
> MPTCP - or define a new MPTCP extension for its own optional use of
> timestamps.

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.

The last solution could work for a timestamp option which does not 
change the semantics of the other MPTCP options. It could provide some 
extensibility in the protocol without using space in the initial 
handshake. For example, we could specify that a host should not send 
more than three MPTCP packets containing the new option if it does not 
receive the same option from the other host. This would provide a form 
of late negotiation of the MPTCP options on an MPTCP connection.

While updating RFC6824, you should probably spend some time to discuss 
the extensibility of the base MPTCP specification.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Oct 2014 15:26:25 -0700

Hi, Oliver,

On 10/1/2014 8:59 AM, Olivier Bonaventure wrote:
> are defined in RFC6824. 

Are you referring to options within Multipath TCP? It might be useful to
distinguish them more clearly from TCP options - of which Multipath TCP
is one.

> In the future, it can be expected that new types

Of both TCP options and options within the Multipath TCP options, sure.

> handshake. This would consumme more space in the initial handshake

If you're talking about an option within MPTCP that is negotiated during
the MPTCP handshake, sure.

If you're proposing a new TCP option KIND value, I disagree (I don't
think that's what you meant, but the text reads that way).

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 1 Oct 2014 22:27:32 -0700

Hi Olivier,

On Wed, Oct 1, 2014 at 8:59 AM, Olivier Bonaventure <
[email-masked]> wrote:

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

Thanks,
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 02 Oct 2014 09:02:37 +0200

Joe,
> distinguish them more clearly from TCP options - of which Multipath TCP

I'm only referring to MPTCP specific options, i.e. suboptions of TCP 
option type 30

> the MPTCP handshake, sure.

Yes

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 02 Oct 2014 09:15:34 +0200

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 :
>
>     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.
>
>
> 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)
> 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 ?

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 2 Oct 2014 21:26:41 -0700

Hi Olivier,

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

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

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