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

From: Alan Ford <[email-masked]>
Date: Fri, 25 May 2012 11:17:02 +0100

Hi Yoshifumi,

Thank you for your feedback. Anything I haven¹t directly commented on below
was straightforwardly addressed in 08. If there is anything you feel wasn¹t
sufficiently addressed, please shout.

Regards,
Alan

On 18/04/2012 07:03, "Yoshifumi Nishida" <[email-masked]> wrote:

> 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:
>> 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.
>> 
>> [Alan] Unique per host, yes. I believe that is clear already; certainly, I
>> couldn¹t find a way of making it any clearer.
>> 
>> 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.
>> 
>> [Alan] Yes it does, and I have clarified that.
>> 
>> 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.
>> 
>> [Alan] It¹s a completely different exchange, sending completely different
>> information: it¹s a crypto handshake not a key exchange. I had hoped that
>> would have been sufficiently clear, but I¹ve added a few words anyway.
>>    
>> 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..
>> 
>> [Alan] Changed to ³Both hosts SHOULD send FINs on all subflows, as a courtesy
>> to allow middleboxes to clean up state even if an individual subflow is no
>> longer operational end-to-end.². This is in the case if a link has failed in
>> the path somewhere, but one of the end hosts is behind a middlebox. That host
>> would never receive a FIN on the subflow, and neither would the middlebox.
>> But the end host knows the subflow should be closed, so by sending a FIN it
>> aids in cleaning up.
>> 
>>    ..
>>    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..
>> 
>> [Alan] Changed to ³As specified above, a standard TCP FIN on an individual
>> subflow only shuts down the subflow on which it was sent.²
>> 
>> 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?
>> 
>> [Alan] Not at all. It says you can¹t remove a functioning subflow with
>> REMOVE_ADDR, you must use a FIN exchange.
>> 
>> 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 .
>> 
>> [Alan] I don¹t want to restrict what implementations do in this state  we
>> don¹t care what happens if MPTCP isn¹t going to be used.
>> 
>>    If packets with the MP_JOIN option are dropped, the paths will simply not
>> be used.
>> 
>>     -> MUST NOT be used?
>> 
>> [Alan] It¹s not a restriction, it¹s a consequence of the MPTCP handshake. If
>> it¹s dropped, it¹s a fact it won¹t be used since the receiver cannot know the
>> packet turning up has anything to do with an MPTCP connection.
>> 
>> 
>> 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.
>> 
>> 
> 
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 30 May 2012 00:49:42 -0700

Hi Alan,

Thank you so much for updating the draft. I agree the updates in the draft
and comments in your mail.
Just one very minor thing..

connection.

>> [Alan] Unique per host, yes. I believe that is clear already; certainly,
I couldn’t find a way of making it any clearer.

I might be too picky. But,  I thought "The key MUST be hard to guess, and
it MUST be unique for the sending host at any one time." might not be very
clear if a unique key is assigned to individual mptcp connection or not.
We might be able to guess it from "Connections will be indexed at each host
by the token", but I'm thinking explicit expression might be better..

Thanks,
--
Yoshifumi

On Fri, May 25, 2012 at 3:17 AM, Alan Ford <[email-masked]> wrote:

>  Hi Yoshifumi,
>
> Thank you for your feedback. Anything I haven’t directly commented on
> below was straightforwardly addressed in –08. If there is anything you feel
> wasn’t sufficiently addressed, please shout.
>
> Regards,
> Alan
>
>
> 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:
>
> Hello,
>
> couldn’t find a way of making it any clearer.
>
> Page 17:
>     -> Since this is MUST, I think Figure 8 needs to include this ACK in
> the sequence.
>
>
> [Alan] It’s a completely different exchange, sending completely different
> information: it’s a crypto handshake not a key exchange. I had hoped that
> would have been sufficiently clear, but I’ve added a few words anyway.
>
> Page 27:
>
>    Both hosts SHOULD send FINS, as a courtesy to allow middleboxes to
> clean up state even if the subflow is failed.
> [Alan] Changed to “Both hosts SHOULD send FINs on all subflows, as a
> courtesy to allow middleboxes to clean up state even if an individual
> subflow is no longer operational end-to-end.”. This is in the case if a
> link has failed in the path somewhere, but one of the end hosts is behind a
> middlebox. That host would never receive a FIN on the subflow, and neither
> would the middlebox. But the end host knows the subflow should be closed,
> so by sending a FIN it aids in cleaning up.
>
>    ..
>    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.
>
> [Alan] Changed to “As specified above, a standard TCP FIN on an individual
> subflow only shuts down the subflow on which it was sent.”
>
> Page 30:
>
> [Alan] Not at all. It says you can’t remove a functioning subflow with
> [Alan] I don’t want to restrict what implementations do in this state – we
> don’t care what happens if MPTCP isn’t going to be used.
>
>    If packets with the MP_JOIN option are dropped, the paths will simply
> not be used.
>
>     -> MUST NOT be used?
>
> [Alan] It’s not a restriction, it’s a consequence of the MPTCP handshake.
> If it’s dropped, it’s a fact it won’t be used since the receiver cannot
> know the packet turning up has anything to do with an MPTCP connection.
>
>
> Page 51:
>
> ------------------------------