Subject: Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Wed, 2 Aug 2017 09:46:15 +0000

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-masked]] De la part de Mirja Kühlewind
> Envoyé : lundi 31 juillet 2017 23:49
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]
> 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...

> 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-masked]
> 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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Aug 2017 10:24:59 -0500

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

> The document does not recommend such a thing... the document leverages
> PMIP (RFC5213) tunneling mechanisms, i.e. IP-in-IP, GRE, ...
>
> Please remove
> 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

> 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.
>
>
> 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.
>
> 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.
>
>
> >
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Aug 2017 03:17:50 +0000

Hi Mirja.

Please see below and also let us know if the text that we discussed with
Warren addresses your main concerns.

Regards
Sri

On 7/31/17, 2:49 PM, "Mirja Kühlewind" <[email-masked]> wrote:

>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.
>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 …“

Ack. Please see the new text.

>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.

We re-wrote this paragraph and hopefully that addresses this issue.

>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. Why are there two
>different options? What happens if one of the options is present in the
>Proxy
>Binding Update but not the other?
>

This is a good point. There is an implicit assumption that the LMA
behavior is consistent with the behavior when dealing with any unknown
options. 
We can put a note that the PBU will rejected with error code 128.

>Please also clarify the definitions of Interface Label and Binding
>Identifier
>as requested by the gen-art review (Thanks Robert!)
>

Interface label is a static field, Ex: “LTE-Interface”, “my blue
interface”. Traffic policy is tied to this static label,

HTTP Flow: Use LTE-Interface, if not available, use “WiFI-Interface”.
Label is tied to a policy; which the MAG and LMA will translate it bind
the flow to a dynamically created tunnel using the CoA from that interface.

Binding identifier is what is dynamically generated and using to identify
a specific binding on the LMA.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 17 Aug 2017 15:12:55 +0200

Hi Sri,

see below.

> Am 17.08.2017 um 05:17 schrieb Sri Gundavelli (sgundave) <[email-masked]>:
> 
> Hi Mirja.
> 
>> only option: 
> „Packet distribution can be done either at the transport
>> level,
>> e.g. using MPTCP …“
> 
> 

Yes, the new text is fine. Instead of not recommending anything you could actually even recommend per-flow scheduling as the default… but text is fine this way as well.

> We re-wrote this paragraph and hopefully that addresses this issue.

Yes, just removing this part was the best option here.

> We can put a note that the PBU will rejected with error code 128.

That's good. Are you supposed to resend without the new options if you received 128? And again what happens if only one option is present?

> a specific binding on the LMA.

I think this comment was on the way it is described in the draft. Maybe the wording can be further clarified there. Here is the original text from the genart review of Robert Sparks:

"* I still find the definitions of Interface Label and Binding Identifier confusing.
   I suspect they _both_ need to be carefully rewritten to make sure they are
   definitions of the terms, and not descriptions of the interactions of the two
   fields. Why is the Interface Label definition talking so much about binding?
   As currently written, that last sentence of the Binding Identifier
   definition says  the document says the mobile access gateway assigns
   a single unique binding identifier for each of its interfaces. „

Thanks!
Mirja

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 18 Aug 2017 01:08:33 +0000

Hi Mirja,

Thank you for your quick feedback. Please see inline …

On 8/17/17, 6:12 AM, "Mirja Kuehlewind (IETF)" <[email-masked]> wrote:

<snip> .. keeping only the open issues.

>That's good. Are you supposed to resend without the new options if you
>received 128? And again what happens if only one option is present?

I will take care of this. Will add considerations on both LMA/MAG behavior
when there is version incompatibility. Will post a new rev with these
considerations. But, thank you; we definitely overlooked this part.

>I think this comment was on the way it is described in the draft. Maybe
>the wording can be further clarified there. Here is the original text
>from the genart review of Robert Sparks:

I have looked at both the definitions and I agree it needs to some
clarification. I will fix this.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 18 Aug 2017 10:24:27 +0200

Thanks! Will wait for the next version!

> Am 18.08.2017 um 03:08 schrieb Sri Gundavelli (sgundave) <[email-masked]>:
> 
> Hi Mirja,
>