Subject: [multipathtcp] comments on draft-ietf-mptcp-multiaddressed-07

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 16 Apr 2012 23:53:38 -0700

Hello,

Sorry for the long delay.
We believe it's good time to proceed to submit
draft-ietf-mptcp-multiaddressed to IESG.

Here's my comments on the draft to prepare a write-up for the draft.
Please check and update if you agree with them.

Thanks,
--
Yoshifumi

Page 13:
  3.1. Connection Initiation

    ->  In my understanding, the key MUST be unique for each mptcp
connection.
         If so, I think we had better articulate it here.

Page 17:
   A host MUST store the Address IDs associated with all established
subflows.

   -> Does this mean both local Address IDs and remote Address IDs
advertized from the receiver?
       It might be better to clarify this.

Page 18:
   therefore receipt of this packet MUST trigger an ACK in response

   -> Since this is MUST, I think Figure 8 needs to include this ACK in the
sequence.

   the packet MUST be retransmitted if this ACK is not received.

   -> In case of MP_CAPABLE, the third packet is not retransmitted.
       But, in case of MP_JOIN, it's retransmitted. Readers might want to
know the rationale about this.

Page 27:

   Essentially, a host MUST NOT FIN all functioning subflows unless it is
safe to do so

    -> MUST NOT close?

Page 28:

   Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to clean
up state even if the subflow is failed.
   -> I'm not very sure which situations can be addressed by this..
   ..
   Note that a host may also send a FIN on an individual subflow to shut it
down, but this impact is limited to the subflow in question.

   -> Sorry. I couldn't understand this sentences well..

Page 30:

    The sender also remembers the receive windows advertised by each
subflow.

    -> Don't we need to put SHOULD or MUST here?

    The send buffer must be, at the minimum, as big as the receive buffer

    -> MUST?

    When doing this, a host must still retransmit the original data on the
original subflow,

    -> MUST?

Page 37:

   if a response is received, the path is not removed.

   a subflow that is still functioning MUST be closed with a FIN exchange

    -> Aren't these sentences inconsistent?

Page 40:

   fallback to regular TCP can become necessary at any point during a
connection if a non-MPTCP-aware middlebox changes the data stream.

    -> The paragraph below this suggest when multiple subflows are in use,
the affected subflow must be terminated, but not suggesting fallback.
         So, fallback seems not to be necessary?

   Therefore, it is not possible to recover the subflow, and the affected
subflow must be immediately closed with an RST.

    -> MUST?

   Failed data will not be DATA_ACKed.

    -> MUST NOT be DATA_ACKed?

Page 47:

   If this is dropped, MPTCP SHOULD fall back to regular TCP.

    -> may be MUST? since we cannot continue to use MPTCP .

   If packets with the MP_JOIN option are dropped, the paths will simply
not be used.

    -> MUST NOT be used?

Page 51:

   Should use RFC6234 instead of RFC4634

Page 52:

   Should use RFC5681 instead of RFC2581
   Should use draft-ietf-tcpm-secury-03 instead of -02
   Should use draft-ietf-mptcp-api-04 or 05? instead of -03

There are some typos in the doc. Please update them by some tools.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 17 Apr 2012 23:03:30 -0700

Hi authors,

Sorry. I would like to add one more thing.

This draft requires to create new registries for subtypes of mptcp option
and cryptographic algorithms handshake in MP_CAPABLE.
For this, you will need to add the description of the policy used for
managing these registries in the IANA considerations section. Please check
the section 4 of RFC5226 to see the available choices (Section 4.1) and
update the texts based on the guideline (Section 4.2).

Thanks,
--
Yoshifumi Nishida

On Mon, Apr 16, 2012 at 11:53 PM, Yoshifumi Nishida
<[email-masked]>wrote:

>    -> Since this is MUST, I think Figure 8 needs to include this ACK in
> the sequence.
>
>
>    Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to
> clean up state even if the subflow is failed.
>    Note that a host may also send a FIN on an individual subflow to shut
> it down, but this impact is limited to the subflow in question.
>