Re: Mirja Kühlewind's Discuss on draft-ietf-d mm-mag-multihoming-04: (with DISCUSS and COMMENT)

On Wed, Aug 2, 2017 at 4:46 AM, <[email protected]> wrote:

> Hello Mirja,
>
> Thanks for the comments. We will update the document accordingly; please
> see inline for resolution.
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : dmm [mailto:[email protected]] De la part de Mirja Kühlewind
> > Envoyé : lundi 31 juillet 2017 23:49
> > À : The IESG
> > Cc : [email protected]; [email protected];
> > [email protected]
> > Objet : [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-mag-
> multihoming-04:
> > (with DISCUSS and COMMENT)
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-dmm-mag-multihoming-04: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > 1) This document should not recommend the use of MPTCP for tunneling, as
> TCP-
> > in-TCP tunnels are generally not recommend if that can be avoided.
>
> The document does not recommend such a thing... the document leverages
> PMIP (RFC5213) tunneling mechanisms, i.e. IP-in-IP, GRE, ...
>
> Please remove
> > the following part from section 3.2 and leave IP-level tunneling as the
> only option:
> > „Packet distribution can be done either at the transport level, e.g.
> using MPTCP …“
> >
>
> Ok, we will remove the sentence. But just to clarify: this sentence refers
> to MPTCP as packet distribution scheme, not tunneling, i.e. run MPTP over
> PMIP  tunnels (IP tunnels). This document follows the idea that building
> the datapath, with the multiple binding option, is one thing and how to use
> the tunnels is another thing.... MPTCP can thus be one of the way to
> distribute the traffic across these tunnels; we actually believe that use
> existing IETF protocols instead of  reinventing hazardous mechanisms...
>
>
I think you are talking about the hybrid access solution that was discussed
long time back in BBF.
Such a discussion belongs to BANANA group not dmm.

This draft is supposed to be a maintenance draft coming from Netext which
is now closed.
dmm is not the place to add new functionality such as hybrid access
capability to PMIP.
 Such a capability would require PMIP support at the home gateways which
was not agreed upon in BBF.
I support Mirja's comment and suggest removing the whole discussion from
the draft.

Regards,

Behcet

> > 2) Further the following sentences also in section 3.2 should be revised:
> > „For example, high throughput services (e.g.
> >    video streaming) may benefit from per-packet distribution scheme,
> >    while latency sensitive applications (e.g.  VoIP) are not be spread
> >    over different WAN paths.“
> > High throughput services only benefit from per-packet scheduling if the
> service
> > requires higher throughput than one of the links can provide. Also video
> streaming
> > may not be a good example here because high latency variations can lead
> to
> > stalls. Therefore in general per-flow scheduling should be recommend for
> all
> > traffic. It could still be beneficial to schedule flows that require low
> latency over the
> > link with the lower base latency, or maybe more important lower jitter,
> however,
> > often it is not known to the network what the requirements on latency
> are for a
> > given flow. Therefore is should probably be recommended to schedule all
> traffic
> > on the "better" link (where better can be pre-configured knowledge or
> measured) as
> > long as the bandwidth of the incoming traffic is smaller than the
> bandwidth of the
> > that link, and only use a second link (with per-flow scheduling) if the
> capacity is
> > required.
> >
>
> I agree. However, this document does not aim to recommend ways to steer
> traffic over multiple paths. Examples focuses on use-cases from RFC4908 to
> which the document inerits. Actually, as per RFC7864 (flow mobility
> extension for PMIPv6), leaves possibility to use either per-flow and
> per-packet distribution.. use one of this scheme, or both it is an
> implementation choice that  is out the scope of this document.
>
>
> > 3) This document does not really normative specify the use of the newly
> defined
> > options. It only gives an examples but it does not specify normatively
> any actions
> > that need to performed on receipt of these options. How does the MAG
> know if
> > the LMA does not support Multipath binding? An LMA that does not
> implement this
> > spec will not send back an error message.
>
> Good point...
>
> Section 4.3 states the LMA that does not support multipath binding.SHOULD
> replies with the error message:   CANNOT_SUPPORT_MULTIPATH_BINDING
>
> However, if the LMA does not support this spec and, thus, does not support
> this error message, the MAG shall not receive the MAG identifier in the PBU
> ack. So, that MAG shall thus fall-back to the legacy RFC5213 compliant MAG
> behavior.
>
> We will clarifiy that.
>
> Why are there two different options?
> > What happens if one of the options is present in the Proxy Binding
> Update but not
> > the other?
> >
>
> The proxy binding update contains the MAG identifier and  the multihoming
> . The LMA replies with only the MAG identifier option. This is in section
> 3.1 (which should be renamed as "protocol overview"), but I confess that it
> should be better highlighted....Also, if one option is missing in the PBU,
> the behavior should be similar to what it is specified in PMIPv6 RFC5213:
> "MISSING_XXX_OPTION" error should be sent by the LMA in the PBA... we will
> add this.
>
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Please also clarify the definitions of Interface Label and Binding
> Identifier as
> > requested by the gen-art review (Thanks Robert!)
> >
> >
>
> Yes, of course.
>
> > _______________________________________________
> > dmm mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dmm
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm