Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

[Christoph Paasch <[e-mail]>]

On 18/07/18 - 15:47:43, [e-mail] wrote:
> Something that needs fixing which Christoph and I just noticed during a chat at the IETF:
> 
> S3.7 on Fallback has 
> <<Note that this rule essentially prohibits the sending of data on the
>    third packet of an MP_CAPABLE or MP_JOIN handshake, since both that
>    option and a DSS cannot fit in TCP option space.>>
> this needs a mod now data is allowed on the third packet.
> 
> .....

Created
https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/issues/12.

> 
> > 
> > [phil] ok - if I get it right the motivation for the change in the MP_CAPABLE protocol exchange starts from the observation that option space is most constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN allows other TCP options to be used in the SYn. As a consequence of this decision, Host A doesn't know that Host B has learnt its key, unless the ACK is sent reliably.  
> 
> The story actually unfolded the other way around. We identified a need for reliable key-exchanges when talking to stateless servers. Based on this we made the key-exchange reliable in the third ACK/first data segment.
> 
> Upon this, we realized that we can gain space in the SYN.
> 
> Thus, the motivation for the change was the need for the reliable MP_CAPABLE.
> 
> > I think it would be useful to tweak the figure in Section 2.1 - just to say the ack is delivered reliably. 
> 
> Incorporating it into the figure seems tricky to me. I changed the first sentence to mention data as well: "... initial ACK (and data) packets also ..."
> 
> [phil2] the figure in S2.1 (ie in the Operation Overview section) should be modified. As it is compulsory to send the MP_CAPABLE ACK message on the first data packet. Sending MP_CAPABLE ACK without data is done if host A doesn't have data to send, but you still have to send ACK later with the first data. Whereas the natural way to interpret the current fig in S2.1 is that the Ack is sent once.

I will rework this as I review the whole MP_CAPABLE exchange.

> 
> 
> ......
> 
> I have another comment. In Section 3.1, there is:
> 
> If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored.
> 
> 
> I suggest to change this to "... then the MP_CAPABLE in this SYN MUST be silently ignored.". Otherwise, hosts setting the B-bit to test for a feature-capability will incur a SYN-retransmission timeout, which is a huge latency penalty.
> 
> Please let me know if that is acceptable.
> 
> [phil2] fine by me - please make it clear this means fallback to TCP (as in similar text for other cases where we fallback)

Incorporated it into
https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/6.


Cheers,
Christoph