Hello,

sorry for writing this so late (8 days left until the end of the LC),
but I only now had the time to do a full read of the draft.

I have several comments concerning the draft as you can see below.


============
* Retransmission of the third ACK, to ensure reliable delivery of the
keys in MP_CAPABLE (page 14):

The retransmission of the third ack was introduced to allow lost third
acks, if the server is operating stateless. However, this introduced an
additional RTT before the client is able to send data and thus, we now
allow the client to send data before he receives the acknowledgment of
his third ack (in PRE_ESTABLISHED state).

I now realize, that the retransmission does not buy us a lot:

E.g., if the third ACK gets lost, but the client already starts to send
data and this data reaches the stateless server.
The server then can only send a subflow-ack without DATA_ACK and thus
behave as in regular TCP.
The client then should interpret this subflow-ack not as the one
acknowledging the third ack (the one with the MP_CAPABLE), but rather
fallback to regular TCP. Because, otherwise the client and server are no
more in-sync.

Thus, the retransmission only buys us something if the server is
behaving stateless, the third ack got lost and the server is the one
trying to send data first. This same problem is already present for
stateless servers operating with regular TCP.

I'm not sure that this current behavior of sending data in
PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and
the first data-packet got lost, but the second data-packet reaches the
server? - the server sends a duplicate subflow-ack without
MPTCP-options. How will the client interpret this subflow-ack?).

I think we should remove the retransmission of the third ack, as it does
not buy us a lot, and keep with the simpler and more straight-forward
mechanism of not caring about lost third-acks (as in draft v02).


============
* Note about pre-established state for *new* subflows (page 19, second
paragraph):

It is not clear to me, if we are allowed to send data on new subflows
while we are still in PRE_ESTABLISHED state. Because for the initial
subflow it is allowed.

If we are allowed to send data on new subflows while in PRE_ESTABLISHED,
it does not really make sense to differentiate between PRE_ESTABLISEHED
and ESTABLISHED for the additional subflows.

However, on page 21, we say that "If Host B does not receive the
expected MAC, or the MP_JOIN option is missing from the ACK, it MUST
close the subflow with a TCP RST."
Thus, I would say that we are not allowed to send data while in
PRE_ESTABLISHED state for new subflows. So, we should clearly specify
that this behavior is different for MP_JOIN's than for MP_CAPABLE's.


============
* Duplicate ACK's with an MPTCP-option should not be considered as
signals of congestion (first paragraph of page 13 and page 45,
"Duplicate ACK"):

I think, we should limit this to duplicate ACK's, containing either
REMOVE_ADDR, ADD_ADDR, MP_PRIO or MP_FAIL.

Otherwise, we have to make sure that we do not put DATA_ACK in duplicate
ack's (which is not so easy to do from an implementation point-of-view).
Additionally, it should be allowed to put a DATA_ACK in a duplicate ack,
because this DATA_ACK may advance the snd_una (due to data arrived on
another subflow).
And, the faster we get the info back for the new snd_una, the better it
is for MPTCP's performance (e.g., the other subflow may have a high RTT).


============
* page 25: "If a mapping for that subflow-level sequence space does not
arrive within a receive window of data, that subflow SHOULD be treated
as broken,..."

This is needed, because we allow to receive a DSS-mapping for a certain
subflow-sequence-space on a packet whose sub-sequence-numbers do not
belong to this space.

I suggest, that we do not support this due to several reasons:

1. why should an implementation decide to send the DSS-mapping on a
packet belonging to a different seq-space than specified in the
DSS-mapping-option.

2. if we do it, and we store a full receive-window, we have to use quite
a lot of memory before treating the subflow as broken.
If we would only support DSS-mappings on packets who belong to this
sequence-space, we can drop the data as soon as we receive a subsequence
packet on this subflow with a DSS-mapping that does not cover the
previous sequence-space (e.g., this happens in case of coalescing
middleboxes). And, if we don't receive mappings, we can drop data as
soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB.


============
* p.27, Section 3.3.3: "Note that when the DATA FIN is not attached to a
TCP segment containing data, the Data Sequence Mapping MUST have Subflow
Sequence Number of 0."

I don't see, why this is needed (we don't implement this - and
DATA_FIN's are still working very fine).
Couldn't we drop this paragraph for simplicity?


============
* p.29, Section 3.3.5: "It should only update its local receive window
values when the largest sequence number allowed increases."

Why not as in RFC 793, p.72:
"If SND.UNA < SEG.ACK =< SND.NXT, the send window should be updated.  If
(SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and SND.WL2 =< SEG.ACK)), set
SND.WND <- SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK."

This is in my opinion more correct than the sentence in our draft. Maybe
we could just reference RFC793 in the mptcp-draft.


============
* p. 41: "If it is known that all unacknowledged data in flight is
contiguous..."

Does it really need to be contiguous?

Because, basically when falling back, the sender of the MP_FAIL
(data-receiver) will discard all data he receives after the
DATA-sequence-number which triggered the fallback. Only packets after
the infinite-mapping option will be allowed. Otherwise, we may have a
corrupted byte-stream presented to the application.
Thus, the data-sender (after receiving the MP_FAIL) will just send the
infinite-mapping option on the next packet. Irregardless, if the data
in-flight is contiguous or not.


============
Some minor nits:

p.8, Section 2:
"...between two hosts communicating hosts like..."

One "hosts" too much.

p.10, Section 2.4:
"...number space and a MPTCP option..." -> "...number space and an MPTCP
option..."

p.10, Section 2.4:
In the figure detailing the content of the DSS-option, DATA_LEN is missing.

p.26, Section 3.3.2:
"... to the behaviour of the standard TCP cumulative ACK in TCP SACK"
Not the ack in TCP SACK. It's just the usual standard TCP cumulative ACK.

p. 45:
"Instead an explicit data-level ACK is This separate subflow- and..."

This sentence got somehow mixed with something else.



Cheers,

Christoph



On 01/31/2012 06:58 PM, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF.
> 
> 	Title           : TCP Extensions for Multipath Operation with Multiple Addresses
> 	Author(s)       : Alan Ford
>                           Costin Raiciu
>                           Mark Handley
>                           Olivier Bonaventure
> 	Filename        : draft-ietf-mptcp-multiaddressed-06.txt
> 	Pages           : 60
> 	Date            : 2012-01-31
> 
>    TCP/IP communication is currently restricted to a single path per
>    connection, yet multiple paths often exist between peers.  The
>    simultaneous use of these multiple paths for a TCP/IP session would
>    improve resource usage within the network, and thus improve user
>    experience through higher throughput and improved resilience to
>    network failure.
> 
>    Multipath TCP provides the ability to simultaneously use multiple
>    paths between peers.  This document presents a set of extensions to
>    traditional TCP to support multipath operation.  The protocol offers
>    the same type of service to applications as TCP (i.e. reliable
>    bytestream), and provides the components necessary to establish and
>    use multiple TCP flows across potentially disjoint paths.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 


-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--