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

From: Warren Kumari <[email-masked]>
Date: Wed, 10 May 2017 08:35:39 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-manet-olsrv2-multipath-13: 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-manet-olsrv2-multipath/

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

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?

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

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

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 │
└───┘            └──┘            └───┘

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

 9.  Configuration Parameters
 "the users of this protocol
   are also encouraged to explore different parameter setting in various
network environments, and provide feedback."  -- where?

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.

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 10 May 2017 15:52:27 +0000

On 5/10/17, 11:35 AM, "Warren Kumari" <[email-masked]> wrote:

Warren:

Hi!

> so I'm trusting Alvaro to know if it is deployable / implementable

There are already 3 open source implementations. ☺

I’ll let the authors address the rest of the comments.

Thanks!

Alvaro.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 May 2017 18:11:07 +0200

> There are already 3 open source implementations. ☺

Ah, excellent....

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

---

From: Jiazi Yi <[email-masked]>
Date: Thu, 11 May 2017 15:31:28 +0200

Dear Warren, 

Thanks very much for the comments. Please check our reply inline: 

> On 10 May 2017, at 17:35, Warren Kumari <[email-masked]> wrote:
> 

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. 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=10113725695151775552>
https://scholar.google.fr/scholar?oi=bibs&hl=en&cites=3728706634624165938 <https://scholar.google.fr/scholar?oi=bibs&hl=en&cites=3728706634624165938>

So we can safely say that it’s deployable / implementable ;)

> implementations are more stable they will be documented on Standards

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. 

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

> should have a reference to somewhere in the document.

fixed

> looking for paths which might not be possible?

Yes. This is intentional: to avoid having too much variance between multiple paths obtained. 

>      SOURCE_ROUTE." - this is vague / confusing. I think that you need a

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 <https://www.ietf.org/mail-archive/web/manet/current/msg19426.html>

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

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

best

Jiazi

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Warren Kumari <[email-masked]>
Date: Thu, 11 May 2017 16:17:35 +0200

On Thu, May 11, 2017 at 3:31 PM, Jiazi Yi <[email-masked]> wrote:
> 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
>
> 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).

Thanks.

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

> should have a reference to somewhere in the document.

Thanks

> looking for paths which might not be possible?

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)

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

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

> The registry is "Message TLV Types” specified in
> https://tools.ietf.org/html/rfc7631

Win!

> Jiazi

Awesome, thank you for addressing all these...

W

---

From: Jiazi Yi <[email-masked]>
Date: Thu, 11 May 2017 17:38:57 +0200

Hi, 

<snip>
> might be impacted”.

Yes. 

> I'm not quite sure what you mean by: "calculation

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

<snip>

> to 1 will only consider equal length paths" ? (I don't feel strongly

Yeah, this would be better. thanks. 

<snip>

> 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

>> https://tools.ietf.org/html/rfc7631 <https://tools.ietf.org/html/rfc7631>

---

From: Justin Dean <[email-masked]>
Date: Sun, 14 May 2017 20:51:01 +0000

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 <[email-masked]> wrote:

> Yes. This is intentional: to avoid having too much variance between
> multiple
> paths obtained.
>
>
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 May 2017 11:09:10 -0400

Great. Thanks all...

W

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 May 2017 14:14:41 +0200

Yes it is a good idea to add the list address, but need IESG/wg-chairs work
harder to maintain acknowledgements/replies to any participants that send
to the list/draft.

AB

On Mon, May 15, 2017 at 5:09 PM, Warren Kumari <[email-masked]> wrote:

> >> based on existing experience, the calculation might be impacted
> depending
> >> on
> >> I’m fine with the proposed text, unless the chairs are explicitly
> against
> >> it ;)
> >>