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

[Christoph Paasch <[e-mail]>]

Hello Phil,

On 17/07/18 - 23:30:15, [e-mail] wrote:
> 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?)
> 

thanks for the suggested text. I adopted it.

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

Sure, I annotated the figure.

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

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

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

Agreed - I will try to work on a proposal for this.

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

Fixed.

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

There is not really reliability of the ACK. Rather, piggy-backing of the
MP_CAPABLE on a data-segment, which implicitly makes the MP_CAPABLE reliable
thanks to the data's reliability.

I try to clarify this with the figure I will do.

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

It is allowed. It is not so much about the DSS-option itself, but rather any
MPTCP-option that is sent together with data.
I will try to clarify this as well.



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.



I created another Pull-Request at
https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/6.

To not lose track of outstanding tasks, I listed them in the issues-section
of the github: https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/issues

If anyone feels inspired to take onto one of these ... ;-)



Christoph