Subject: Re: [multipathtcp] New MPTCP Drafts

From: <[email-masked]>
Date: Mon, 12 Jul 2010 18:14:30 +0100

Alan

Here are some brief comments on the architecture draft

It basically seems good to me.

S2.1
>>   A host supporting Multipath TCP that requires the other endpoint to
   do so too must be able to detect reliably whether this endpoint does
   in fact support the next-generation protocol, using it if so, and
   otherwise automatically falling back to the legacy protocol.

Suggest calling them MPTCP & TCP, rather than next generation and legacy!

S2.2.2
Falling back to TCP should be mentioned here as a requirement on Network compatibility. As a MUST

S3
I'm not entirely convinced how useful this section is. probably a fresh reader to MPTCP should comment.
In figure 6, 'TCP' would be better replaced with 'Subflow TCP' or something similar to what's in Fig 7

S4
This could do with another edit to tighten it. I think perhaps just talk about the functions here - don't mix in high level design decisions, which are explained better in S5.

S5.1
I thought the rationale for the data seq mapping could be explained a bit better.

S5.4
Please add the decision about options vs payload, once that decision is made

S5.6
Worth explining briefly the purpose of the connectioon identifier?
Could give an example of how app would specifically ask for particular address [I think it might be possible to misinterpret the sentence]

S5.8
Please add the high level decisions about congestion control, something like:
- "linked increases": the increase phase of the congestion avoidance state is modified, compared with TCP's, by linking togather the increase phases of the subflows for a MPTCP connection, meaning that...
- The slow start, fast retransmit, and fast recovery algorithms, as well as the multiplicative decrease of the congestion
   avoidance state are the same as in TCP

S5.9
There should be an extra section on high level decision about security. Ie baseline is same as sctp [explain] (unless there have been further thoughts since the last ietf)

S8 & 9 should be before the Summary section

S9
Thanks for this section - I think it will be very useful for readers. Inclined to think could have more text in this doc - may comment further when read the protocol doc

I think it could be made clearer to what extent we hope /expect/ require MPTCP to operate through middleboxes. In particular if there's more than one NAT. earlier the doc says mptcp should work however many nats there are on the path - is this really true? Will adding more paths work? My impression was that the ability to signal about a new path from either end should enable mptcp to work through one nat reliably, but if there are 2 nats on the path, things are less certain.

>>In effect, future applications must mimic
   existing ones if they want to be deployed.
Seems a bit strong - makes apps easier to deploy. The point is that in general the issue is more important /severe for MPTCP than for apps, since MPTCP wants to be a universal transport.

>From the bulleted list, separate out tcp options & segmentation, since the others are types of middlebox

>>unlikely to permit holes in sequence space
You could clarify which seq space you mean

TCP options
I guess this bullet will be expanded after the options vs payload discussion has converged.

>>For future MPTCP-
      aware middleboxes, they will require the ability to correlate the
      various paths in use.
=> Future MPTCP-aware middleboxes may even correlate traffic sent over the various paths of a MPTCP connection.

Thanks
phil

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ford, Alan
> Sent: 22 June 2010 10:52
> To: [email-masked]
> Subject: [multipathtcp] New MPTCP Drafts
>
>
> Hi all,
>
> As you'll have seen, we have made new submissions of the
> Architecture and Protocol drafts.
>
> The architecture draft is fairly mature at this stage - a few
> minor additions were made in this submission (notably about
> middleboxes). We would be very keen to get reviews of this document.
>
> The protocol draft has had a number of significant changes,
> the highlights of which are:
> * Significant clarification of receive window behaviour and
> interactions with DATA_ACK
> * Subflow setup heuristics
> * Fixed (hopefully!) consistency of option naming; option
> size analysis; clarifications of when they should be used
> * Checksum and fallback mechanisms for error detection (to
> work around/with payload-changing middleboxes)
> * Added optional Port to ADD_ADDR; clarified behaviour of
> REMOVE_ADDR to avoid hijacking
> * Better documentation of error cases when options are lost;
> and other improved examples
> * Further middlebox discussion
>
> Once again we are very keen on receiving comments, questions
> and feedback, and indeed full reviews, of this document. An
> appropriate security mechanism for the handshake is one open
> issue that still remains; we have a few ideas in the draft at
> the moment but would be interested in any suggestions.
>
> We are working on a lightweight, straw-man draft documenting
> a possible way to achieve MPTCP with payload encoding. We
> intend this to act as a worked example in resolving further
> discussion about options-vs-payload as a way to encoding
> MPTCP signalling.
>
> Regards,
> Alan
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipat> htcp
>