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 protected]> 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. > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
