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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Sri,

see below.

> Am 17.08.2017 um 05:17 schrieb 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.

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.

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


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

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

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?

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

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



> 
> 
> 
> 
>> 
>