Subject: [multipathtcp] Comments on draft-amend-mptcp-robe-00

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 16 Jul 2019 15:13:12 +0000

Markus,

Thanks for submitting this draft. As I will not be able to participate 
to the discussion in Montreal, here are some initial comments on the draft.

First, I think that it would make sense to discuss the relation between 
your proposal and Happy Eyeballs. The problem of selecting between IPv6 
and IPv4 is not too far away from the problem of selecting between 
interface 1 and interface 2 in a multipath transport. Although from a 
delay viewpoint it makes sense to send a SYN simultaneously over two 
different interfaces to minimise the connection establishment time, this 
increases the cost in number of packets transmitted and load on the 
server that needs to be discussed in the draft.

AFAIK, this is how Apple's WiFi assist work to select the best interface 
based on dynamic network conditions. Other network managers probably 
behave similarly on other types of devices.

Second, the assumption of the draft is that the two SYNs sent by the 
client reach the same server. This may not be the case when there are 
load balancers or when the server uses an anycast address. In those 
cases, two connections are established when the two SYNs are 
transmitted. This should be discussed as large servers use these two 
techniques and Multipath TCP must remain compatible with them.

Third, it would be interesting to explore the cost of implementing this 
approach on heavily loaded servers.

Detailed comments

Figure 2 is not totally clear to me. The client has received two 
different MP_CAPABLE options that announce different keys and could come 
from different servers. The MP_JOIN_CAP proposes to change the Key-A to 
replace the Key-A' that was announced earlier on this interface ? It 
looks difficult to me to assume that the server has access to Key-B and 
Key-B' and can link them easily. Note that the SYNs could come through a 
NAT and thus one cannot rely on the IP addresses to identify that they 
are related.

I'm missing the context for using (crc16(Key-B) & 0x3FF).

[RFC6824]; Can match based on Key-A, same effort as for a MP
           JOIN.

In RFC6824, the match is done on the Token, which is a hash of the key. 
Why not using the token in this option ?

Best regards,

Olivier

---

From: <[email-masked]>
Date: Fri, 19 Jul 2019 15:34:29 +0000

Hi Olivier,

answers inline

> -----Original Message-----
> From: multipathtcp <[email-masked]> On Behalf Of Olivier
> Bonaventure
> Sent: Dienstag, 16. Juli 2019 17:13
> To: multipathtcp <[email-masked]>
> Subject: [multipathtcp] Comments on draft-amend-mptcp-robe-00
> 
> Markus,
> 
> Thanks for submitting this draft. As I will not be able to participate to the
> discussion in Montreal, here are some initial comments on the draft.
> 
> 

OK, will consider to add a section addressing the pro and cons compared
to existing mechanisms

> behave similarly on other types of devices.

Yes, however RobE can guarantee without any probing/estimation,
establishment, smallest delay and even a bandwidth boost for small
transmissions

> techniques and Multipath TCP must remain compatible with them.

Thanks for this hint. Should be mentioned in the draft. A simple solution
could be some negotiation... In case of MP_JOIN_CAP it could even be
just resetting the flow.

> approach on heavily loaded servers.

A prototypical implementation and evaluation is on the To-Do list. If
someone is keen to support please let me know. Would be for example a
good thesis topic for a student.

> different MP_CAPABLE options that announce different keys and could
> come from different servers.

Yes, in case of your aforementioned load-balancers

> The MP_JOIN_CAP proposes to change the Key-A to
> replace the Key-A' that was announced earlier on this interface ?

Yes, after selecting the initial path on client side based on the fastest SYN/ACK

> It looks difficult to me to assume that the server has access to Key-B and
> Key-B' and can link them easily.

No, relationship is identified on Key-A only, not on Key-A' or Key-B or Key-B'

> Note that the SYNs could come through a

See above

> I'm missing the context for using (crc16(Key-B) & 0x3FF).

That is just important in the unlikely case where the selected initial flow cannot
deliver the ACK before the MP_JOIN_CAP arrives. See 2nd bullet point in section
2.3.2. The fast_hash can be then used to make relationships between the not yet
Established initial flow and the MP_JOIN_CAP flow with minimal computing
overhead. That has also the benefit to overcome the reliable delivery of the final
ACK in MPTCP v1 before subsequent flows can be established.

> Why not using the token in this option ?

Because the token is not available at this time. In terms of calculation performance
it should not make any difference

> 
> Best regards,
> 
> 
> Olivier
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp