Subject: [manet] OLSRv2 and "per node MPR selection"

From: "Teco Boot" <[email-masked]>
Date: Wed, 8 Apr 2009 15:34:54 +0200

Posting is delayed because attachment. This is plain text message only.
Attachment is on http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf
Teco.

-----Oorspronkelijk bericht-----
Van: Teco Boot [mailto:[email-masked]] 
Verzonden: woensdag 8 april 2009 15:21
Aan: 'jacquet'; 'Charles E. Perkins'; 'Dearlove, Christopher (UK)'
CC: [email-masked]'
Onderwerp: OLSRv2 and "per node MPR selection"

Hi Philippe,

[changed subject]

|One special case: assume that you have two kinds of interfaces: slow and
|fast. If slow means very slow, then you may have a very long flooding
|time for a single packet if you merge interfaces for MPR selection.  You
|may even have no end at all;-)
|
|Consider the following network

  B***D
 / \  /\
A   \/  F
 \  /\ /
  C***E

I adjusted diagram somewhat, did you use proportional font?
The two asterisk lines are separate "slow" segments.
The other lines share the "fast" segment.
OK?
See also attachment.

|with all interfaces of type fast excepted (B,D) and (C,E), that are
|slow. 

I have problems with term "slow interfaces". Maybe the medium is "slow" or
there is some queuing (or jitter). I assume that I know what you meant:
"late arrival / long delay". Personally, I am sure "fast" interfaces can
connect a MANET router to a "slow segment", because this is what I deploy in
real world. Minor detail here.

|If all interfaces are merged for MPR calculation, then it can be
|that MPR of B and C are all on slow interface.

OK:
B selects D or E as MPR for path to C and F. Assume it is D.
C selects D or E as MPR for path to B and F. Assume it is E.

|Suppose MPRs of A are both B and C (there may be additional neighbors on
|B and C to force that).
|If A initiates a flood, then  B and C will retransmit simultaneously on
|fast interface and slow interface, but fast interface arrives first on D
|and E, both receive first from non MPR and cannot relay. F does not
|receive the broadcast.

Do you mean "from non MPR selector"???

Not sure on this.
Scenario:
A transmits, B and C receives the message.
B and C retransmit the message, one after each other,
on both "fast" and "slow" interfaces
D receives first on "fast" interface, from C.
C is not MPR selector (2.2.3), so message is discarded.
Same for E.
Then D receives the message on the "slow interface", from B.
Why is the packet not forwarded? Algorithm:
  1: is B symmetric neighbor? Yes, continue
  2: is msg received on "slow" interface before? No, continue
  3: is msg forwarded before? No, continue
  4: is prev_hop an MPR selector? Yes: FORWARD
Same for E.

What is the problem ???

Again, maybe I overlook something.

|When D or E eventually receive from the slow interface it could compare
|time stamps to actually decide that slow interface indeed had precedence
|on fast interface in race competition and finally to decide to actually
|retransmit. But again you come out with the performance of the worse
|interface (and a very complicated mechanism).
|
|If MPR are on per interface, then B will select E as MPR on fast
|interface
|and you gain on the fastest interface which will win the race
|competition.
|
|I think this was the issue (but I am not sure), but I agree that the
|result was a kind of compromise to keep things simple.

Not sure what "simple" means.

Side remark: both "per interface" and "per node" MPR based flooding can be
performed with RouterIDs. And the "per interface MPR selection" is maybe
somewhat less complex (I wonder), but the overhead on the "slow segment"
looks unacceptable to me.

Again, I might overlook something here...

If agreed this scenario works fine on "per node MPR selection", can someone
come up with a failing scenario?

Teco.

|Best regards,
|Philippe
|
|Charles E. Perkins a écrit :
|>
|> Hello Chris,
|>
|> Comments below...
|>
|> Dearlove, Christopher (UK) wrote:
|>>
|>>> I don't understand this. The requirement is that the set
|>>> of MPRs must provide connectivity to all 2-hop neighbors
|>>>
|>>
|>> That's not sufficient.
|>>
|>
|> I believe this is highly debatable.
|>
|>>
|>>>  o   Why MPR selection per interface?
|>>>
|>>
|>> Read the literature. And yes, that is me not putting in the effort
|>> to point out the race condition case and why per interface avoids
|>> it and per router doesn't (a subtlety in the MPR flooding proof).
|>>
|>
|> I read the proofs, albeit a couple of years ago, and I don't remember
|> anything particular about this point.  Too bad I can't go back and
|review
|> this material today.
|>
|
|_______________________________________________
|manet mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 8 Apr 2009 15:07:49 +0100

What if D uses the same interface to receive from
B and C (and E likewise) although B and C use two
interfaces to send on? (As you say, interfaces of
any type can connect. Fast and slow is a point for
an example.) The race condition stops onward
transmission in that case.

Incidentally note that there is also interface
dependence due to OLSRv2 section 7.3 point 1.

And you can't flood on router ID because a forwarded
message does not contain the router ID of a forwarding
node. Messages are not changed (hop count/limit aside)
by forwarding - this is the intended model described
in 5444 and necessary for end to end authentication
as also suggested in 5444, and in real use. All you get
from an intermediate node is source IP address of the
datagram containing the forwarded message. (This is not
the first time I've pointed that out.)

-- 
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 Teco Boot
Sent: 08 April 2009 14:35
To: 'jacquet'; 'Charles E. Perkins'; Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: [manet] OLSRv2 and "per node MPR selection"

               *** WARNING ***

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

-----Oorspronkelijk bericht-----
Van: Teco Boot [mailto:[email-masked]] 
Verzonden: woensdag 8 april 2009 15:21
Aan: 'jacquet'; 'Charles E. Perkins'; 'Dearlove, Christopher (UK)'
CC: [email-masked]'
Onderwerp: OLSRv2 and "per node MPR selection"

Hi Philippe,

[changed subject]

  B***D
 / \  /\
A   \/  F
 \  /\ /
  C***E

OK:

Not sure on this.
Scenario:

What is the problem ???

Teco.

|Best regards,
|Philippe
|

_______________________________________________
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: "Teco Boot" <[email-masked]>
Date: Wed, 8 Apr 2009 17:47:32 +0200

|What if D uses the same interface to receive from
|B and C (and E likewise) although B and C use two
|interfaces to send on? (As you say, interfaces of
|any type can connect. Fast and slow is a point for
|an example.) The race condition stops onward
|transmission in that case.

To line up on terminology:

 MANET segment

    Wireless communication facility which may interconnect
    MANET interfaces, when within radio range to each other.
    A MANET interface connects a MANET router to a single 
    MANET segment.

Some __physical__ router interfaces can connect to multiple MANET segments.
I assume the driver for such an interfaces provide __separate virtual
interfaces__. 
I can imagine that a router has multiple interfaces to the same segment. For
example for redundancy, for Rx diversity or whatever. One is used for Tx, or
even both (Tx diversity). I assume the interfaces have the same IP address
and MAC address. So for other nodes, this is transparent. All of this
doesn't cause the race condition. 

When B-D (and C-E) are on the same "fast" MANET segment, and forwarding of
relayed msg by B is delayed (jitter, queuing), msg from C would arrive
first. Or D or E is the MPR for C, in this case it is E. E forwards, D does
not.
What is the problem?

Question: what is the difference with "per interface MPR selection"? Now we
have single segment / single interface.

If you provide some more guidelines for the scenario, I'm happy to produce
another analysis document.

|Incidentally note that there is also interface
|dependence due to OLSRv2 section 7.3 point 1.

Yes, it is in my flow chart.

|And you can't flood on router ID because a forwarded
|message does not contain the router ID of a forwarding
|node. 

Yes, it is. In my proposal, all messages are sent with the RouterID as
source address, e.g. the protocol binds to the loopback interface, or the
"unnumbered interface" model is used. I moved somewhat towards the
addressing model of Thomas / Ulrich.
With the loopback interface approach, L3 to L2 address mapping must be
handled. One can think of snooping or proxy-arp/nd. There could be more
options, so this is not blocking. Snooping is a nice feature, implemented as
plug-in in olsr.org code already.

|Messages are not changed (hop count/limit aside)
|by forwarding - this is the intended model described
|in 5444 and necessary for end to end authentication
|as also suggested in 5444, and in real use. All you get
|from an intermediate node is source IP address of the
|datagram containing the forwarded message. (This is not
|the first time I've pointed that out.)

Works fine for me.

A I am more and more convinced RouterID works fine, I could write an I-D for
it. Few cycles left in coming weeks. Or maybe Henning is producing
something.

For "per node MPR selection", I'll wait on a scenario that breaks this
model. If no one can come up with it, I do not see a reason for not
accepting it by the WG.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 8 Apr 2009 17:18:03 +0100

> What is the problem?

The problem is when the ordering of different transmissions
of the same message is not well-defined. That ordering is an
assumption of the mathematical theorems that allow MPRs to
work (including such efficiency savings as that a first
reception from a non-MPR selecor blocks a later reception
from an MPR selector from being forwarded, significantly
saving on transmissions). Philippe's example (when you consider
reception by single interfaces) shows such a case, where the
conditions are violated, and the flooding fails. Per interface
selection avoids this case.

---

From: Richard Ogier <[email-masked]>
Date: Wed, 08 Apr 2009 09:53:41 -0700

Teco Boot wrote:

>I am more and more convinced RouterID works fine, I could write an I-D for

I agree with the above.  Note that in OSPFv3 (RFC 5340), each OSPF message
includes the sender's Router ID in the OSPF header.  There is no reason
why the same cannot be done here.

>model. If no one can come up with it, I do not see a reason for not

I also agree with this.  Christopher has not yet provided a clear
example that shows per node MPR selection will not work when
the first reception of a given message on *each* interface is
considered for forwarding.  As you pointed out, Philippe's
example does not show failure under this assumption.  (He assumed
that only the first reception of a given message on *any* interface
is considered for forwarding.)

Richard

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 8 Apr 2009 17:55:12 +0100

> why the same cannot be done here.

See my previous postings and RFC 5444 for why this is not done.

> considered for forwarding.

As I have mentioned, that is inefficient, it means that there are
always extra messages sent when using multiple interfaces, not
just sometimes.

---

From: Richard Ogier <[email-masked]>
Date: Wed, 08 Apr 2009 10:28:20 -0700

>always extra messages sent when using multiple interfaces, not

OK, you now agree it works.  But you are saying it is inefficient
because a given message is considered for forwarding the first
time it is received on each interface (not just the first interface).
But as Teco pointed out, and as specified in Step 2.1 of Section 7.3,
a received message is discarded only if it was already received
on the *same* interface.  Therefore, olsrv2 already considers
a message for forwarding the first time it is received on each
interface!  Therefore, the proposed modification is not less
efficient, but is more efficient because a single set of MPRs
is selected for all interfaces (not per interface).

Richard

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 8 Apr 2009 19:53:39 +0200

|> What is the problem?
|
|The problem is when the ordering of different transmissions
|of the same message is not well-defined. That ordering is an
|assumption of the mathematical theorems that allow MPRs to
|work (including such efficiency savings as that a first
|reception from a non-MPR selecor blocks a later reception
|from an MPR selector from being forwarded, significantly
|saving on transmissions). Philippe's example (when you consider
|reception by single interfaces) shows such a case, where the
|conditions are violated, and the flooding fails. Per interface
|selection avoids this case.

Again, if one comes up with more detailed description of the race condition,
I am happy to analyze this.
Philippe's example with "single interfaces" is working fine. 

For now, I assert "per node MPR selection" does not have problems.

Teco.

---

From: Philippe Jacquet <[email-masked]>
Date: Thu, 09 Apr 2009 10:49:54 +0200

Hi, Teco,

These new rules would align the performances on the worse interface and 
very likely generate more packets than with the previous rule and with 
much more delays. But maybe I understood wrongly. Are you proposing
1. per node MPR selection
2. forward if there is an interface where you receive first from one MPR 
selector?

Then the following example fails:

     B-----E
      * --/
      / **
     C*****D

I mean (B,E) and (B,D) on interface --
        (C,D) and (C,E) on interface **

MPR of B is E and MPR of C is D. B shoots first on interface ***, C 
shoots first on interface --. Then E and D receive both first from non 
MPR selector.

In conclusion the order per interfaces does not generate a founded order 
on the packets, as soon you have more than two interfaces. When the MPR 
are selected per interface makes the order founded again.

One possible alternative well founded order with per node selection is 
to use the emitter ID, but in this case you have no bound on how long 
you have to wait to determine which is the smallest ID of the emitters 
and to retransmit if the smallest ID is an MPR selector. In general it 
turns out to retransmit more packets and align again on the performance 
of the worse interface.

Best regards,
Philippe

---

From: Philippe Jacquet <[email-masked]>
Date: Thu, 09 Apr 2009 11:28:26 +0200

Hi Teco,

I change subject but I take the opportunity of your nice diagrams in
http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf

There is a recurrent proposal to use the metric MPRs as flooding MPR. 
Chris already said that this won't work because metric MPRs don't 
necessarily cover the two hop neighbor, since they may be well within 
the node neighborhood (very likely among the closest node).

If one wants a flooding via metric MPR one must change the condition "is 
srce sym neigh?" (if no, then "discard") probably by something like "is 
srce last relay in an inbound shortest path" (if no, then discard) which 
is more complicated to implement.

If one does indeed implement this, that would be more or less equivalent 
to artificially reduce the neighborhood of each nodes to its closest 
neighbor (wrt metric). And therefore have a much larger ratio #MPR over 
#neighbor. Basically this ratio determines the performance ratio between 
MPR flooding and basic flooding.

Best regards,
Philippe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 9 Apr 2009 11:23:36 +0100

> OK, you now agree it works.

I'm not sure which "it" you are referring to. I agree that
there are variations you can make that work, though some
allow the race condition and just hope it is rare enough to
ignore, and some are clearly inefficient. But (see Philippe)
there's work that indicates why the current approach (which is
- presentation aside - essentially that of OLSRv1, a tried
and tested protocol with many deployments) is that included.
I don't agree that all of the variants that have been
suggested work, and some have definitely bad requirements.

Two more points. One is that I'm shortly away for over a week,
so failure to comment is not agreement. The other is that over
three years ago now, we agreed to create OLSRv2 as the Standards
Track protocol, a key advantage being that in most regards
(flooding is one) we get to know how it behaves - it's like
OLSRv1. Even where things aren't exactly as OLSRv1, it's actually
getting the same performance (or sometimes slightly better in
handling some address change transient issues) with fewer messages.
I have no desire to see the MANET WG degenerate to the state it
was half a dozen years ago where all the time was spent arguing
over these points. What we need (have needed for two or three
years in fact) is to get this done, not reopen old discussions.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 9 Apr 2009 11:29:20 +0100

> For now, I assert "per node MPR selection" does not have problems.

Assertions aren't worth much, especially ones just "for now".
I prefer mathematical proofs. And those exist, but with ordering
requirements which multiple interfaces and simple MPR selection
don't satisfy. And a problem case has been pointed out (with the
point that the receiving nodes use a single interface in this case)
which shows that simply removing that requirement doesn't work.

---

From: Richard Ogier <[email-masked]>
Date: Thu, 09 Apr 2009 09:43:57 -0700

Philippe,

Thanks for your example.  I believe that is what Teco and I were both 
looking for.  I am now convinced that MPRs cannot be selected per node, 
without using emitter ID to establish order or selecting MPRs in a 
special way as discussed below.

Another alternative (though less efficient) is to select MPRs so that 
the neighbor with the largest RID that covers a given 2-hop neighbor is 
always selected as an MPR.  (This can also be achieved using 
self-selected MPRs.)  In your example, B and C would both select E as an 
MPR (assuming E has a larger RID than D).  I hope that olsrv2 is 
flexible enough to allow such a selection, thus essentially allowing 
per-node MPRs by making it unnecessary for the MPR set for each 
interface to cover all 2-hop neighbors. However, Section 14 of the draft 
does not currently allow this, so I hope this can modified to allow more 
flexibility.  Chris said "There's plenty of scope for intelligent 
tradeoffs of how to do things", but this appears to be a significant 
limitation.

BTW, you had a typo which is corrected as follows:

I mean (B,E) and (C,E) on interface --
       (C,D) and (B,D) on interface **

Richard

Philippe Jacquet wrote:

> Hi, Teco,
>
> These new rules would align the performances on the worse interface 
> and very likely generate more packets than with the previous rule and 
> with much more delays. But maybe I understood wrongly. Are you proposing
> 2. forward if there is an interface where you receive first from one 
> MPR selector?
>
> In conclusion the order per interfaces does not generate a founded 
> order on the packets, as soon you have more than two interfaces. When 
> the MPR are selected per interface makes the order founded again.
>
> turns out to retransmit more packets and align again on the 
> performance of the worse interface.
>
> Best regards,
> Philippe
>
> Teco Boot a écrit :
>
>> |> What is the problem?
>> |

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 9 Apr 2009 21:51:20 +0200

Hi Phillipe,

[lots of interruptions while responding...]

|Then the following example fails:
|
|     B-----E
|      * --/
|      / **
|     C*****D
|
|I mean (B,E) and (B,D) on interface --
|        (C,D) and (C,E) on interface **

Split your diagram in two:

Interface --

     B-----E
       ___/
      / 
     C     D

This is (B,E) and (C,E).

Interface **

     B     E
      **   
        *** 
     C*****D

This is (B,D) and (C,D).

[as Richard also noticed]

|MPR of B is E and MPR of C is D. B shoots first on interface ***, C
|shoots first on interface --. Then E and D receive both first from non
|MPR selector.

OK. Now E and D process the message, but they do not forward. Thinks can
happen.

But B shoots also on ---, C on ***. These will arrive on both E and D MPRs
and MUST be forwarded. This indeed need the adjusted forwarding algorithm,
updating the "received on this interface before" check, as Richard pointed
out.

Question is: update to "received before?", or just skip the check. I have to
read more on this.

Teco.

---

From: Richard Ogier <[email-masked]>
Date: Thu, 09 Apr 2009 13:33:32 -0700

I thought of a better solution that does not require the
MPR set for each interface to cover all 2-hop neighbors.

Unlike the (inefficient) solution I mentioned that gives priority to
neighbors with larger Router IDs, my proposed solution gives
priority to interfaces with larger network addresses.
(If an interface has multiple addresses, use the largest one.)
This can be achieved by modifying the following bullet
from Section 7:

o  If the selecting router sends a message on that OLSRv2 interface,
   and that message is successfully forwarded by all of the selected
   MPRs for that interface, then all symmetric strict 2-hop neighbors
   of the selecting router through that OLSRv2 interface will receive
   that message on a symmetric link.

The modified bullet is:

o  If the selecting router sends a message on that OLSRv2 interface,
   and that message is successfully forwarded by all of the selected
   MPRs for that interface, then all symmetric strict 2-hop neighbors
   of the selecting router through that OLSRv2 interface, EXCLUDING
   routers that are symmetric strict 2-hop neighbors through an
   interface with a larger address, will receive that message on a
   symmetric link.

Thus, the interface with largest address will have a "full" set
of MPRs that cover 2-hop neighbors, but a lower numbered interface
need not have a full set of MPRs if some of the 2-hop neighbors
are covered by MPRs on a higher numbered interface.

This solution works for both of Philippe's examples, assuming
that a given message is forwarded if there exists an interface
on which the message is first received from an MPR selector.
In Philippe's last example, assuming that E's interface has
a larger address than D's interface, both B and C would select
E as MPR (as in the current draft), but would not select D
as MPR (unlike the current draft).

If the above modification does indeed work while reducing the number
of MPRs, then it probably should be incorporated in the draft.

Richard

P.S.  In Philippe's last example, he is assuming that B and C
send the same message, originated by another router A that
is not shown.  This might not have been clear.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 14 Apr 2009 11:18:31 +0200

Hi Philippe,

|In conclusion the order per interfaces does not generate a founded order
|on the packets, as soon you have more than two interfaces. When the MPR
|are selected per interface makes the order founded again.

Do you mean the "per interface MPR selection" method guarantees the
requirements for circumventing the race condition?

What if the interface connects to a multi-hop sub-IP layer network, like for
example Ethernet (or sub-IP multi-hop wireless network)?

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

Network B-C-D-E id 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.

I can imagine a future generation radio system that has similar behavior.
The system would have time synchronization and multi-channel facilities
(FDMA or CDMA). B and C are allowed to send in parallel and both D and E can
receive both signals. E is close to B and D is close to C. No jitter, or
jitter is neutralized by time synchronization.

        +---+        +---+
       /| B |z------z| E |\
      / +---+|\    /|+---+ \
      |      | |   ||       | 
      |      | |   ||       | 
      |      | |   ||       | 
      |      | |   ||       | 
+---+/       | \  / |       \+---+
| A |        |  ==  |        | F |
+---+\       | /  \ |       /+---+
      |      | |   ||       | 
      |      | |   ||       | 
      |      | |   ||       | 
      |      | |   ||       | 
      \ +---+|/    \|+---+ /
       \| C |z------z| D |/
        +---+        +---+

Teco.

---

From: jacquet <[email-masked]>
Date: Wed, 15 Apr 2009 14:23:32 +0200

Hi, Teco,

The case you describe sounds to me like an interface with significant 
propagation delay jitter. While frequently ignored in simple wireless 
interface, the propagation jitter adds to contention jitter. Of course 
MANET protocol delay tolerance (and therefore flooding jitter) must be 
statistically larger than those delays.

If propagation jitters are too large then protocols must be designed as 
in DTNRG that addresses issues about traffic buffering and outdated 
topology informations. Maybe more on http://www.dtnrg.org/wiki

Best regards,
Philippe

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 15 Apr 2009 16:14:54 +0200

Hi Philippe,

|The case you describe sounds to me like an interface with significant
|propagation delay jitter.

No, the scenario is using just a couple of switches. The hop-by-hop delay is
a little longer than jitter due to processing a TC message. Assume no
RFC5148 jitter, so TC from A (at T0) is relayed by B and C immediately (at
T1). Because they can send to the switch in parallel, and the two switches
relay this broadcast in parallel, the TC is received (at T3) by D (from C
only), E (from B only) and on both switches (from opposite switch, from the
MPR selector) simultaneously. So both D and E receives at T3 the TC from the
non-MPR selector, and these are stored in the Received Sets, but not
forwarded to F. Both switches forward both the TC messages, switch above the
TC relayed by C and the switch below the TC relayed by B. Finally, the TC is
received at both D and E (at T4). But these TC messages are also not
forwarded to F, because the "seen before on this_interface" check. So F will
not receive the TC messages send (or relayed) by A.

It doesn't matter how large intervals between T0 to T4 are, less than a
millisecond would be enough.

The scenario on a hulti-hop wireless sub-IP network is very similar. I would
depict a (few) node(s) between (B,E) and (C,D). Assume no hidden terminal
problem (e.g. PGM or NORM, but also at sub-IP layer, or TDMA or whatever).

Mix of both Ethernet and wireless multi-hop will do also, e.g. the two
switches interconnected with a wireless point-to-point bridge.

| While frequently ignored in simple wireless
|interface, the propagation jitter adds to contention jitter.

Yes. But this doesn't matter. The problem occurs because the TC flooding
starts in parallel and delivery to the non-MPR selector first is caused by
multi-hop. I assume jitter caused by frequency or contention is less than
multi-hop forwarding

| Of course
|MANET protocol delay tolerance (and therefore flooding jitter) must be
|statistically larger than those delays.

I am not sure if you meant RFC5148 jitter. This is a MAY. I would not use it
on Ethernet segments. For the failing scenario, it is disabled.

Yes, routing protocols shall tolerate delay / jitter in packet delivery.
Unfortunately, this could be a reason for routing loops. A bit out of topic
here.

|If propagation jitters are too large then protocols must be designed as
|in DTNRG that addresses issues about traffic buffering and outdated
|topology informations. Maybe more on http://www.dtnrg.org/wiki

I would not say a network with a couple of Ethernet switches is a scenario
for DTN.

Regards, Teco

|> What if the interface connects to a multi-hop
|> sub-IP layer network, like for example
|> Ethernet (or sub-IP multi-hop wireless network)?
|>
|>         +---+   +--------+   +---+
|>        /| 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.