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

[Olivier Bonaventure <[e-mail]>]

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