[multipathtcp] AD Review: draft-ietf-mptcp-architecture-03

[Lars Eggert <[e-mail]>]

Summary: good to go.

I'll start the IETF last call. Please take the comments below as last-call comments. I will make this last call longer than normal, due to the holiday season.

Lars


Section 1., paragraph 2:
>    By the application of resource pooling[3], these available resources

  Nit: s/pooling[3]/pooling [3]/  (also check other reference citations
  for a missing space before them)


Section 1.2., paragraph 0:
> 1.2.  Terminology

  I'd be somewhat useful to reorder the terms such that definitions
  appear before they are used, as much as possible.


Section 1.2., paragraph 2:
>    Path Identifier:  Within the context of a multi-addressed multipath
>       TCP, a path is defined by the source and destination (address,
>       port) pairs (i.e. a 4-tuple).

  Why is a Path identified by something that includes port numbers?
  Because of ECMP?


Section 1.2., paragraph 6:
>    Subflow:  A flow of TCP packets operating over an individual path,
>       which forms part of a larger Multipath TCP connection.

  s/packet/segment/ (please check this throughout the document, "packet"
  is often used where "segment" is meant)


Section 1.3., paragraph 4:
>    The scenario could have any number of addresses (1 or more) on each
>    host, so long as the number of paths available between the two hosts
>    is 2 or more (i.e. num_addr(A) * num_addr(B) > 1).  The paths created
>    by these address combinations through the Internet need not be
>    entirely disjoint - shared bottlenecks will be addressed by the
>    Multipath TCP congestion controller.

  "will be addressed" is imprecise. Maybe: "potential fairness issues
  introduced by joint bottlenecks need to be handled by..."


Section 1.3., paragraph 5:
>    Furthermore, the paths through
>    the Internet may be interrupted by any number of middleboxes
>    including NATs and Firewalls.

  Middleboxes don't really "interrupt" a path. Maybe rephrase with "are
  present"?


Section 1.3., paragraph 6:
>    Finally, although the diagram refers
>    to the Internet, Multipath TCP may be used over any network where
>    there are multiple paths that could be used concurrently.

  Not sure if there is much value in mentioning this. (Plus, we do
  assume an _IP_ network.)


Section 2.1., paragraph 3:
>    o  Improve Resilience: Multipath TCP MUST support the use of multiple
>       paths interchangeably for resilience purposes, by permitting
>       packets to be sent and re-sent on any available path.

  I think you mean "segments" (i.e., chunks of the bytestream) here, and
  not IP packets.


Section 2.1., paragraph 5:
>    As distribution of traffic among available paths and responses to
>    congestion are done in accordance with resource pooling
>    principles[3], a secondary effect of meeting these goals is that
>    widespread use of Multipath TCP over the Internet should optimize
>    overall network utility by shifting load away from congested
>    bottlenecks and by taking advantage of spare capacity wherever
>    possible.

  s/optimize/improve/ (it won't be optimal unless there is global
  deployment *and* the mechanism itself is optimal)


Section 2.2.1., paragraph 3:
>    A multipath-capable equivalent of TCP SHOULD retain backward
>    compatibility with existing TCP APIs, so that existing applications
>    can use the newer transport merely by upgrading the operating systems
>    of the end-hosts.

  Any reason why this is not a MUST? I think this is critical; otherwise
  we'd already have seen widespread use of SCTP.


Section 2.2.2., paragraph 1:
>    In the traditional Internet architecture, network devices operate at
>    the network layer and lower layers, with the layers above the network
>    layer instantiated only at the end-hosts.  While this architecture,
>    shown in Figure 2, was initially largely adhered to, this layering no
>    longer reflects the "ground truth" in the Internet with the
>    proliferation of middleboxes[8].  Middleboxes routinely interpose on
>    the transport layer; sometimes even completely terminating transport
>    connections, thus leaving the application layer as the first real
>    end-to-end layer, as shown in Figure 3.

  And even application level protocols often define roles for
  intermediaries, e.g., SIP and HTTP.


Section 2.4., paragraph 1:
>    standardised.  The de facto standard stream-based transport protocol

  s/de facto standard/by far most widely used/ (TCP *is* of course a
  standard...)


Section 3., paragraph 7:
>    behaving as a TCP flow in network, is an instantiation of the

  Nit: s/in network/in the network/


Section 4., paragraph 10:
>       shared bottlneck.  An algorithm to support this is specified in

  Nit: s/bottlneck./bottleneck./


Section 4., paragraph 12:
>    own sequence number, acks, and passes them to network.  The receiving

  Nit: s/acks,/ACKs,/


Section 5.1., paragraph 3:
>    receiver must determine how subflow-level data (carying subflow

  Nit: s/(carying/(carrying/


Section 5.1., paragraph 6:
>    be permissable for the mapping to be sent periodically and cover more

  Nit: s/permissable/permissible/


Section 5.2., paragraph 2:
>    to-end semantics.  It means that once a packet is acked at the

  Nit: s/acked/ACKed/


Section 5.2., paragraph 4:
>    a subflow traversing a transparent proxy: if the proxy acks a segment

  Nit: s/acks/ACKs/


Section 5.2., paragraph 6:
>    Therefore, to provide a fully robust multipath TCP solution, MPTCP
>    SHOULD feature explicit connection-level acknowledgements, in

  After all of this argumentation in the previous paragraphs, why is
  this not a MUST? Esp. since in the first paragraph you already say
  "MPTCP features..." which in essence is a MUST.


Section 5.2., paragraph 10:
>    maintain subflow integrity, as per the network compatiblity goal.  By

  Nit: s/compatiblity/compatibility/


Section 5.2., paragraph 11:
>    doing this, throughput will be wasted, and it is unclear at this
>    point what the optimal retransmit strategy is.

  I think "throughput will be wasted" sounds too harsh. Maybe "some
  efficiency is lost"?


Section 5.3., paragraph 6:
>    The resulting buffer size should be small enough for practical use.
>    However, there may be extreme cases where fast, high throughput paths
>    (e.g. 100Mb/s, 10ms RTT) are used in conjunction with slow paths
>    (e.g. 1Mb/s, 1000ms RTT).  In that case the required receive buffer
>    would be 12.5MB, which is likely too big.  In these cases a Multipath
>    TCP scheduler SHOULD use only the fast path, potentially falling back
>    to the slow path if the fast path fails.

  Please rephrase the last sentence so that it not specific to the
  example given, since we're trying to state a general rule here. Maybe:
  "it may be prudent to only use some of the fastest available paths for
  the MPTCP connection" or something like that


Section 5.4., paragraph 3:
>    The MPTCP protocol design will, however, use TCP Options for this
>    additional signalling.  This has been chosen as the mechanism most
>    fitting in with the goals as specified in Section 2. 

  Aside: Instead of using several different TCP Option numbers, I wonder
  if we can use one TCP Option Number for MPTCP and disambiguate based
  on the Length field what kind of MPTCP option we have? (Assuming all
  our different option kinds have different lengths...)


Section 5.5., paragraph 1:
>    Currently, the network does not expose multiple paths between hosts.

  This isn't really capturing it. The network *does* expose this, *if*
  the paths begin and end at different IP addresses. I think you mean
  that the network doesn't expose the availability of path diversity *in
  the network* for paths between the same two IP addresses.


Section 5.5., paragraph 2:
>    that these paths, whilst not necesarily entirely non-overlapping,

  Nit: s/necesarily/necessarily/


Section 5.5., paragraph 4:
>    Multiple different (source, destination) address pairs will thus be
>    used as path selectors in most cases.  Each path will be identified
>    by a TCP 4-tuple (i.e. source address, destination address, source
>    port, destination port), however, which can allow the extension of
>    MPTCP to use such 4-tuples as path selectors.  This will allow hosts
>    to use MPTCP to load balance to different ports, for example if the
>    network routes different ports over different paths (which may be the
>    case with technologies such as Equal Cost MultiPath (ECMP) routing
>    [16]).

  So actually, you use a five-tuple, it's just that the protocol number
  component is always 6 (TCP) in our case. There are ECMP schemes where
  the resulting paths are different when only the protocol number
  component is different. I'd prefer if we could talk about five-tuples
  and path IDs, since paths are not usually something that is specific
  to one transport protocol. (And you actually do already talk about
  five-tuples in the next section...)


Section 5.5., paragraph 6:
>    The modularity of path management will permit alternative mechanisms
>    to be employed if appropriate in the future.

  What modularity of path management? Nothing in this section so far
  talks about modularity. Suggest to drop this paragraph.


Section 5.8., paragraph 11:

>    o  The desire to support a 'break-before-make' (as well as a 'make-
>       before-break') approach to adding subflows implies that a host
>       cannot rely on using a pre-existing subflow to support the
>       addition of a new one.

  But I don't think we want to support "unlimited" break-before-make,
  i.e., just because we had the connection up yesterday doesn't mean I
  should still be able to join a new first flow into it today. In other
  words, we want to support break-before-make for some limited amount of
  break time only.


Section 7., paragraph 3:
>    just basic datagram delivery.  A miriad of middleboxes are deployed

  Nit: s/miriad/myriad/


Section 7., paragraph 15:
>    o  Segmentation and Colescing: middleboxes (or even something as

  Nit: s/Colescing:/Coalescing:/


Section 12.2., paragraph 7:
>    [9]   Carpenter, B., "Internet Transparency", RFC 2775,
>          February 2000.

  Unused Reference: '9' is defined on line 1108, but no explicit
  reference was found in the text