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

[Warren Kumari <[e-mail]>]

Great. Thanks all...

W

On Sun, May 14, 2017 at 4:51 PM, Justin Dean <[e-mail]> wrote:
> I think having people directed to the list regarding questions of
> implimentations is completely appropriate.
>
> Justin Dean
>
>
> On Thu, May 11, 2017, 11:45 AM Jiazi Yi <[e-mail]> wrote:
>>
>> 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
>> 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



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