Subject: [multipathtcp] Submitted drafts

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 9 Jul 2015 17:04:37 +0200

Hello,

During the last week we have written and submitted several drafts that 
could be of interest for the working group :

* https://www.ietf.org/internet-drafts/draft-ietf-mptcp-experience-02.txt

This is a revised version of the Use case and experience draft that is 
part of the WG charter. We've taken into account most of the comments 
received in June and have added some text on the utilisation of MPTCP 
proxies.

* 
https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt

This draft proposes a standard encoding for experimental MPTCP options. 
Given the small number of MPTCP options, it is important to allow 
experimenters to use MPTCP options without wasting this limited ressource.

https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-01.txt

This is an example of the utilisation of experimental options to encode 
a timestamp option

* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-00.txt

This draft discusses some issues with the advertisement of addresses in 
Multipath TCP and proposes a small modification to the handling of the 
address identifiers of the initial subflow to simplify implementations. 
It also shows how the reverse DNS can be used as an alternative to 
ADD_ADDR to announce the addresses of servers. This technique is already 
used for multipath-tcp.org

* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup-00.txt

This draft discusses some issues with the support of backup subflows in 
the existing Multipath TCP specification. In RFC6824 backup subflows 
work well when a subflow completely stops, but not when a subflow 
experiences huge losses.

* 
https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-long-options-00.txt

There have been many discussions on the TCPM working group about 
extending the space for TCP options in the TCP header. In this draft, we 
explore several ways of changing the DSS option to allow Multipath TCP 
to support long options.

Comments on any of those drafts are of course welcome. Some will be 
presented quickly in Prague but we won't probably have time to discuss 
all of them

Olivier

---

From: <[email-masked]>
Date: Thu, 9 Jul 2015 15:45:10 +0000

Olivier and colleagues,

Thanks for all the work. 

Please comment on the drafts - for instance, what things are worth adding to the protocol bis?

phil

> -----Original Message-----
> From: multipathtcp [mailto:[email-masked]] On Behalf Of
> Olivier Bonaventure
> Sent: 09 July 2015 16:05
> To: multipathtcp
> Subject: [multipathtcp] Submitted drafts
> 
> Hello,
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 10 Jul 2015 08:27:18 +0200

Phil,

>> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-

This draft would be a good candidate to be included in RFC6824bis.

>> * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-

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.

The other drafts are more improvements that do not necessarily need to 
go into rfc6824bis

Olivier

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 10 Jul 2015 10:36:00 -0700

Hello,

> This draft would be a good candidate to be included in RFC6824bis.

+1

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

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

Cheers,
Christoph

> 
> The other drafts are more improvements that do not necessarily need to go
> into rfc6824bis
> 
> 
> Olivier
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 10 Jul 2015 22:57:05 +0200

Christoph,

> Maybe we can use 8 bits of the key?

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

> 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

---

From: Christoph Paasch <[email-masked]>
Date: Sun, 12 Jul 2015 23:09:23 -0700

Hello,

On 10/07/15 - 22:57:05, Olivier Bonaventure wrote:
> We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented and
> replace it with a set of flags.
> 
>                           1                   2                   3
> 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.

Yes, I think it would be good to have such a reliable ADD_ADDR2 exchange.

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

Concerning the address-ID of the initial subflow, I am not sure whether it
is worth it to replace the complexity in the implementations of handling the
implicit zero address-ID, with a reliable empty ADD_ADDR-exchange (which
will also add complexity of its own).

If we could add the address-ID in the MP_CAPABLE it would be great (as this
will simplify a lot), but I understand that we do not want to lose
the entropy of the 64 bits.

In general, if the MP_CAPABLE could transport all the information that is
relevant for this subflow (address-ID and backup-bit), would be great.
Because, as of today, if a stack sends a SYN+MP_CAPABLE on a subflow that is
actually meant to operate as a "backup" subflow (as soon as another subflow with
higher priority can be established), a stack has to send an MP_PRIO
immediately after the 3-way handshake. The reliability of the MP_CAPABLE in
the SYN could actually get exploited to send such information immediately
(as is already done in the MP_JOIN).

Considering that the keys are already sent in plaintext, maybe the loss of
entropy is not such a big deal?

Cheers,
Christoph

---

From: Alan Ford <[email-masked]>
Date: Wed, 22 Jul 2015 16:21:49 +0100

Hi Olivier, all,

Inline...

> experimenters to use MPTCP options without wasting this limited ressource.
This met with consensus in the WG session yesterday and I'll wrap it into
the next version of the bis draft.

However, do we really need to use 2 bytes on the experiment ID? That seems
like a lot when we have very limited TCP option space. Surely we want to
minimise the overhead? Could we make do with a single byte here?

> address identifiers of the initial subflow to simplify implementations. It
> also shows how the reverse DNS can be used as an alternative to ADD_ADDR to
> announce the addresses of servers. This technique is already used for
> multipath-tcp.org

(I'll reply later in the thread re this)

>
> *
> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup-00.txt
>
> the existing Multipath TCP specification. In RFC6824 backup subflows work
> well when a subflow completely stops, but not when a subflow experiences
> huge losses.
>
>
As I mentioned in the WG session yesterday, I am not sure this needs any
protocol changes, but maybe some improvements to advice in the heuristics
section. It was always the intention that end hosts could use any kind of
indication they had available to trigger a change between subflows, so if
an implementor could shorten timeouts, or use some out-of-band triggers,
that would achieve the desired result.

Regards,
Alan

---

From: Alan Ford <[email-masked]>
Date: Wed, 22 Jul 2015 16:33:16 +0100

Hi all,

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

> Then the entropy for the key is lower because it is reduced to 56 bits.
Definitely thumbs-down for that I'm afraid!

> and replace it with a set of flags.

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