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

Hi, 

<snip>
>> 
>> "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”.

Yes. 

> I'm not quite sure what you mean by: "calculation
> might be impacted" - perhaps "suboptimal results may be obtained"? Or
> something.

It’s the disjointness of the paths calculated. We will clarify it in the text also. 

<snip>

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

Yeah, this would be better. thanks. 

<snip>

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

I’m fine with the proposed text, unless the chairs are explicitly against it ;)

Again, thanks very much for the review and the comments!

regards

Jiazi

> 
>> 
>> 
>> 
>> 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 <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
>> manet@ietf.org
>> 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