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

[<[e-mail]>]

In-line
Thanks
phil
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: 15 July 2018 16:15
To: Eardley,PL,Philip,TUD1 R <[e-mail]>
Cc: [e-mail]
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

...

> 
> S3.9.2
> << If the two communicating hosts immediately try to set up subflows
>    from all available addresses to all available addresses on the other
>    host, this could end up creating two subflows per path.  This is an
>    inefficient use of resources.>>
> is two subflows correct? Multiple I think

It would be two subflows on each path (one being initiated by each host).

[phil] ok. Can the para be re-phrased so it's clear this is about a new situation (compared to the earlier paras). Something like, "Another issue is that both communicating hosts may simultaneously try to set up a subflow between the same pair of addresses. This leads to an inefficient use of resources." (I suppose 'inefficient resources'  refers to resources on the end host?)

...


> 
> << client                                                         server
>      |                                                              |
>      |    S 0(0) <MP_CAPABLE>, <TFO cookie request>                 |
>      | -----------------------------------------------------------> |
> >>
> Can you explain the S 0(0) nomenclature/ please.

tcpdump-style sequence number and length of the segment.

Is it ok, if I change the figure for the first time we use this notation to:
S Seq=0(Length=0)

And from there on leave the one we have now?

[phil] yes - I suggest in the first figure you add a key that explains the notation and states it's used in Figures x, y, z.


> 
> 
> Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so 
> that Host A's key is sent only on the ACK (not on the SYN)? Is this so 
> it's only sent when we know host B is MPTCP capable, which is 
> therefore a slight security improvement?  (Just send a link to earlier 
> emails, if that's easier)

The reason for this is because now that we send the keys reliably in the third ACK / first data-segment, we actually don't need to send the key in the SYN anymore. Thus, we can reduce the size of the MP_CAPABLE in the SYN-segment and gain some bytes.

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

I think it would be useful to tweak the figure in Section 2.1 - just to say the ack is delivered reliably. 
However in Section 3.1 I think it would be good to include a more extensive figure about this - showing the different ways & timings for when the ack is known to have been delivered - ie figure showing somehow that A or B may be one that first sends data - and therefore when A knows that the ACK has indeed been successfully delivered to B.
The actual text (in the para starting " If B has data to send first, then the reliable delivery of the ACK...") is pretty good - however, there are a lot of "this packet", "this is" etc - likely that someone could misinterpret what a "this" refers to. A figure would help clarify and/or breaking the text up .



Also I spotted
<< This option is used to declare the 64-bit keys that the end hosts     
    have generated for this MPTCP connection.  This key is used to     
    authenticate the addition of future subflows to this connection.>>
This key is -> These keys are ...

<< Therefore, A's key must be delivered reliably to B, and in order to     
    do this, the transmission of this packet must be made reliable.>>
is it right to say that the protocol makes transmission of the ACK reliable?   Suppose the Ack is lost. The protocol ensures that A doesn't have the mistaken belief that B has got the Ack. But does it say anything about how /when A sends the Ack again?  (perhaps it should say something about this?)


<< Note that new subflows MUST NOT be established
   (using the process documented in Section 3.2) until a Data Sequence
   Signal (DSS) option has been successfully received across the path
   (as documented in Section 3.3).>>
In the case where A sends data first, then the MP-CAPABLE is sent instead of the DSS. Does the text quoted mean that new subflows are not allowed (until an actual DSS is sent) or are they allowed because DSS has kind of been inferred?