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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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" <[e-mail]> wrote:

>Mirja Kühlewind has entered the following ballot position for
>draft-ietf-dmm-mag-multihoming-04: Discuss
>
>
>----------------------------------------------------------------------
>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.
>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.


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


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



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





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




>