Subject: Re: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-symmetric-02.txt

From: <[email-masked]>
Date: Thu, 2 Apr 2015 13:06:11 +0000

Hi Yoshi,

Thank you for the review.

Please see in line.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : mercredi 25 mars 2015 07:58
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-symmetric-02.txt

Hi Med,

I have read the draft. I agree with the motivation of the draft, but I'm not very sure if we need to extend or develop an option yet.

[Med] The current version does not voice any preference among the three flavors listed in the document. Olivier suggested to redefine “IPVer” field as a “flags” field. Using a flag bit from that field would be fine for draft-boucadair-mptcp-symmetric.

My comments are below...

1: I think you will need to use ADD_ADDR2 instead of ADD_ADDR in future versions as ADD_ADDR will be deprecated.

[Med] Fixed in my local copy, thanks.

2: mptcp cannot guarantee if it can receive incoming flows as it depends on external mechanisms.
    So, I'm not very sure how much the check flag can be useful.

[Med] Incoming packets can be received if appropriate mappings are installed in firewalls/NATs that service a given device. Preparing those mappings is of course out of scope of MPTCP, but other means can be used (PCP is mentioned as an example in the draft). Once those mappings are correctly instantiated, the procedure defined in draft-boucadair-mptcp-symmetric allows to notify the remote peer.

3: From the same reason above, I'm also not very sure about the lifetime info, either.

[Med] There is already some text in the draft that explains the reason: e.g., anticipate migrating the traffic to a new sub-flow, address selection process to avoid addresses with too short lifetimes, etc. BTW, the use of the lifetime is aligned with what has been presented by B. Trammel in the technical plenary in Dallas (http://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-3.pdf):

“A2P  (app  to  path):  problem  appears  tractable,  there  is  a  minimal  set
of  useful  information  (e.g.  session  lifetime)  which  can  be  exposed,
and  is  anyway  useful  to  the  far  endpoint”

The lifetime discussion can be separated from the one about the “path validation checks”.

    Also, even if an endpoint tries to use a staled address for a new subflow, I think it will fail since the peer won't be able to send back a proper token.

[Med] The idea of sending the lifetime is to avoid such delay to get established additional sub-flows.

Thanks,
--
Yoshi

On Thu, Mar 12, 2015 at 8:50 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

We submitted this short I-D.

Comments are welcome.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] De la part de
> [email-masked]<mailto:[email-masked]>
> Envoyé : lundi 9 mars 2015 13:36
> À : [email-masked]<mailto:[email-masked]>
> Objet : I-D Action: draft-boucadair-mptcp-symmetric-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : An Extension to MPTCP for Symmetrical Sub-Flow
> Management
>         Authors         : Mohamed Boucadair
>                           Christian Jacquenet
>       Filename        : draft-boucadair-mptcp-symmetric-02.txt
>       Pages           : 7
>       Date            : 2015-03-09
>
> Abstract:
>    This document specifies a MPTCP extension that allows to achieve
>    symmetrical subflow management.  In particular, this extension allows
>    both endpoints to add new subflows whenever needed without waiting
>    for the endpoint which initiated the first subflow to add new ones.
>
>    This document updates RFC 6824.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-symmetric/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-symmetric-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 6 Apr 2015 00:55:27 -0700

Hi Med,

Thanks for the response. I put some comments in lines.

On Thu, Apr 2, 2015 at 6:06 AM, <[email-masked]> wrote:

> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* mercredi 25 mars 2015 07:58
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [email-masked];
> [email-masked]
> *Objet :* Re: [multipathtcp] TR: I-D Action:
> draft-boucadair-mptcp-symmetric-02.txt
>
>
>
> Hi Med,
>
>
>
> I have read the draft. I agree with the motivation of the draft, but I'm
> not very sure if we need to extend or develop an option yet.
>
>
>
> [Med] The current version does not voice any preference among the three
> flavors listed in the document. Olivier suggested to redefine “IPVer” field
> as a “flags” field. Using a flag bit from that field would be fine for
> draft-boucadair-mptcp-symmetric.
>

OK. I think redefining IPver field might be a good idea, although we will
need to think about how to use the flags.

> [Med] Incoming packets can be received if appropriate mappings are
> installed in firewalls/NATs that service a given device. Preparing those
> mappings is of course out of scope of MPTCP, but other means can be used
> (PCP is mentioned as an example in the draft). Once those mappings are
> correctly instantiated, the procedure defined in
> draft-boucadair-mptcp-symmetric allows to notify the remote peer.
>

Hmm.. But, what we should do when C flag is not set?
Can't we just send an ADD_ADDR when we think it's ready to use?

> [Med] There is already some text in the draft that explains the reason:
> e.g., anticipate migrating the traffic to a new sub-flow, address selection
> process to avoid addresses with too short lifetimes, etc. BTW, the use of
> the lifetime is aligned with what has been presented by B. Trammel in the
> technical plenary in Dallas (
> http://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-3.pdf
> ):
>
>
>

Well, lifetime info might be useful. But, if a peer can know the lifetime
of the mapping table, I think it can re-negotiate before the expiration of
it.
This means, it can get a new mapping or can extend the current mapping.
Either case, it might not need to tell the lifetime to the remote peer.
In case where it failed to get the mapping, it can send a REMOVE_ADDR.

>
>     Also, even if an endpoint tries to use a staled address for a new
> subflow, I think it will fail since the peer won't be able to send back a
> proper token.
>
>
>

Ok. I see.

Thanks,
--
Yoshi

>
>
> On Thu, Mar 12, 2015 at 8:50 AM, <[email-masked]> wrote:
>
> Dear all,
>
> > De : I-D-Announce [mailto:[email-masked]] De la part de
> > [email-masked]
> > À : [email-masked]
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > [email-masked]
> [email-masked]