[manet] Mirja Kühlewind's Discuss on draft-ietf-manet-olsrv2-multipath-12: (with DISCUSS and COMMENT)

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

Mirja Kühlewind has entered the following ballot position for
draft-ietf-manet-olsrv2-multipath-12: 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-manet-olsrv2-multipath/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The following text in section 4 seems to indicate that scheduling is done
on a per-packet basis:
"When there is a
   datagram to be sent to a destination, the source router acquires a
   path from the Multi-path Routing Set (MAY be Round-Robin, or other
   scheduling algorithms)."
This seems not appropriate as e.g. TCP packets routed on links with
largely different delays may suffer performance. ECMP usually hashes the
5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and routes
all packets belonging to the same flow on the same route. I recommend to
apply the same here.

Also related is this text in section 8.4 that should explain Round-Robin
on a per flow basis instead. Further this should only be an example
scheduling alogirthm while text belong seems to assume that Round-Robin
is always used.
"If a matching Multi-path Routing Tuple is obtained, the Path Tuples
   of the Multi-path Routing Tuple are applied to the datagrams using
   Round-robin scheduling.  For example, there are 2 path Tuples
   (Path-1, Path-2) for destination router D. A series of datagrams
   (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D.
   Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for
   Packet 3, etc.  Other path scheduling mechanisms are also possible
   and will not impact the interoperability of different
   implementations."

Related is this text in section 8.4.:
"If datagrams without source routing header need to be forwarded using
   multiple paths (for example, based on the information of DiffServ
   Code Point [RFC2474])"
RFC2474 does not specify any application requirements on multipath use
and as such the DiffServe field should not be used to determine if the
flow can be routed on multiple paths. The ability to profit from
multipath routing depends not only on the application and protocols used
but also on the characteristics of the multipath link(s); so it's hard to
make any implicit assumptions here. However, if routing would only be
recommended on a per-flow basis this problem does not occur and the
brackets above could be remove. Further, if routed on a per flow basis
would be done, DiffServ could actually be used to decide which path to
use, if e.g. one path has a lower delay, but that seem to need further
discussion as well.


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

Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source routing
   header to avoid fragmentation."
MAYBE
"It is NOT RECOMMENDED to fragment the IP packet if the packet with the
source routing header would  exceed the minimum MTU along the path. In
this case source routing and therefore the additional path calculated by
MP-OLSRv2 SHOULD NOT be used."

2) section 9:
"For IPv6 networks, it MUST
      be set to 0, i.e., no constraint on maximum number of hops."
Why is that?

3) Not sure why section 12.1. is there? Can this be removed?