Hello, > On Nov 5, 2019, at 4:18 AM, Paolo Abeni wrote: > > hi, > > while testing the v1 MP_CAPABLE handshake, I stumbled upon the > following scenario: > > syn + MP_CAPABLE -> > > <- syn + ack + MP_CAPABLE(sndr key) > > ack + MP_CAPABLE(sndr key, rcvr key) > > <- ack + DSS(map,data_ack) > > At this point, is the client still supposed to send MP_CAPABLE(sndr > key, rcvr key, data_len)? or should it send a plain DSS? Since it > received a DSS from the peer, the client knows that the MP_CAPABLE > options has been successfully received, but reading > > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/?include_text=1 > > from section 3.1.: > > """ > If A does not > immediately have data to send, it MUST include the MP_CAPABLE on the > third ACK, but without the additional data parameters. When A does > have data to send, it must repeat the sending of the MP_CAPABLE > option from the third ACK, with additional data parameters. > """ > > it looks like the client should always use MP_CAPABLE+data for the > first data packet, is that right? no, not always. Once the client receives a valid DATA_ACK from the server it knows that the server did receive the keys. This is somehow mentioned at: If B has data to send first, then the reliable delivery of the ACK+MP_CAPABLE can be inferred by the receipt of this data with a MPTCP Data Sequence Signal (DSS) option (Section 3.3 ). The draft says that the delivery can be inferred by the receipt of this data with a DSS-option, but it should actually read "by the receipt of a DATA_ACK". I actually mentioned that to Alan (https://mailarchive.ietf.org/arch/msg/multipathtcp/Mo-bvEcMEodPph8rTpylFMQ85IE ) and suggested text to him in private, but that text never made it into the draft. Do you want to send an e-mail to the IETF mailing-list to correct this? The text I suggest would be: "If B has data to send first, then the reliable delivery of the ACK can be inferred by the receipt of this data with an MPTCP DATA_ACK inside the DSS option (Section 3.3)." Christoph > > Thanks, > > Paolo >