Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, May 11, 2017 at 3:31 PM, Jiazi Yi <[e-mail]> wrote:
> Dear Warren,
>
> Thanks very much for the comments. Please check our reply inline:
>
> On 10 May 2017, at 17:35, Warren Kumari <[e-mail]> wrote:
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-13: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I am not a MANET person, and know very little about the Optimized Link
> State Routing Protocol, however I found this document to be very vague
> and poorly worded in many places. At some point I simply gave up trying
> to understand it, but have concerns that it is not sufficiently clear for
> independent implementations.
>
> I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, and
> so I'm trusting Alvaro to know if it is deployable / implementable
>
>
> As an extension of OLSRv2, some background on OLSRv2 is probably necessary
> to fully understand the document. We will try our best to clarify related
> issues in the next revision.
>
> Regarding the deployability and implementability, as we mentioned in section
> 10 - Implementation Status of the draft, there have been several open source
> implementations and those are tested in both real testbed and simulators.


Excellent. I'll be honest - I stopped reading before Sec 10, and then
skipped down to the end....


> There are also non-trivial amount of academic publications related to this
> work:
>
> https://scholar.google.fr/scholar?oi=bibs&hl=en&cites=10113725695151775552
> https://scholar.google.fr/scholar?oi=bibs&hl=en&cites=3728706634624165938
>
> So we can safely say that it’s deployable / implementable ;)
>
>
> Comments:
> S1.1:
> "The multi-path extension for OLSRv2 is expected to be revised and
> improved to the Standard Track," - I'm not sure an extension can be
> "improved to the Standard Track" - perhaps you mean that the documents
> will be improved and published as Standards track? Or that once
> implementations are more stable they will be documented on Standards
> Track?
>
>
> Yeah. As an experimental document, we would like to gather more experience
> on related issues, and once mature enough, push the idea on standards track
> (like OLSR and OLSRv2).
> We also rephrased the text in the draft.

Thanks.


>
>
> "Although with existing experience, multiple paths can be obtained even
> with such partial information,  the calculation might be impacted,
> depending on the MPR selection algorithm used." - I don't understand the
> "with existing experience", and this sentence is a fragment. I suspect
> that removing " with existing experience," would make this cleaner, but I
> don't really understand what you are trying to say…
>
>
> Does this sound better:
>
> Although multiple paths can be obtained even with such partial information
> based on existing experience, the calculation might be impacted depending on
> the Multi-Point Relay (MPR) selection algorithm used.
>

I think, "Experience has shown that multiple paths can be obtained
even with such partial information, however, depending on the
Multi-Point Relay (MPR) selection algorithm used, the calculation
might be impacted". I'm not quite sure what you mean by: "calculation
might be impacted" - perhaps "suboptimal results may be obtained"? Or
something.


>
>
> "Different algorithms to obtain multiple paths, other than the default
> Multi-path Dijkstra algorithm introduced in this specification." - this
> should have a reference to somewhere in the document.
>
>
> fixed

Thanks


>
>
>
> 5.1:
> "CUTOFF_RATIO   The ratio that defines the maximum metric of a path
> compared to the shortest path kept in the OLSRv2 Routing Set. For
>  example, the metric to a destination is R_metric based on the
>  Routing Set." - I don't understand what the last sentence is trying to
> say.
>
> "CUTOFF_RATIO MUST be greater than or
>      equal to 1.  Note that setting the value to 1 means looking for
>      equal length paths, which may not be possible in some networks."
>  -- surely setting it to 2 (or any other number) will also end up
> looking for paths which might not be possible?
>  E.g:
>        ┌──┐  ┌──┐  ┌──┐  ┌──┐
>  ┌────▶│R1│─▶│R2│─▶│R3├─▶│R4│─────┐
>  │     └──┘  └──┘  └──┘  └──┘     ▼
> ┌───┐            ┌──┐            ┌───┐
> │ S │───────────▶│R6│───────────▶│ D │
> └───┘            └──┘            └───┘
>
>
> Yes. This is intentional: to avoid having too much variance between multiple
> paths obtained.


Yup, but if set to 2, you might also not be able to find a path that
works, so I think you need to remove: "Note that setting the value to
1 means looking for equal length paths, which may not be possible in
some networks." -- or perhaps, "Setting the number low makes it less
likely that additional paths will be found -- for example, setting it
to 1 will only consider equal length paths" ? (I don't feel strongly
about any of this)

>
> "SR_HOLD_TIME_MULTIPLIER  The multiplier to calculate the minimal time
>      that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2
>      Router Set. It is the value of the Message TLV with Type =
>      SOURCE_ROUTE." - this is vague / confusing. I think that you need a
> reference to Sec 6.1.1.
>
>
> In the new revision, this parameter is removed based on the discussion with
> Chris at https://www.ietf.org/mail-archive/web/manet/current/msg19426.html
>

Great, thanks.

>
> 9.  Configuration Parameters
> "the users of this protocol
>   are also encouraged to explore different parameter setting in various
> network environments, and provide feedback."  -- where?
>
>
> Hmmm… I didn’t quite get the question. You meant where to provide the
> feedback? There is contact information of the authors in the draft, and
> apparently, the mailing list is the right place also. If you want, we can
> call it out explicitly in the draft.


Yup, that would be great -- perhaps "and provide feedback to the MANET
WG <insert list name>"
ID Guidlines contains:

"It is strongly recommended that the draft include a notice (with
   email address) of where comments should be sent.  For example:

      "Comments are solicited and should be addressed to the working
      group's mailing list at ___@______ and/or the author(s)."
"
-- perhaps just copy that.  Actually, chairs, do you want this (don't
want to clutter up your list).

>
>
>
> 12.  "IANA Considerations
>   This section adds one new Message TLV, allocated as a new Type
>   Extension to an existing Message TLV."
>  -- this section seems to be missing some important information, like
> which registry this updates Message Type 7 in.
>
>
> The registry is "Message TLV Types” specified in
> https://tools.ietf.org/html/rfc7631
> We will add related information in the new revision.

Win!

>
> best
>
> Jiazi
>

Awesome, thank you for addressing all these...

W

>
>
>
>
> Nits:
> S1.1:
>
> "Because the packet drop is normally bursty in a path" -- "Because packet
> drops on a path are normally bursty"...
>
> "Other than general experiences including the protocol specification and
> interoperability with base OLSRv2 implementations, the experiences in the
> following aspects are highly appreciated:"
> s/ experiences including/ experiences, including / (grammar)
> s/ the experiences / experiences / (grammar)
>
> "Although with existing experience,  multiple paths can be obtained even
> with such partial information,  the calculation might be impacted,
> depending on the MPR selection algorithm used."
> s/Although with existing experience/Although, with existing experience/
> (grammar)
>
> "In scenarios where the length of the source routing header is critical,
> the loose source routing can be considered."
> s/ the loose source /  loose source /
>
> "for  example, the paths with lower metrics (i.e., higher quality) can
> transfer more datagrams compared to paths with higher metrics." -- nit:
> many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you
> might want to clarify (or just say packet)
>
> S3:
> "MP-OLSRv2 is designed for networks with dynamic topology by avoiding
> single route failure." - this makes it sound like it was *designed* by
> avoiding single route failure.
>
> "in IPv4 networks the interoperability is achieved by using loose source
> routing header;" - in IPv4 networks interoperability is achieved using
> loose source routing headers;" (or "by using the loose...")
>
> S4:
> "The reactive operation is local in the router" - "local to the router"
>
>
> S5.1:
> "All the intermediate routers MUST be included in the source routing
> header, which makes the number of hops to be kept a variable."
> -- I don't understand how the "the number of hops to be kept" is "a
> variable"; this makes it sound like I can set the number of hops to be
> kept. Perhaps you meant "a variable number of hops" or "the number of
> hops changes"?
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf