Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-03.txt

From: [email-masked]
Date: Mon, 24 Nov 2014 04:56:51 -0800

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-03.txt
	Pages           : 16
	Date            : 2014-11-24

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-03

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/

---

From: Henning Rogge <[email-masked]>
Date: Mon, 24 Nov 2014 14:04:52 +0100

Hi,

I hope this new revision of the DAT metric resolves the trouble with
interoperability between nodes that can send/process RFC5444 packet
sequence numbers and nodes that can not.

The draft became a little bit shorter in the process because there is
no "mode A" and "mode B" (plus optional "mode C") anymore, MANET
routers should gracefully fall back to Hello timeout loss measurements
when the neighbor cannot deliver packet sequence numbers or the local
router cannot process them.

Henning Rogge

On Mon, Nov 24, 2014 at 1:56 PM,  <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Nov 2014 18:49:27 +0100

I strongly support publication of this document as an Experimental RFC.

Minor nits follow.

1. Introduction

The introduction seems to imply that DAT is preferable to ETX ("less
efficient than in the past, which is one reason to move to a different
metric").  I don't understand that -- it is my feeling that DAT is just
a variant of ETX that's easier to implement.  If you stand by your claim,
then that deserves more discussion.

3. Applicability Statement

Please clarify what happens when 8 packets in a row are lost.  Is the link
dropped, or will it be used as the least-preferred link?  (The latter,
judging from 10.2.5.2.)

(FWIW, experimental data indicate that 802.11 remains useful when 7/8
packets are lost, pre-ARQ -- so your "7 or 8" is a little close for
comfort.)

4. Rationale

"The Directional Airtime Metric measures the incoming loss rate".  This is
the loss rate in the "wrong" direction -- it's the loss rate in the
outgoing direction that we're interested in.  I agree with you that this
approximation gives reasonable results when combined with bidirectional
reachability detection (or whatever it is called in NHDP), but this
deserves some more discussion.

5. Metric Functioning & Overview

You're speaking about "packet loss", it is not clear that you measure
packet loss for protocol packets only.  It may be worth restating that
that protocol packets are always sent over multicast (is that correct?).

6. Protocol Paremeters

"Two routers with different values..."  The consequences of this are not
clear.  What happens if routers are configured with different parameters?
Will the network collapse, or will you merely end up with sub-optimal
routing choices?  (I understand it's the latter, correct?)

"DAT_HELLO_TIMEOUT_FACTOR = 1.2".  I'm using 1.5 in Babel, which gives
more margin for late packets while still reliably avoiding mistaking the
next hello for the previous one.

8. Data structures

I don't think that citing DLEP is useful here, it only adds confusion by
implying that this specification is dependent on DLEP.

Why are you using L_DAT_rx_bitrate instead of the tx bitrate?  (Given that
you only have packet loss in the "wrong" direction, it's not clear to me
whether you should be using link speed in the "right" or in the "wrong"
direction; more discussion would be welcome.)

9.2

Should a router using this metric ensure that there is a Hello in each
packet it sends?  Or would the cost be prohibitive?

(FWIW, Babel doesn't make that requirement, but it only measures packet
loss for packets containing a Hello.)

9.3 Link Loss Gathering

"SHOULD be carried out".  Why SHOULD?

"packets without packet sequence number MUST NOT be processed".  Why not?
I'd say that if you have either INTERVAL_TIME or seqno, than you can
manage.  If you have neither, then you're out of luck, of course.  At any
rate, this MUST NOT seems to contradict the stand you're taking in 9.2.
More discussion would be welcome

Step 2.3.  What happens when L_DAT_last_pkt_seqno = pkt_seqno?  Should you
be dealing with this case specially?  Especially if you take into account
my suggestion in 10.1 below.

(FWIW, in Babel we treat specially the case where pkg_seqno is between
L_DAT_last_pkt_seqno - 15 and L_DAT_last_pkt_seqno -- we "undo history"
in that case.)

Step 2.3.  This case deserves further comments.  It implies that the
neighbouring router has rebooted (since an extended outage would have
caused your various timers to trigger); is it justified to keep the
statistics, or should the whole state for this neighbour be reset?  (No
objection to keeping the current behaviour, just make it clear what's
going on here.)

10.1

Shouldn't you be incrementing L_DAT_last_pkt_seqno?  (It doesn't matter
much, since you'll reset the value the next time you receive a Hello, but
you've concluded that you've lost a packet, so you might as well reflect
it.  Doing this, however, implies further complexity in step 2.3 of 9.3.)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Nov 2014 19:00:58 +0100

> I strongly support publication of this document as an Experimental RFC.

However, my previous caveat still stands: as far as I'm aware, you haven't
published any experimental data that shows that this metric doesn't behave
significantly worse than ETX.  While this should not prevent publication
as an *Experimental* RFC, it seriously reduces the interest of your work.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Tue, 25 Nov 2014 08:34:02 +0100

Hi Juliusz,

thank you for the quick review!

> then that deserves more discussion.

Are you talking about ETT? Because ETX doesn't include the link speed.

We already had the situation in a few of community mesh networks where
they had to cut a few long range links... they were low speed (2
MBit/s in the example I remember) but had no packet loss. And ETX was
concentrating traffic on these links instead of going through a series
of high-speed links (also without packet loss).

So I think there is no question that a link-speed based metric is
better than ETX.

> dropped, or will it be used as the least-preferred link?  (The latter,

8 packets in a row get lost?

The packet loss algorithm described does only care about the total
number of received/lost packets in the measurement period. If you
loose more than 7/8 of them (regardless of the number), the "packet
loss" part of the metric will go to the highest value.

Dropping links is not the job of the metric, its the job of the
validity timeout and the link hysteresis.

> packets are lost, pre-ARQ -- so your "7 or 8" is a little close for

I think the change to 7/8 came from a discussion with you. With 7/8
packet loss you will loose ~ 50% of your packets even after ARQ, which
should nearly kill every TCP connection. I don't think it makes much
sense to measure how much worse than 7/8 loss you are. Its just "worst
link packet loss while still alive".

> outgoing direction that we're interested in.

Please have a look at http://tools.ietf.org/html/rfc7181#section-8.1

" L_in_metric will be specified by a process that is external to this
specification..."

The job of the metric is to calculate the cost of the incoming links.

>  I agree with you that this

OLSRv2 use directional metrics, it doesn't combine incoming and outgoing metric.

> packet loss for protocol packets only.

I will adapt the text in chapter 3 now that the "option A, B, C" for
packet loss gathering is gone. Thank you for finding this.

> It may be worth restating that

OLSRv2/NHDP control traffic is normally done over multicast, but I
know that people have used unicast for OLSRv1 directional point to
point links. Not sure if we need to mention this.

> next hello for the previous one.

I have no really strong opinion on this... I think the value was 1.5
in an earlier document but got reduced later. 1.5 might be too large
if you use a 25% jitter... Jitter always decrease the interval between
messages, so you could get two Hellos within 1.5 Hello-intervals.

> implying that this specification is dependent on DLEP.

DLEP is one potential source for the incoming bitrate, so I think its
worth mentioning here.

> direction; more discussion would be welcome.)

Because I calculate incoming link metric.

> loss for packets containing a Hello.)

Not necessary, because every RFC5444 packet can contain a packet
sequence number.

> "SHOULD be carried out".  Why SHOULD?

Yes, if the packet does not contain a packet sequence number of you
are unable to get the packet sequence number, you don't need to do it.
The algorithm will automatically fall back to a "hello timeout based"
packet loss estimation.

Maybe we could say it like "If the packet contains a packet sequence
number, it MUST be processed this way" ?

> More discussion would be welcome

You are mixing up Hello (message) processing with packet sequence
number processing. The packet header does not contain INTERVAL_TIME or
VALIDITY_TIME TVLs.

> my suggestion in 10.1 below.

Normally this would be an implementation bug, because the packet
sequence number should be increased for every sent packet.

We could add a check for this, but I am not sure it would really help.

> L_DAT_last_pkt_seqno - 15 and L_DAT_last_pkt_seqno -- we "undo history"

The algorithm does not store which sequence numbers were received and
which not, so it could not undo the history.

Sequence number going backward for a few numbers would be considered a
jump of 6553x forward.

> objection to keeping the current behaviour, just make it clear what's

I think its worth keeping the statistic... the whole thing happened
within a Hello Validity time (otherwise the link tuple would have been
removed), so the data is still valid.

> it.  Doing this, however, implies further complexity in step 2.3 of 9.3.)

No.

This function does two jobs...

if you have a neighbor that does not deliver packet sequence numbers
(or you just cannot receive them), it will count a Hello-timeout as a
packet loss.

if you have a neighbor that DOES deliver packet sequence numbers, you
count the Hello-timeout events since the last received packet. It is
used to estimate the loss, but this estimation is instantly removed
when you receive the next packet.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 Nov 2014 21:46:17 +0100

> Are you talking about ETT? Because ETX doesn't include the link speed.

Yes, I meant ETT.  I think you should rewrite this section to state that
DAT is a simplified version of ETT, which is itself a significant
improvement on ETX (at least for the 802.11 MAC).  (Assuming you agree
with this assessment, of course.)

> number processing.

Yes, I am.  Sorry for that.

Henning, I've looked through all of my comments in light of your
clarifications -- your answers are very helpful.  I think that all of them
should be part of the draft.

In particular, I believe you need to clarify:

  - how the incoming metric is the right thing due to 7181;
  - that you rely on only measuring loss over multicast;
  - that it's not the metric's job to drop associations;
  - how you "automatically" fall back to timeout-based computation;
  - how seqno resets don't require discarding all statistics.

-- Juliusz