[DMM] Mirja Kühlewind's No Objection on draft-ietf-dmm-mag-multihoming-07: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-mag-multihoming-07: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS comment and refine the spec where needed!

This is my old discuss text for the record:

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

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.

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?