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

[Henning Rogge <[e-mail]>]

On Sun, Sep 14, 2014 at 2:29 PM, Abdussalam Baryun
<[e-mail]> wrote:
> 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.
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).

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

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

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

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.

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

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.

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

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.

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

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

> In section 6:
>
> It says defines two constants that are defined but then refers to four
> 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
> mandatory per case. If that is case please clarify in the section.

All of the constants are similar important.

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

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

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.

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

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