Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis

[<[e-mail]>]

Hi Philip,

A change was proposed in (https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02) to redefine IPVer field of ADD_ADDR as a set of flag bits (see below). This change applies also for ADD_ADDR2.

OLD:
        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    |ADD_ADDR| IPVer  |  Address ID   |
       +---------------+---------------+--------+--------+---------------+
       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)           |
       +-------------------------------+---------------------------------+
       |   Port (2 octets)             |
       +-------------------------------+

NEW:
       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    |ADD_ADDR| Flags  |  Address ID   |
      +---------------+---------------+--------+--------+---------------+
      |          Address (IPv4 - 4 octets / IPv6 - 16 octets)           |
      +-------------------------------+---------------------------------+
      |   Port (2 octets)             |
      +-------------------------------+

                                        +-+-+-+-+
      Flags is a set of 4 flags:        |C|r|r|r|
                                        +-+-+-+-+

      C flag MUST be set to 1 when the address/port are checked.
      "rrr" are for future assignment as additional flag bits.
      r bits MUST each be sent as zero and MUST be ignored on receipt.

                                 Figure 1

Another proposal from the symmetric draft is to define one of these flag bits as C-flag to indicate to a remote peer that it can initiate subflows even if its didn't initiated the first subflow. The problem was mentioned in [I-D.ietf-mptcp-experience]:



      From a subflow viewpoint, the Multipath TCP protocol is completely

      symmetrical.  Both the clients and the server have the capability

      to create subflows.  However in practice the existing Multipath

      TCP implementations [I-D.eardley-mptcp-implementations-survey<https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02#ref-I-D.eardley-mptcp-implementations-survey>]

      have opted for a strategy where only the client creates new

      subflows.  The main motivation for this strategy is that often the

      client resides behind a NAT or a firewall, preventing passive

      subflow openings on the client.

Cheers,
Med

De : multipathtcp [mailto:[e-mail]] De la part de [e-mail]
Envoyé : lundi 6 juillet 2015 20:01
À : [e-mail]
Objet : [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis


Hi,

In the Prague meeting, we aim to move forward the protocol bis doc (to meeting our Cahrter objetive for a standards track version of RFC6824)



One topic we'd like to discuss is if there's anything that should be deleted from or added to the current draft, https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - based on operational and implementation experience.



Any proposals?



Looking at the (expired) draft summarising the various implementations,

https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02

one thing that may be worth discussing is whether we need both 4 & 8 byte Data ack & DSS

<<   All implementations support 4 bytes "Data ACK" and "Data sequence
   number" fields, and will interoperate with an implementation sending
   8 bytes.  Implementation 1 uses only 4 bytes fields; if an
   implementation sends an 8 byte data sequence number it replies with a
   4 byte data ack.

>>



I don't think the implementation survey suggests that there's anything else worth considering deleting - are there any other proposals?



As to things to add, there are a few proposals for some (minor?) additions in the recent set of drafts from Olivier Bonaventure and team.



Since we have a lot more requests for presentation time than it's possible to squeeze into the meeting, it would be excellent to have discussion on the list before the meeting, about anything that should be added to, or deleted from, the current rfc6824bis, before we progress it to WG last call.



thanks!