Subject: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2013 14:13:28 +0200

Dear list,

Henning Rogge has asked me to repeat and clarify the comments that
I made about draft-rogge-baccelli-olsrv2-ett-metric-02 in Berlin.  So
here it goes.

0. I'm delighted to see this draft.  It has been known for almost
a decade that hop-count is not a good choice for mesh networks, where
it tends to prefer marginal links to solid links (some people like to
speak of "worst path routing").  If OLSRv2 is to be relevant to real
deployments, this draft or something very much like this is essential.

1. This is not ETT.  This is a unidirectional link rate/packet loss
metric very much unlike ETT.  It MUST NOT be called ETT, or anything
that might cause confusion with ETT.

Suppose, for example, that Henning's metric doesn't work out.  Then
whenever we suggest using ETT, people will tell us "I thought that ETT
didn't work", and we'll have a lot of explaining to do.

Note that I don't care what you call it, as long as confusion is
avoided.  For example, one of the metrics used by Babel is called
"Z3", and our users are quite happy to speak of the "Z3 metric",
although they have no idea what the Z and the 3 stand for.  (It was
the third metric inspired by an IRC chat I had with somebody whose
nick starts with a Z.)

2. This is not ETT.  Unlike ETX/ETT, which have been extensively
studied in the peer-reviewed litterature, I know of no publications
about a unidirectional packet loss metric combined with link rate.
While I'm pretty sure it will work out fine, I'd like to see hard data
showing that this metric does in fact work.

Alternatively, and preferably, I think that Henning should switch to
pure ETT, so that he can draw on the wealth of previous experience
with that particular metric.

3. Unfortunately, there is no place in the OLSRv2 packet format to
carry the inverse packet loss needed to compute full ETX/ETT.
I believe that such a standardised place should be provided, and
suggested that Henning should define that.  Stan indicated that Chris
might be a better choice.  Chris shrugged.

Regards,

-- Juliusz

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 7 Aug 2013 14:21:04 +0000

I don't believe "Chris shrugged" is an accurate representation.

There are multiple levels at which you have to consider addition of the sort of information you suggest:

- Is there a possible place in the packet or message structure (I'll come back to which in a later point) to add the information? There we have a flexible format that could certainly include anything you want.

- Is there a specification of a format in which to carry the information? No, not at present, but TLVs can, and have been, defined as needed.

(So whether your "Unfortunately, there is no place" is correct depends on whether you meant, no place defined, or no place definable. As it could mean the latter, which is not so, I think it's unfortunately phrased. Actually even if you meant the former, I don't find it unfortunate at all, I find it good design to not specify things unnecessarily when you still don't know what you want, as you are just likely to get it wrong. And "standardised place" is also not quite right, it's not in a fixed place - beyond which TLV block it belongs in - but a defined means of attaching the information.)

- This appears to need a protocol to handle that information. Where does that protocol live? Here you have to be very careful. (We've already discussed that Henning's metric needs some consideration here,) The formal position is that we have what we usually call the 5444 multiplexer/demultiplexer. It owns packets, and additions to the packet header, such as packet TLVs. If you want to consider all packets on an interface then you are interacting with this process. If you want to report this at all times, you need to do this in the packet header, as there may not be any relevant messages. (Alternative, create what is also a new protocol with a new message type. This would appear to be a bad idea, for a number of reasons, at least without a good reason why.) Or if measuring all packets, but only reporting less often, say in HELLO messages, then you are now creating what is also an extension to NHDP.

- If your protocol does work, calculates a metric, does what it has to do (update the appropriate L_in_metric) then it's an extension to NHDP (that owns the Link Set being updated) and OLSRv2 (which added that element to a Link Tuple).

- While you can start by considering what is sent to whom without getting into these details, before you finish you'll need to have those points (relationship to 5444, NHDP and OLSRv2, exacty TLV specifications) pinned down, or you won't get through the IESG. (You shouldn't get through the WG before that.)

- And there are some things to get right - such as needing an L_in_metric as soon as a neighbour is heard. You might have to make that "maximum until know better", but as currently defined, I don't think you can make unknown pending information.

So in summary, all is possible, but the devil is in the details, which need to be got right.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juliusz Chroboczek
Sent: 07 August 2013 13:13
To: [email-masked]
Subject: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Dear list,

Regards,

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Joe Macker <[email-masked]>
Date: Wed, 7 Aug 2013 14:31:02 -0400

Sent from my iPhone

> showing that this metric does in fact work.

i agree this is not ETT and should be called something else
> with that particular metric.

good topic for further discussion
> might be a better choice.  Chris shrugged.

i think an extension in nhdp aignaling is the better place to get the initial ETT metric. could then be consumed by and carried in metric packets of routing such as LS updates

---

From: Henning Rogge <[email-masked]>
Date: Wed, 7 Aug 2013 20:40:18 +0200

> i think an extension in nhdp aignaling is the better place to get the initial ETT metric. could then be consumed by and carried in metric packets of routing such as LS updates

I think the easiest way to allow this signaling is to request an
additional message-type specific address-tlv for NHDP Hello messages.
Every link metric can use this TLV with the same extension type to
transport any kind of data to the other side of the link to be
received and processed there.

It wouldn't be necessary for a directional metric, but might be
necessary for a 'symmetrical' metric.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Teco Boot <[email-masked]>
Date: Wed, 7 Aug 2013 21:44:15 +0200

> necessary for a 'symmetrical' metric.

My experience with ETX is that in practice, links are not symmetric.
Same for data rate.
The Directional-ETT as proposed doesn't need signaling over the air.
I suggest to keep the proposal as is and not to comply to a formal ETT specification.
Just rename will do.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 8 Aug 2013 12:10:51 +0000

If this is a metric for OLSRv2, ask yourself why you want a symmetric metric. The metric used in OLSRv2 is, by design, directional, both because links are different in the two directions (for several reasons) and because it avoids having to negotiate a metric. Now if you introduce a protocol to ensure a symmetric metric, you will then pass it to OLSRv2, which will then proceed to ignore that the metric is the same in each direction. The only win is that the metric storage in the message will be more compact, but you'll then throw that away in the negotiation. The negotiation will also reduce responsiveness to change, but that may or may not matter as you don't want to be too responsive.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 07 August 2013 19:40
To: Joe Macker
Cc: [email-masked]; Juliusz Chroboczek
Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 01:10:37 +0200

> If this is a metric for OLSRv2, ask yourself why you want a symmetric metric. 

We don't particularly want a symmetric metric.  It just turns out that
the metrics that have been shown to work well with the 802.11 MAC
happen to be symmetric.

ETX and ETT are metrics that are designed to model more or less
accurately the behaviour of the 802.11 MAC, which uses ARQ for unicast
frames.  They try to take into account the fact that both the airtime
and the number of txops consumed when sending a unicast frame depends
on the loss probability in both the forward and the backwards directions.

ETX and ETT are certainly not perfect, but they would appear to model
802.11 better than a simple packet loss metric.  While both are
symmetric as described in the litterature, it would be quite
reasonable to design a variant of ETT that takes into account the
differing size of data and acknowledgment frames, and therefore would
no longer be symmetric.  However, I don't know of any peer-reviewed
hard data that shows that such a metric behaves better in practice
than plain ETT.

-- Juliusz

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 12 Aug 2013 11:22:57 +0000

OK. We need to be clear on the applicability, but that's a detail.

Given your comments, and the requirements of OLSRv2 both to have a metric immediately, and that it doesn't need to be symmetric, the following would be my (not fully thought through) first thought.

- You need a metric immediately. In the absence of any other information you may have a forward measure, you'll have to assume backward is poor, and combine those two.

- Later you will have backward information, e.g. in a TLV in a HELLO message. You can then revise your combined forward/backward metric - but used to represent the inward metric. The combination can be asymmetric if you like, or symmetric.

- The other end does the same to get its inward metric, your outward metric. If using a symmetric combination these may well be the same, which makes for more efficient HELLO messages. But you don't make that assumption. If your neighbour tells you a significantly different view of its in, your out, metric (in a HELLO message) than your view of your in metric then you have two choices (a) ignore the difference, use what you are given. Under no circumstances substitute your value for its value, that's a looping problem waiting to happen, (b) recognise this is really messed up and reject the link. Exactly how to do the latter is stepping outside NHDP, but permitted by its extension clauses. Personally I'd go with (a).

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
Sent: 12 August 2013 00:11
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; Joe Macker; [email-masked]
Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 18:36:04 +0200

> - You need a metric immediately.

I think I strongly agree with you -- if OLSRv2 is to be relevant in
The Real World (as opposed to simulation), it needs to come with
a reference metric that works better than hop count.  I am fairly
happy with Henning's work (up to some editorial changes that I still
haven't had time to fully write up), and the only point I have strong
feelings about is that it should be renamed to avoid confusion with ETT.

As to the other points -- I'm glad that you are aware of the issue
(and, perhaps immodestly, I like thinking that I've been instrumental
in helping people think about it), but I don't think it is as urgent
as Henning's current work.

(We're currently experimenting with some very exciting new metrics in
the Babel world, and at least some of that work should be relevant to
OLSRv2.  Unfortunately, my current favourite metric, Z3, is not isotonic,
and hence cannot be used with Dijkstra's algorithm.)

-- Juliusz

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 12 Aug 2013 10:05:50 -0700

I think that Chris meant that a router needs to send out a metric to a
newly discovered neighbor, even if it has not yet received the inbound
metric from that new neighbor.

That's different from the question whether we need a new metric
specification. I am in favor of working on a such a document, but I
would like to see a new revision first. Chris mentioned a few good
points recently in an email [1]. I think these should be addressed
before the document is considered for WG adoption.

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

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 12 Aug 2013 17:12:29 +0000

I think you have misinterpreted what I meant.
(I just see Ulrich has made the same point, so I don't need to explain.)
That's not to say I disagree with you, just that's not the point I made.

Of course OLSRv2 already has non-hop count metrics. Whatever you like. As an example, a trivial - but nonetheless useful - one is a small set of well-separated values for a set of different bandwidths. It's not standardised, so it's specific to a network, and needs appropriate management. But you can do it today (or for some time).

(Note that I'm not considering Wi-Fi networks here, but rather heterogeneous networks with inherently quite different types of links.)

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
Sent: 12 August 2013 17:36
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Comments about draft-rogge-baccelli-olsrv2-ett-metric-02

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 19:35:27 +0200

> metric from that new neighbor.

Ah, I had read "immediately" and "later" as current and later
specifications.  Sorry for the misunderstanding.

(Note to self -- don't reply to e-mail just before supper.)

-- Juliusz