Subject: [manet] AB#1 Review for draft-ietf-manet-olsrv2-dat-metric (DAT metric for RFC7181)

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 14 Sep 2014 14:29:51 +0200

Reviewed draft name: draft-ietf-manet-olsrv2-dat-metric-02.
Date: 14.09.2014.

Dear WG editors, and All WG participants,

I thank you very much for this interesting work. I read the draft and don't
think the draft is ready for WGLC as Thomas proposed previously in July [1]
(no action/reply by WG yet for the proposal). Furthermore, I agree with the
comment of Thomas regarding IANA section, specially for
olsrv2 multitopology's consideration. However, IMHO the draft should be
clear who the RFC5444 packets belong to (from other discussions with WG,
they think it only belongs to the multiplexer), while measuring
link packets loss.

 The terminology section should clarify what are packets for this protocol,
is a packet: the link packet, control packet, data packet, IP packet, or
mixed, but because not clear about that it may taken more reading time. I
understand it is only link packets because this metric-protocol measures
only link packets. The WG draft in section 9 defines value for RFC5444
packet, but does not describe how it is implemented or does not mention the
unified multiplexer function. I suggest adding one section for multiplexing
considerations. I remember in one conversation [2], you suggested a code
line into right place. For this experimental protocol where will be the
right place to instruct RFC5444 to input value for packet sequence numbers.

[1]. http://www.ietf.org/mail-archive/web/manet/current/msg16741.html

[2]. http://www.ietf.org/mail-archive/web/manet/current/msg16987.html

AB> the draft needs to be clear what is the "packet loss". IMO it should
always say "link packet loss". Please amend.

In section 3:
Some links may have more than one routing protocol using it as RFC5498/5444
shares the number/port for all MANET protocols' control traffic.

--- OLD ---
If [RFC5444] control traffic is used to determine the link packet loss, the
administrator should take care that link layer multicast transmission do
not not have a higher reception probability than the slowest unicast
transmission.

--- NEW ---
If [RFC5444] control traffic is used to determine the average packet loss,
the administrator should take care the following: 1) that the control
traffic is owned by the routing protocol determining the metric, 2) that
link layer multicast transmission do not not have a higher reception
probability than the slowest unicast transmission.

In section 5:
The ratio is not average because it should be less than 1. The draft has to
determine that the ratio is per protocol not per multiplexer. IMHO The
draft is now calculating the ratio per multiplexer.

--- OLD ---
The average packet loss ratio is calculated as the sum of the ’total
packets’ counters divided by the sum of the ’packets received’ counters.
 This value is then divided through the current link-speed and then scaled
into the range of metrics allowed for OLSRv2.

--- NEW ---
The link packet loss value is calculated as the sum of the ’total packets’
counters routing protocol links divided by the sum of the ’packets
received’ counters for same links.  This average value is then divided
through the current link-speed and then scaled into the range of metrics
allowed for OLSRv2.

In section 6:

It says defines two constants that are defined but then refers to four
constants. I expect you mean the first two are MUST and the others are
mandatory per case. If that is case please clarify in the section.

In section 8.1:

Repeated packet sequence number initial ( please delete one).

--- OLD ---
L_DAT_lost_hello_messages := 0 (no HELLO interval without packets).

--- NEW ---
L_DAT_lost_hello_messages := 0 (no HELLO interval without a hello message).

In Section 9.3

---OLD---
While this metric was designed for measuring the packet loss based on the
[RFC5444] packet sequence number, some implementations might not be able to
add the packet sequence number to their output. Because of this the
following section contains multiple alternatives to calculate the packet
loss.

--- NEW ---
While this metric was designed for measuring the packet loss and link
speed based on the Link packet sequence number and the multiplexer
policy, some implementations might not be able to add the packet sequence
number to their output. Because of this the following section contains
multiple alternatives to calculate the packet loss.

In section 10:

You mention RFC5444 processing, what do you mean, I understand you
mean the unified multiplexing of RFC5444, is that what you mean?

Overall, looking into our WG drafts and RFCs, is the WG avoiding
mentioning the multiplexer function in its drafts for an unknown
reason? Is that an official editing procedure plan? Even the RFC5444
puts it in the appendix, which I think is the wrong place, if the WG
is considering interoperability.

Best Regards,

AB

This is the first review of AB for this WG draft.

On Friday, August 8, 2014, wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Mobile Ad-hoc Networks Working Group of
> the IETF.
>
>         Title           : Packet Sequence Number based directional airtime
> metric for OLSRv2
>         Authors         : Henning Rogge
>                           Emmanuel Baccelli
>         Filename        : draft-ietf-manet-olsrv2-dat-metric-02.txt
>         Pages           : 17
>         Date            : 2014-08-08
>
> Abstract:
>    This document specifies an directional airtime link metric for usage
>    in OLSRv2.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 16 Sep 2014 10:21:40 +0200

On Sun, Sep 14, 2014 at 2:29 PM, Abdussalam Baryun
<[email-masked]> wrote:
> comment of Thomas regarding IANA section, specially for olsrv2
> multitopology's consideration.
If you read the IANA section of the olsrv2 multitopology draft, you
will notice the extended 'administrative action' part.

So the question about if this draft (which does not extend the
definition of outgoing RFC5444 packets/messages on its own) needs a
Type Extension registration is still open.

> However, IMHO the draft should be clear who
> the RFC5444 packets belong to (from other discussions with WG, they think it
> only belongs to the multiplexer), while measuring link packets loss.

This draft does not define any extension of the RFC5444 packets, it
just uses what has been suggested in RFC5444 (and its errata).

> only link packets.

As you can (and should) read in the draft it defines several ways to
measure the link packet loss. Depending on your choice you measure
something different.

In addition to this the term "link packets" doesn't make much sense...
link packet loss describes the packet loss on a link... not the loss
of a special kind of packet. I hope you are aware what a "link" is.

> The WG draft in section 9 defines value for RFC5444
> considerations.

Again, this draft does not define new RFC5444 messages, nor does it
add new TLVs. It only mandates the presence of the packet sequence
number as it has been described in RFC5444 (and errata).

> I remember in one conversation [2], you suggested a code

As you can read in my mail you linked in [2], the comment was about an
implementation. Implementation specific details should not be part of
this draft.

> shares the number/port for all MANET protocols' control traffic.

Please re-read the section about packet-sequence number based link
loss measurements. The advantage (and challenge) of this is that you
can use the RFC5444 protocol traffic of ALL protocols using the MANET
port defined in RFC5498. As long as its a RFC5444 packet going the the
multicast address defined in RFC5498, you can use it without even
looking into the protocol specific messages. The more RFC5444 packets
you get, the more exact will be the estimated link loss.

> administrator should take care that link layer multicast transmission do not
> not have a higher reception probability than the slowest unicast
> transmission.
>
> --- NEW ---

Two paragraphs above you suggest using "link packet loss" everywhere
and now you suggest replacing it by "average packet loss"?

> In section 5:
> The ratio is not average because it should be less than 1.

Yes, it is an average... no, it is not below 1.

As you can read in RFC7181 we have to deal with link COSTS, which
means "low is good, high is bad". So the ratio this draft talks about
is total packets divided by received packets. This is equivalent to
the link costs described in the ETX and ETT papers referenced by this
draft.

> The draft has to
> determine that the ratio is per protocol not per multiplexer. IMHO The draft
> is now calculating the ratio per multiplexer.

Ratio per multiplexer? I am not sure what you are talking about.

> counters routing protocol links divided by the sum of the ’packets received’
> counters for same links.  This average value is then divided through the
> current link-speed and then scaled into the range of metrics allowed for
> OLSRv2.

I don't think this text change makes any sense.

> constants.

Yes, this is definitely a bug, thank you for finding it.

> I expect you mean the first two are MUST and the others are

All of the constants are similar important.

But replacing "two constants" by "multiple constants" should fix the problem.

> L_DAT_lost_hello_messages := 0 (no HELLO interval without a hello message).

No, that is wrong. The draft does only need to "estimate" any loss if
it doesn't get any RFC5444 packet over a link. As soon as it receives
a single RFC5444 packet, it can calculate the earlier packet losses
based on the packet sequence number so the L_DAT_lost_hello_messages
is really the number of HELLO intervals without any received RFC5444
packets.

> While this metric was designed for measuring the packet loss and link speed
> based on the Link packet sequence number and the multiplexer policy, some
> implementations might not be able to add the packet sequence number to their
> output. Because of this the following section contains multiple alternatives
> to calculate the packet loss.

No, this is wrong. The link speed is NOT based on the packet sequence numbers.

Not sure what you want to say with the multiplexer policy.

> In section 10:
>
> You mention RFC5444 processing, what do you mean, I understand you mean the
> unified multiplexing of RFC5444, is that what you mean?

It means section 9, which describes the parsing of data incoming
through RFC5444 packets and messages.

> Overall, looking into our WG drafts and RFCs, is the WG avoiding mentioning
> the multiplexer function in its drafts for an unknown reason? Is that an
> official editing procedure plan? Even the RFC5444 puts it in the appendix,
> which I think is the wrong place, if the WG is considering interoperability.

Its not the job of this draft to describe the multiplexer part for
RFC5444. It just reads existing incoming information, including the
packet sequence number content described in RFC5444.

Henning Rogge