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

[<[e-mail]>]

Hi Olivier,

answers inline


> -----Original Message-----
> From: multipathtcp <[e-mail]> On Behalf Of Olivier
> Bonaventure
> Sent: Dienstag, 16. Juli 2019 17:13
> To: multipathtcp <[e-mail]>
> 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.
> 
> 
> 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.

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

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

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

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

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.

> Third, it would be interesting to explore the cost of implementing this
> 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.

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

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
> NAT and thus one cannot rely on the IP addresses to identify that they
> are related.

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.

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp