Subject: [manet] NHDP: Link quality based on seq-num

From: "Teco Boot" <[email-masked]>
Date: Mon, 9 Nov 2009 10:33:01 +0900

In NHDP-11 14.4, it is suggested that a node should 
receive all sequential packet sequence numbers from
its neighbors.
I think this is an invalid assumption. A node could
send packets out of multiple interfaces. Sequence 
numbers are per packet, not (per packet, per interface).

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 9 Nov 2009 07:28:16 +0100

> numbers are per packet, not (per packet, per interface).
Packet sequence numbers should be interface specific I think. It doesn't make 
sense to make them node specific.

Unfortunately Teco is right, we specified them differently in packetbb:

   o  The <pkt-seq-num> field, if present, contains a sequence number
      that is incremented by 1 for each packet generated by a node.  The
      sequence number after 65535 is 0.  In other words, the sequence
      number "wraps" in the usual way.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 09:57:26 -0000

> Sequence numbers are per packet, not (per packet, per interface).

Packet sequence numbers are how you choose to use them.
Not even in the intended usage section of RFC 5444 does
it say either. If you want to use them in this way then,
like OLSRv1, they would need to be per interface, and it
would be a good idea to say that. But it's permissible.

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 10:00:35 -0000

Bother, I missed this one, both them and now.

That requires some thought. Thanks to Teco for pointing this out.
This was not the intent of course, I think this got put in in the
various editing to pass reviews and was badly specified.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 Henning Rogge
Sent: 09 November 2009 06:28
To: [email-masked]
Subject: Re: [manet] NHDP: Link quality based on seq-num

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Nov 2009 19:17:53 +0900

I agree with Teco that issue is important, also for my performance
section in MIBs.

Ulrich

On Mon, Nov 9, 2009 at 7:00 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 11:03:39 -0000

My, not fully worked out, thought is that per interface
packet sequence numbers should be allowed, or even
preferred. That leaves a procedural issue of how to get
from where we are to where we want to be.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 09 November 2009 10:18
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] NHDP: Link quality based on seq-num

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Nov 2009 22:11:27 +0900

> from where we are to where we want to be.

I agree that we should allow packet sequence numbers per interface. At
the moment, I cannot think about a good reason for not preferring
them, but maybe there is...

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 9 Nov 2009 23:31:16 +0900

What if someone defines a reliable transport and suppress 
repeating messages?
Are we sure we want to use missing sequence numbers as 
indication of missed packets?
What if other reasons caused the loss, e.g. tail drop during 
congestion caused by the MANET protocol itself?

Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Ulrich Herberg
>Verzonden: maandag 9 november 2009 22:11
>Aan: Dearlove, Christopher (UK)
>CC: [email-masked]
>Onderwerp: Re: [manet] NHDP: Link quality based on seq-num
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 9 Nov 2009 15:37:39 +0100

> congestion caused by the MANET protocol itself?
Packet Sequence numbers have the same "range" as a linklocal IP, so I don't 
see any problem with reliable transports. Such a transport would be built 
"below" packetbb, so the mechanism should be transparent to packetbb.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 9 Nov 2009 23:38:49 +0900

Teco,

I think that "counting packets" is one tool that may be used, but by  
no means *the* tool to be used in all situations. If you're running  
over a lower layer with known delivery/drop properties and the ability  
to extract "other information" describing how good the link is  
(SNR, ...), then that "other information" would be a better choice for  
when setting quality.

Thomas

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Nov 2009 23:41:29 +0900

Teco,

> What if someone defines a reliable transport and suppress

In that case, that mechanism of using packet seq. numbers would not
work. But I think this is okay, since the NHDP draft does not mandate
this mechanism. If one decides to use packet sequence numbers for
indicating lost packets, one probably has to assume a non-reliable
transport transport protocol such as UDP.

> indication of missed packets?

No, we don't want to mandate it. It is just *one* possible way, under
certain assumptions (no reliable transport protocol).

> congestion caused by the MANET protocol itself?

Well, in that case the router will face problems anyway, since it does
not receive control traffic any more.

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Nov 2009 23:44:59 +0900

> "below" packetbb, so the mechanism should be transparent to packetbb.

I don't see the relation to LL here. I think what Teco means is that
if NHDP runs on a reliable transport, a very bad link (that needs many
retransmissions of HELLOs) still would appear as perfect link to NDHP,
because no packetbb packet is lost. So, of course the transport
protocol is transparent to NHDP, but using packet seq. no. as measure
of number of lost packets would not make sense any more.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 14:47:38 -0000

> What if someone defines a reliable transport and suppress 

There are many ways in which this is not relevant
- NHDP messages are local broadcast. If you have a reliable
  local broadcast mechanism to unknown recipients, I think
  we'd like to know.
- The transport mechanism sees packets, not messages. These
  are much less likely to be repeats. but even messages may
  not be repeated, due to e.g. message sequence numbers and
  security mechanisms.
- It's no business of the transport mechanism to do this.
  There are reasons to repeat messages due to mobility, trying
  to find unknown nodes etc.

> indication of missed packets?

It's an option. Nothing in that area is something that must
be done. It's not my first choice of options, I think there
are better ones. But that doesn't make it unusable.

> congestion caused by the MANET protocol itself?

If your congestion gets to the point where sufficient dropping
is occurring to make this happen, then there is a real problem in
any case, especially if (as one should) give routing signalling
a better than average priority.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 14:51:03 -0000

> I think what Teco means is that

If you have such a reliable transport layer (except I don't
believe in it because it's not unicast, but ignore that for
now) then I would want the retransmission rates from that
transport layer as a supplement or replacement to packet
sequence number. It's not alone in that - I'd like all the
information I can get.

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Nov 2009 23:54:22 +0900

On Mon, Nov 9, 2009 at 11:51 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> now)

I think this was more a theoretical assumption...

> then I would want the retransmission rates from that

Yes, true. But this would require some cross-layer information. I
agree that in that case, it would be necessary to get some information
from the transport protocol.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 00:02:56 +0900

Hi Ulrich,

>Van: Ulrich Herberg [mailto:[email-masked]]
>Verzonden: maandag 9 november 2009 23:41
>Aan: Teco Boot
>CC: Dearlove, Christopher (UK); [email-masked]

You missed my point.
The protocol would suppress the repeated info.

>certain assumptions (no reliable transport protocol).

But it is an impossible way, as defined today in the spec.

>not receive control traffic any more.

And send more traffic. See a nearby museum for what can happen if a system
is speeding up its own explosion. 

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 10 Nov 2009 00:08:52 +0900

> The protocol would suppress the repeated info.

Then I do not understand. Your L2 (or "something-behaving-as-L2")  
below IP is reliable. That's fine, you'll get 100% of packets across.  
A great L2 and a great feat if you can do reliable broadcast to an  
unknown recipient set (I'd like to learn more if you have one at hand).

> But it is an impossible way, as defined today in the spec.

How so? Your L2 does not lend itself to "counting packets" - so you  
won't, you'll use something else (more appropriate to your L2) for  
establishing the quality.

This is not only enabled by the spec, but even recommended.

> is speeding up its own explosion.

I think that's an inappropriate reference.

I also think that it's an inappropriate and incorrect characterization  
of what NHDP would do....

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 00:09:56 +0900

Hi Ulrich,

>Verzonden: maandag 9 november 2009 23:45
>Aan: Henning Rogge
>CC: [email-masked]; Teco Boot; Dearlove, Christopher (UK)

Yes, this is an example the mechanism breaks.
I had IP layer in mind, like PIM over TCP. PIM started with repeating
advertisements, but for scalability and other reasons, the protocol is
extended for using reliable transfer (draft-ietf-pim-port).

In my MANETs, I have low bandwidth high costs links and cannot afford 
the repeating MANET messages over it. With reliable multicast (or 
unicast, if the link is P2P), I could suppress. Sequence numbers may 
break this idea.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 00:17:26 +0900

Hi Chris,

>Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
>Verzonden: maandag 9 november 2009 23:48
>Aan: Teco Boot; Ulrich Herberg
>CC: [email-masked]
>Onderwerp: RE: [manet] NHDP: Link quality based on seq-num
>

PGM and NORM can do the job.

>  not be repeated, due to e.g. message sequence numbers and

Yes, see other posting. Why are the sequence numbers incremented
For each packet? Sorry, it could be written in the draft and I
have overlooked it. 

>  to find unknown nodes etc.

For hello, especially incremental hello, reliable multicast
doesn't help. For TC, it is another story. 

>are better ones. But that doesn't make it unusable.

After the fix, I can agree.

>a better than average priority.

Yes, but broadcast queues with infinite depth have drawbacks to.
Especially when giving priority to it. At least, we need some form 
of shaping or fair queuing.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 00:22:34 +0900

>Verzonden: maandag 9 november 2009 23:54
>CC: Henning Rogge; [email-masked]; Teco Boot

NACK based reliable multicast does not provide the info that is needed.
But yes, the info that becomes available could be used for MPR selection.

The idea is more serious than theoretical assumption. When the performance
of MANETs degrades due to TC load, we could take a look at this.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 00:38:57 +0900

>Van: Thomas Heide Clausen [mailto:[email-masked]]
>Verzonden: dinsdag 10 november 2009 0:09
>Aan: Teco Boot
>CC: 'Ulrich Herberg'; 'Dearlove, Christopher (UK)'; [email-masked]

100% delivery ratio is the goal of reliable multicast.
But at cost of delay and other annoying aspects.
It runs at layer 4 (instead of UDP or vanilla IP).

>This is not only enabled by the spec, but even recommended.

Back to my first comment, the spec needs a fix. Then, we can recommend
to use it. But only when sequence numbers are used. 
We could regret this in the future, when working on optimizing TC load.

>I think that's an inappropriate reference.

I've seen network meltdowns, including MANETs. This meltdown term is
borrowed
from nuclear catastrophes.

>of what NHDP would do....

Did I say so?

But yes, network meltdowns due to chain reaction is a real world concern.
It is definitely not specific to NHDP/OLSR. But these are also not immune.

Can we go back to my first comment, and fix this minor issue?

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 10 Nov 2009 00:47:50 +0900

> It runs at layer 4 (instead of UDP or vanilla IP).

However, if you run it for NHDP, it would effectively look as a "very  
good L2", yes?

> We could regret this in the future, when working on optimizing TC  

What do you suggest to fix in the spec? If it does say "you MUST use  
sequence number counting", then the spec is wrong. If the spec says  
that "sequence number counting MAY be used, if nothing better is  
available", then I am not sure what's wrong?

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 16:53:22 -0000

> the repeating MANET messages over it.

Change the message intervals, possibly adaptively.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Nov 2009 16:56:20 -0000

> Can we go back to my first comment, and fix this minor issue?

Assuming that's the "packet sequence numbers should be
per interface, not per node/router to be useful" then
yes. I'm not sure what the appropriate procedure is
(errata to RFC 5444?).

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 10 Nov 2009 02:00:32 +0900

> yes. I'm not sure what the appropriate procedure is

Unless I recall a really good reason for it being as it is in 5444,  
then I agree with Chris. We talked earlier today and couldn't recall  
any justifications, so it might just have slipped through the editing  
cracks (drat!).

Give me a couple of days after this IETF to dig through my archives of  
notes - failing any discoveries, we issue an errata?

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 04:47:39 +0900

Hi Thomas,

>However, if you run it for NHDP, it would effectively look as a "very

Yes.
I did not suggest exchanging hello messages over it. For TCs, originated
from over the place, it would make sense. OSPF tackles the problem
from the other end of the spectrum, here we have only the reliable LSA
transfer.

>available", then I am not sure what's wrong?

I recommend using hello messages sequence numbers only.

It need more thoughts, but what about using hello msg-seq-num?
Hello messages could have msg-seq-num per interface. Then, we 
have the timer based detection and the sequence number detection, 
both using hello messages. 
We need a RFC5444 errata on msg-seq-num if we use this.
I think it makes sense to have hello incrementing msg-seq-num per
interface and incrementing TC msg-seq-num per message. The errata
would say incrementing sequence numbers for 1-hop advertized messages
and packets must have per interface numberspaces.

For TCs, I prefer not incrementing the msg-seq-num for repeating,
identical messages. Then, suppression or reliable transfer with
regenerating the repeating messages becomes doable. 
Also, the receiving node has better knowledge on having a topology 
update or not, by checking the sequence number only. Little gain here,
but still.
With this approach, the OLSR spec would say the repeating TC message is
not regenerated each time send out. The mechanism shall be implemented 
on a generating node A for support for a suppressing node B. So it needs
implementation on all nodes for interoperability.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 04:53:15 +0900

>Verzonden: dinsdag 10 november 2009 1:53
>Aan: Teco Boot; Ulrich Herberg; Henning Rogge
>CC: [email-masked]

This won't work in a heterogeneous network. On parts in the MANET, we can 
afford and take the benefits of high rate repeating messages, where in 
other parts this would overwhelm the link.
The hop-limit feature is helping somewhat, but not sufficient.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 9 Nov 2009 21:09:45 +0100

> I recommend using hello messages sequence numbers only.
I thought we were talking about packet sequence numbers. Message sequence 
numbers are something totally different.

> and packets must have per interface numberspaces.
I don't think that makes sense Teco.
 
> update or not, by checking the sequence number only. Little gain here,
That's why TCs have an answer-set number.

> implementation on all nodes for interoperability.
I think you are really mixing up multiple sequence numbers in OLSR. At the 
moment we have three different numbers:

1.) packet sequence numbers. They have some kind of "link local scope" and can 
be used for estimating the packet loss on a link.

2.) message sequence numbers. These are "end to end", generated by the 
originator of the message and are used for duplicate detection.

3.) answer set numbers. They are only in the TCs and are increased every times 
the topology information a nodes sends has changed.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 07:46:36 +0900

Hi Henning,

>Van: Henning Rogge [mailto:[email-masked]]
>Verzonden: dinsdag 10 november 2009 5:10
>Aan: [email-masked]
>CC: Teco Boot; 'Thomas Heide Clausen'; 'Dearlove, Christopher (UK)'

Yes. But my recommendation is to use msg-seq-num. I'm not sure
all packets send via an interface are received by all neighbors.
For hello's, I'll say this is a valid assumption. Or we can make
it mandatory for NHDP. I heard Justin the other day promoting 
PacketBB for a very different application. What if I write a 
draft on multicast joins / prunes, that uses unicast?

>That's why TCs have an answer-set number.

It must have been the product of jet-lag, readability of the draft and
a TLV for just a seq-num. By the way, did you mean the sequence number 
as value in TLV CONT_SEQ_NUM, called ANSN?.

>be used for estimating the packet loss on a link.

IMHO this is not always true.

>originator of the message and are used for duplicate detection.

OK. But then, are they mandatory for TC?

>the topology information a nodes sends has changed.

Is this OLSRv2?
I need more time to read this over.

Teco.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 10 Nov 2009 09:52:06 +0900

Thomas,

On Tue, Nov 10, 2009 at 2:00 AM, Thomas Heide Clausen
<[email-masked]> wrote:
>[..]
> Unless I recall a really good reason for it being as it is in 5444, then I
> agree with Chris. We talked earlier today and couldn't recall any
> justifications, so it might just have slipped through the editing cracks
> (drat!).
>
> Give me a couple of days after this IETF to dig through my archives of notes
> - failing any discoveries, we issue an errata?

Yes, I think that should be considered. Using packet seq number per
interface instead of per node should solve the problem.

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 10 Nov 2009 09:57:31 +0900

> moment we have three different numbers:

Are we talking about OLSR or OLSRv2 here? I assume the latter...

> the topology information a nodes sends has changed.

This is an accurate description (besides that it's not "answer set
number", but "Advertised Neighbor Sequence Number" or ANSN).

Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 10 Nov 2009 10:00:14 +0900

On Nov 10, 2009, at 9:52 AM, Ulrich Herberg wrote:

>> then I

Agree. I just want to check that it's like it is "by accident" and not  
"by forgotten reason" :)

Thomas

---

From: "Justin Dean" <[email-masked]>
Date: Mon, 9 Nov 2009 23:38:52 -0500

I understand the argument for changing packet sequence numbers from global
space to interface spaces, and think I have actually made this argument in
the past, but I have a nagging feeling that there is some drawback which we
are currently missing.  Aggregated interface reception perhaps?

Justin

> Sent: Monday, November 09, 2009 7:52 PM
> To: Thomas Heide Clausen
> Cc: Dearlove, Christopher (UK); [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Tue, 10 Nov 2009 08:59:16 +0100

> draft on multicast joins / prunes, that uses unicast?
The packetbb IANA RFC 5498 suggests to use a linklocal multicast group for 
sending NHDP/OLSRv2/... packets. So I think it's mandatory that all 
transmitted TCs will be received by all neighbors.

> as value in TLV CONT_SEQ_NUM, called ANSN?.
Yes, sorry... ANSN (advertised neighbor sequence number)
 
> >> With this approach, the OLSR spec would say the repeating TC message
> >
> >is
> >
> >> on a generating node A for support for a suppressing node B. So it
> >
> >needs
> >
It can be used to estimate the packet loss on the layer NHDP/OLSRv2 is working 
on. Of course this is not the true packet loss if you have a retransmission on 
a lower layer.

> I need more time to read this over.

OLSRv2 draft, section 8.2:

  A TC message MUST contain:
....
   o  <msg-seq-num> and <msg-hop-limit> elements, as specified in
      [RFC5444].
...
   o  A single Message TLV with Type := CONT_SEQ_NUM, and Type Extension
      := COMPLETE or Type Extension := INCOMPLETE, as specified in
      Section 8.2.1 (for complete and incomplete TC messages,
      respectively) except that the latter MAY be omitted if the message
      does not contain any addresses associated with a TLV with Type =
      NBR_ADDR_TYPE or Type = GATEWAY.

So yes, message sequence numbers and CONT_SEQ_NUM (which contains the ANSN) 
are mandatory for TCs.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 10 Nov 2009 09:28:40 +0100

> are currently missing.  Aggregated interface reception perhaps?
Hmm...

what is the advantage of using packet sequence numbers per node instead of per 
interface ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 10 Nov 2009 23:04:30 +0900

>what is the advantage of using packet sequence numbers per node instead

If two interfaces are on same medium, we have the aggregation.
There are other issues with such a setup, e.g. per_interface_MPR. 
Is this scenario analyzed before?

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 10 Nov 2009 15:48:11 +0100

> Is this scenario analyzed before?
You mean two interfaces sharing a physical interface but kept separate (for 
example with VLANs) ? I still don't see any advantage of a "per node" packet 
sequence number. Maybe you can explain your scenario and the advantage of the 
"per node" thing a little bit more ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 07:03:50 +0900

>example with VLANs) ?

Not isolated with VLANs. Assume box with multiple radios, attached
to directional antennas.

> I still don't see any advantage of a "per node"
>packet
>sequence number. 

The discussion is what to do, per packet seq-num or
(per packet per interface). Using the latter can be
dangerous in this scenario, as a neighbor could get 
both packets and will get mixed up by the two seq-nums,
as they are not nicely ordered anymore.

Teco.

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 11 Nov 2009 08:45:12 +0900

Teco,

On Wed, Nov 11, 2009 at 7:03 AM, Teco Boot <[email-masked]> wrote:
>[...]

But would that matter? We still have message sequence numbers to
detect duplicate messages (the message sequence number is created per
router). And we have the ANSN to detected which TCs are newer. I do
not see how that could be harmful. Can you describe an example?

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 08:56:33 +0900

>not see how that could be harmful. Can you describe an example?

What brings pkt-seq-num?

What happens when router receives msg A on int A, and discard
because not being MPR. Then it receives msg A on int B, and discard
because seen before on int A, but is MPR. MPR broken?

Teco.

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 11 Nov 2009 09:25:19 +0900

>>not see how that could be harmful. Can you describe an example?

I think they bring nothing if not used for something like a link
quality mechanism. Note that neither NHDP nor OLSRv2 forces them to be
used. The only place where NHDP mentions packet sequence numbers is:
      "If control packets include a
      sequential packet sequence number, as defined in [RFC5444], then
      link quality can be updated when a control packet is received,
      whether or not it contains a HELLO message.  The link quality may
      then, for example, be based on whether the last N out of M control
      packets on the link were received, or may use a "leaky integrator"
      tracking packet reception and loss."

The OLSRv2 draft does not mention packet sequence numbers (correct me
if I am wrong).

> because seen before on int A, but is MPR. MPR broken?

But discarding a message is only based on message sequence number, not
packet sequence number.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 10:30:40 +0900

(new thread)

I asked:
> because not being MPR. Then it receives msg A on int B, and 
> discard because seen before on int A, but is MPR. MPR broken?
Response appreciated.

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 11 Nov 2009 10:34:05 +0900

>> discard because seen before on int A, but is MPR. MPR broken?

No, that is not a problem - the selection algorithm proposed in OLSR  
and OLSRv2 handles this correctly.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 12:04:45 +0900

Thanks. It seems this is another scenario requiring per interface MPR.
I still do not like it, but having this scenario leads me towards 
acceptance. But MPR still doesn't support my Ethernet scenario posted 
months ago.

Reading back OLSRv2-10, I think text around "Received Set" needs revision.
It is not "received", but "received via symmetric link". Messages could
be received via asymmetric link and be processed. This is OK. But then,
the message is in Processed Set and not in Received Set. This looks not
obvious, and can lead to misunderstanding. At leased, 6.4.1 needs 
adjustment, and I prefer more text wherever Received set is mentioned.
or rename it, to such as MPR_Received Set or Received_SL Set.

Teco.

>Verzonden: woensdag 11 november 2009 10:34
>Aan: Teco Boot
>CC: [email-masked]
>Onderwerp: Re: [manet] MPR and multiple interfaces on same medium
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 11 Nov 2009 12:10:41 +0900

> acceptance. But MPR still doesn't support my Ethernet scenario posted

I have been running OLSR and OLSRv2 over also Ethernets for years,.  
Can you remind me, what's not working?

<SNIP - something which is to address in a different email>

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 12:26:17 +0900

(new thread)

As far as I know there is a MPR over Ethernet use case with MPR 
problems. The scenario was discussed as follow-up on:
 http://www.ietf.org/mail-archive/web/manet/current/msg11061.html

Thomas, I remember you thought there was a mechanism for a fix.
Maybe you had jitter in mind, but IMHO this is not a real solution.
Especially when SMF is in use.

Here the scenario:

        +---+   +--------+   +---+
       /| B |---| switch |---| E |\
      / +---+   +--------+   +---+ \
+---+/               |              \+---+
| A |                |               | F |
+---+\               |              /+---+
      \ +---+   +--------+   +---+ /
       \| C |---| switch |---| D |/
        +---+   +--------+   +---+

Network B-C-D-E is full connected.
B selects D as MPR.
C selects E as MPR.
Packets sent by B are received by E before received by D.
Packets sent by C are received by D before received by E.
The delay between the switches can be quite large.

I mentioned the same scenario can be set up with
whatever L2 technology, including sub-IP MANETs.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 09:47:36 -0000

You do not have to use the same intervals in all parts
of the network. You trade off bandwidth and responsiveness
of course, but this does not have to be the same across
the whole network, and if it is heterogeneous this may
well be appropriate. Of course that still leaves the
fastest rate TC messages impacting on the whole network,
so decisions can't entirely be local. The abilities for
both variable (possibly adaptive) and variable hop-count
(Fisheye/HSLS) mechanisms may also help. But if you have
a heterogeneous network with quite different characteristics
you have problems to solve in any case.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 09 November 2009 19:53
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: RE: [manet] NHDP: Link quality based on seq-num

                    *** WARNING ***

>Change the message intervals, possibly adaptively.

This won't work in a heterogeneous network. On parts in the MANET, we
can 
afford and take the benefits of high rate repeating messages, where in 
other parts this would overwhelm the link.
The hop-limit feature is helping somewhat, but not sufficient.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 09:52:07 -0000

> identical messages.

That does not work. The TC message sequence number is there
to manage duplicates in flooding. Make it constant, and no
second copy of a message will ever be delivered and the network
will disintegrate.

Freshness of information is in the ANSN. The message sequence
number does a different job. NHDP/OLSRv2 are designed for
unreliable networks. If you have a reliable network you may
want to redesign, but I see no evidence that a reliable
local broadcast mechanism is anything other than a thought
experiment.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 10:00:09 -0000

There is a question as to whether we change completely,
or change to A or B. That is partly a question about
errata as well as technical.

-----Original Message-----
From: Justin Dean [mailto:[email-masked]] 
Sent: 10 November 2009 04:39
To: 'Ulrich Herberg'; 'Thomas Heide Clausen'
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: RE: [manet] NHDP: Link quality based on seq-num

                    *** WARNING ***

I understand the argument for changing packet sequence numbers from
global
space to interface spaces, and think I have actually made this argument
in
the past, but I have a nagging feeling that there is some drawback which
we
are currently missing.  Aggregated interface reception perhaps?

Justin

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 10:13:47 -0000

> because seen before on int A, but is MPR. MPR broken?

MPR is not broken. What happens is described in the
specification. That it works is proved in INRIA reports
on MPRs. Note that what matters with MPRs is not that
a destination X gets a message from a node Y that picked
it as an MPR, it's that it gets it at all. Getting it via
node Z is quite acceptable. (This is, incidentally, at the
heart of why flooding MPRs are per interface.)

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 20:10:23 +0900

You are right on thought experiment. Because I have reasons for this.
Can I afford repeating messages over a costly link? (pay per MB)
How to run a large OLSR domain with some small bandwidth links? 

What matters is prevent blocking future enhancements, that optimize
TC via those links. The building blocks in my thought experiment
are fast topology database synchronization after restart or merged 
networks and partial update TC messages (e.g. seq-num only).

I'm not sure on lost TC msg recovery. MPR selection prefers fewest 
relay nodes, at cost of potential high loss ratio (depending on 
LQ implementation, algorithm etc.). It is a choice between
more MPR redundancy or more robust transfer over lossy links.
For multicast I don't see much happen at L2 for this. So we could
define something. Not today :-) Neither block it.

Teco.

>Verzonden: woensdag 11 november 2009 18:52
>Aan: Teco Boot; Thomas Heide Clausen
>CC: [email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 11:15:22 -0000

> MPR selection prefers fewest relay nodes

Not so. MPR selection may be according to any algorithm that
creates a set with the required properties (loosely, coverage
of all strict two hop nodes). A small, or smallest, set is
generally a good idea, but if an operator has a better idea
he is free to use it.

(The example algorithm generally has - but is not guaranteed
to have - minimal properties. But it is not mandated in any way.)

---

From: jacquet <[email-masked]>
Date: Wed, 11 Nov 2009 12:53:38 +0100

I will add that the MPR selection gives all flexibilities according to  
interface performance, in particular when the interfaces show very  
different performance between them or within them, as proposed in most  
Teco's examples.

Philippe

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 20:49:03 +0900

(passed to new thread)

I said "depending on algorithm", so I agree. But there 
is a large OLSRv1 community that complains on RFC default
behavior. 
In OLSRv2, the Link Quality defaults are "LQ disabled". This,
with the default / example MPR selection algorithm works the
way I meant.
We have here the same issue as link metrics: people implement
the RFC, test it (or run production immediately) and complain.

I am looking forward to text on ETX. Then, we have NLQ. With 
adding N2LQ in the hellos, we have more info for MPR selection 
for providing low loss.

Teco.

>Verzonden: woensdag 11 november 2009 20:15
>Aan: Teco Boot
>CC: [email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 11:54:58 -0000

> with the default / example MPR selection algorithm works the

It is not the default, it is an example. Frankly, we've made a
lot of tools available for people who either have unusual
characteristics, or expertise to get more out of what they have.
(That's including link metrics. Yes, they aren't in place, but
they will be in OLSRv2, once we can actually get NHDP - whose
WGLC period is long over - out of the door to the IESG.) That's
the best we can do to cover the range of possibilities. If
people run unusual cases, and ignore all of this, there's not
much we can do about that.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 11 Nov 2009 21:23:57 +0900

>   there's not much we can do about that.

Small adjustments may have large effects.
I suggest adjusting the defaults to:

===

14.4.  Updating Link Quality

   A router SHOULD update link quality based on any information available
   to it.  Particular cases that MAY be used include:

(skip)

15.4.  Link Quality Interface Parameters

   If link quality is changed, then parameter values will depend on the
   link quality process.  If link quality is not changed, then:

   o  HYST_ACCEPT := 0.8

   o  HYST_REJECT := 0.3

   o  INITIAL_QUALITY := 0.5

   o  INITIAL_PENDING := true

===

I'm fine with better defaults, whatever that may be.
It hasn't much meaning anyway, as there is no provided mechanism.
And the SHOULD above is a MUST. If LQ is not updated, the link is 
not used.

For an alternative MPR selection, this is not a small adjustment. 
I'll postpone to after seen ETX text.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Nov 2009 13:24:39 -0000

Default values of 0.8 and 0.3 are meaningless if you
haven't (and we neither can nor want to) define the
meaning of the scale. That's why we specifically
changed defaults from OLSRv1.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 11 November 2009 12:24
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: RE: [manet] Default LQ and example MPR

                    *** WARNING ***

===

   A router SHOULD update link quality based on any information
available
   to it.  Particular cases that MAY be used include:

(skip)

   o  HYST_ACCEPT := 0.8

   o  HYST_REJECT := 0.3

   o  INITIAL_QUALITY := 0.5

===

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 22:05:40 +0100

>changed defaults from OLSRv1.

The LQ parameters are dimensionless. The OLSRv1 defaults are not 
that bad.

>>  A router SHOULD update link quality based on any information

More important: the change from MAY to SHOULD. My experience is
that having LQ is crucial on those link types that are our primary
concern.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 09:32:59 -0000

The MAY to SHOULD thing is a tricky one. Personally I would
agree that you should (lower case should). But back when this 
was put together, there were some opinions not wanting to use
link quality, and the MAY, together with other wordings (noting
that if link quality never changes you don't need to record it)
was a compromise that kept consensus. I'd rather not re-open
that, despite personally being happy with SHOULD.

There is also an argument that this is not an interoperability
issue, it's entirely local to a router and is a quality of
implementation issue, and those don't need to be stressed as
strongly.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 16 November 2009 21:06
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: RE: [manet] Default LQ and example MPR

                    *** WARNING ***

Teco.