Subject: [manet] DLEP link metric discussion

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Apr 2013 11:12:39 +0200

Hi,

as promised in the earlier review of DLEP-04, here are some more points 
to discuss for DLEP link metrics.

Layer-2 traffic data
--------------------

Many IP radios can easily keep track of the incoming and outgoing data 
to its neighbors, both in terms of bytes and frames. This data is useful 
for calculating routing metrics, so I would like to see statistic 
metrics (as described in my private draft) as optional metrics for DLEP.

This way manufacturers do not need to invent proprietary metric TLVs for 
this data.

Layer-2 mesh
------------

It seems that many IP radios try to establish a transparent layer-2 mesh 
between the radios on the same channel. The fact that the linklayer 
forms a mesh is useful knowledge for a layer-3 MANET routing protocol, 
it allows an implementation to optimize its flooding and forwarding 
routings (by not using two-hop routes within the layer-2 mesh domain).

I would suggest adding a new TLV to DLEP with a single byte value to 
signal this feature to the router. Establishing a codepoint for "no 
mesh" and one for "mesh" should be enough for the basic DLEP draft, 
other optional codepoints that signal more features of the radio 
available to the router could be defined in later RFCs.

9.X Mesh

The Mesh TLV is used in Peer Discovery and Peer Update messages to 
indicate if the radio use a transparent layer-2 mesh to forward the traffic.

The Mesh TLV contains the following fields:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |TLV Type =TBD  |Length = 1     |Mesh Capability|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    TLV Type    -  TBD

    Length      -  1

    Mesh Capability -  Value 0 means the radio does not use mesh 
forwarding on this DLEP interface. Value 1 means the radio does use mesh 
forwarding, but do not provide further data about the feature.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 23 Apr 2013 13:25:13 +0000

I support the addition of this metric, as we're dealing with radios that have this capability. But while we're spending a byte anyway, why not simply report the layer-2 hop count to the neighbor?

Martin Duke
Boeing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Tuesday, April 23, 2013 2:13 AM
To: [email-masked]
Subject: [manet] DLEP link metric discussion

Hi,

as promised in the earlier review of DLEP-04, here are some more points to discuss for DLEP link metrics.

Layer-2 traffic data
--------------------

Layer-2 mesh
------------

9.X Mesh

     0                   1                   2

    TLV Type    -  TBD

    Length      -  1

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 23 Apr 2013 14:08:10 +0000

The difference between a 1 byte Boolean value and a layer2-hopcount is how big should the TLV data packet be... 8-bits?  16-bits?  etc.

I vote for 1 byte Boolean.

Also, exposing layer-2 topology information could lead to people requesting a TLV to notify a change of layer-2 hopcount.  I would keep the lid on the can of worms.

Rick Taylor

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Duke, Martin
> Sent: 23 April 2013 14:25
> To: [email-masked]; [email-masked]
> Subject: Re: [manet] DLEP link metric discussion
>
> I support the addition of this metric, as we're dealing with radios that
> have this capability. But while we're spending a byte anyway, why not
> simply report the layer-2 hop count to the neighbor?
>
> Martin Duke
> Boeing
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Apr 2013 16:30:56 +0200

The current solution is just a single "boolean" (with later chances of
expansion) value per Radio. Thats easy to implement and doesn't
produce lots of overhead.

Adding data that changes dynamically to each neighbor is a lot more of both.

I think we can work on this (feature to export layer-2 topology
through DLEP), but this should become an Extension-RFC. Lets keep it
out of the core specification.

Henning Rogge

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

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 23 Apr 2013 08:57:13 -0700

> to discuss for DLEP link metrics.

At layer 3, routers are peer-peer.  But most radio networks at layer 2
are not: a radio network segment (such as an LTE or 802.16 one) has a
base station (BS) and several subscriber stations (SS).  BS has all
kinds of this data readily at hand; a SS will only have metrics
pertinent to that particular SS.  In these kinds of network segments,
mining the SS that a router is attached to may not tell you important
data -- rather, you want to mine the BS which may be attached to a
different router.

> This way manufacturers do not need to invent proprietary metric TLVs for 

While the data in the BS is not itself described in the standards (e.g.
IEEE 802.16); the gozintas and gozoutas are very carefully described.
There are about four dozen -- the upload map (UL-MAP) is the single most
important one, but ranging messages will tell you a lot about link
quality if you wiretap them ... or the database they go into.  We need
not reinvent all these data notions.

> Layer-2 mesh
Henning, we need to be careful about the term 'mesh'.  It's been badly
abused and poorly defined ... and if you've been raised with
fiber/copper underlying connectivity, the set of assumptions changes
(you got that part), but it changes in some ways that you didn't get.

> routings (by not using two-hop routes within the layer-2 mesh domain).

There are two issues here that need to be disentangled.

The first is knowledge of connectivity at layer 2, and feeding it upward
to the routing table.  OK, I'll live with that.

But the second is the MAC.  With a shared media, you need one
(conversely, with point-point media you don't).  So capacity of the
layer 2 radio network is baseband capacity prorated across all the SS in
the segment .... minus the overhead used by the MAC.  In the case of
ethernet derivatives (like WiFi), that overhead may reach 80%!  And it
gets worse as the segment gets more congested ... so one of the metrics
you would need to get hold of is how congested the network segment
is ... so you don't overload and stall it.

> available to the router could be defined in later RFCs.

All the conventional radio networks commonly used in the internet
(802.11, 802.16, LTE) have the BS/SS asymmetry.  The one place I know
where this is not the case is in AIS, the distributed system whereby
ships report their lat/long positions.  I've not analyzed that MAC in
detail though.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Apr 2013 18:35:22 +0200

> data -- rather, you want to mine the BS which may be attached to a

Most MANET do not run on this "master/slave" style of networks, but we
should keep in mind that DLEP should also work for them.

> not reinvent all these data notions.

Do you have a suggestion what are the most common/useful values
available in this kinds of networks?

> (you got that part), but it changes in some ways that you didn't get.

I used "mesh" as a layer-2 MANET technology... 802.11s for example, or
BATMAN Advanced as it is included in the Linux Kernel.

> is ... so you don't overload and stall it.

I am not sure how this is connected to a "does/does-not layer-2 mesh"
TLV for DLEP.

> ships report their lat/long positions.  I've not analyzed that MAC in

Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does not
include this asymmetry.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 23 Apr 2013 16:52:48 +0000

> should keep in mind that DLEP should also work for them.

Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.

> available in this kinds of networks?

This is (to some extent) what I was afraid of - the notion of adding 4 dozen TLV's to DLEP is a bit daunting. ;-) Hopefully, we can reach consensus on this issue before too much time expires. 

> I am not sure how this is connected to a "does/does-not layer-2 mesh"

In the case described above, I could see SS-to-SS connectivity (via the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the statement that "mesh" is poorly defined. 

> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does not

That reminds me of a statement a college professor made. Something along the lines of "No one in their right mind will ever use 802.11 adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc example irrelevant.

Regards,
Stan

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Apr 2013 12:56:36 -0400

I like the concept of having some sort of "hop-count" metric to support
the layer 2 "mesh routing". The reason for this instead of a boolean
yes/no is that the layer 3 routing protocol can filter on 1-hop routes to
prevent double-routing.

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 23 Apr 2013 10:43:59 -0700

On Tue, 2013-04-23 at 16:52 +0000, Stan Ratliff (sratliff) wrote:
> This is (to some extent) what I was afraid of - the notion of adding 4
> dozen TLV's to DLEP is a bit daunting. ;-) Hopefully, we can reach
> consensus on this issue before too much time expires. 

Agree that 4 dozen is daunting; and some of these messages are necessary
to the internal workings of the network segment and need not be visible
outside.  I'd suggest that the place to look is in the MIB which is
where the values represented in these messages would roost.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 24 Apr 2013 11:14:25 +0200

On 04/23/2013 04:08 PM, Taylor, Rick wrote:
> The difference between a 1 byte Boolean value and a layer2-hopcount
> is how big should the TLV data packet be... 8-bits?  16-bits?  etc.

In addition to this, the layer-2 hopcount would be "per neighbor" while 
the boolean flag is "once per DLEP session".

> Also, exposing layer-2 topology information could lead to people
> requesting a TLV to notify a change of layer-2 hopcount.  I would
> keep the lid on the can of worms.

Exposing a complete layer-2 topology including metrics can be useful in 
special cases, but not for the common router.

I would like to include the two basic values "0 - no mesh" and "1 - 
transparent layer-2 mesh" into the core RFC.

(maybe we have to work on the name of the TLV and the description of the 
values to make it more clear what we are talking about)

After we finished the core RFC for DLEP, we can talk about adding things 
like "2 - layer-2 mesh reporting hopcount" and "3 - layer-2 mesh 
exporting topology" in an extension draft. The DLEP message format is 
flexible enough to handle this.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 24 Apr 2013 11:26:12 +0200

> Agreed. I'd hate to see a DLEP spec that wouldn't work on 802.16.

Yes, that would be bad.

>>>> Layer-2 mesh ------------
>>>>
>>> Henning, we need to be careful about the term 'mesh'.  It's been
>>> badly abused and poorly defined ... and if you've been raised
>>> with fiber/copper underlying connectivity, the set of assumptions
>>> changes (you got that part), but it changes in some ways that you
>>> didn't get.
>>
>> I used "mesh" as a layer-2 MANET technology... 802.11s for example,
>> or BATMAN Advanced as it is included in the Linux Kernel.
>>
>>>> It seems that many IP radios try to establish a transparent
>>>> layer-2 mesh between the radios on the same channel. The fact
>>>> that the linklayer forms a mesh is useful knowledge for a
>>>> layer-3 MANET routing protocol, it allows an implementation to
>>>> optimize its flooding and forwarding routings (by not using
>>>> two-hop routes within the layer-2 mesh domain).
>>>
>>> The first is knowledge of connectivity at layer 2, and feeding it
>>> upward to the routing table.  OK, I'll live with that.
>>>
>>> (conversely, with point-point media you don't).  So capacity of
>>> the layer 2 radio network is baseband capacity prorated across
>>> all the SS in the segment .... minus the overhead used by the
>>> MAC.  In the case of ethernet derivatives (like WiFi), that
>>> overhead may reach 80%!  And it gets worse as the segment gets
>>> more congested ... so one of the metrics you would need to get
>>> hold of is how congested the network segment is ... so you don't
>>> overload and stall it.
>>
>> I am not sure how this is connected to a "does/does-not layer-2
>> mesh" TLV for DLEP.
>
> In the case described above, I could see SS-to-SS connectivity (via
> the BS) to be a kind-of-sort-of "mesh" connection. Goes back to the
> statement that "mesh" is poorly defined.

Maybe it would make more sense to distinguish layer-2 networks where

a) Layer-3 has to look for multihop paths within the radio domain

b) layer-2 networks which either have no alternative paths to 
destinations or do multihop retransmissions themselves

in case b, a MANET protocol could simplify the flooding and routing by 
not considering multihop-forwarding on the radio interface (only to 
other destinations beyond other interfaces).

>> Wifi (802.11) is mostly used in Adhoc-Mode for MANETs, which does
>> not include this asymmetry.
>
> That reminds me of a statement a college professor made. Something
> along the lines of "No one in their right mind will ever use 802.11
> adhoc. For anything."  So please forgive me if I find the Wifi/Adhoc
> example irrelevant.

I think we can agree to disagree on this statement.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 24 Apr 2013 12:13:38 +0000

As one of the instigators of the 'Should there be a meshing flag in DLEP' questions I thought I should add a bit of history.

My team have been implementing layer-3 routing over 802.11s style 'mesh' radios which support DLEP-00.  Unfortunately, the radio implementation is primitive and based on an early DLEP draft and so has some issues, the prime example being that the neighbour metrics supplied to the router by the radios did not match the underlying topology of the layer-2 mesh.

A quick example: (The bow-tie)

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

>From the manufacturer's reading of DLEP-00, the reported CDR from A to F did not account for any loading placed on C and D from traffic travelling E to B.  Hence the layer3 routing decisions ended up flooding the intermediate nodes resulting in network collapse.

In trying to see a way forwards, we came to two proposals:

A) DLEP should allow some way for a radio to state that it is participating in a mesh that performs multi-hop layer-2 packet forwarding, and as such, the router should not attempt layer-3 multi-hop routing within the mesh.  This is the proposal picked up by Henning, the Boolean mesh TLV.

B) The DLEP specification should include explicit statements forcing manufacturers to correctly handle the 'bow-tie' example above when reporting metrics, allowing a layer-3 router to pick a multi-hop route within the mesh that matches the layer-2 packet paths.  This I believe is Stan's position.

As I see it B) is the most 'correct' solution but it relies on careful wording in the specification that is understandable not only in English, but also to non-native speakers (I know this out of scope for an IETF document, but it is a reality).  Also, incorrect implementations are fatal to routers.

Option A) is a cludge/compromise/cop-out, but it does give manufacturers a way to specify that they do something they consider clever (or too complicated to get the metrics right) at layer-2, and layer-3 routers should avoid performing multi-hop routing *within* the radio-net.

As a pragmatist, I feel that DLEP should aim for B, but allow option A.

Rick Taylor

> Sent: 24 April 2013 10:26
> To: [email-masked]

---

From: Teco Boot <[email-masked]>
Date: Wed, 24 Apr 2013 17:04:09 +0200

I'm not sure I get the problem.

DLEP provides info on L2 / sub-IP links to a connected router. In the example, radio-A provides info to connected router-A on links to a router-B, router-E and router-F (not clear in the example radio-C and radio-D have connected routers). The reported metric *should be composed from info from al links of the L2 / sub-IP path*. If the radio cannot provide such, but instead provides only info on parts of the path (such as for radio A reports only link A-C), I wonder what the router can do with such information (other than discard...).

@Henning: If NHDP tells that each neighbor has connectivity to all other neighbors on that IP link, wouldn't that be "full connected"? Are you looking for this FullConnected TLV?

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Wed, 24 Apr 2013 16:10:06 +0000

Some responses to some various points in this discussion (I was the one that originally argued to replace the 1-Byte Mesh Boolean with a 1-Byte hop count integer).

1) I concede that explicitly stating hop count will create more updates, but are we really that constrained in control plane bandwidth between radio and router? Who cares if we send a few local messages per second in this channel?

2) I'm hesitant to say that the mesh Boolean should *strictly prevent* the router from doing its own forwarding through the mesh. It's true that some routers are unsophisticated and some radios have fancy cross-layer mechanisms. It's also true that some radios aren't that sophisticated, and that routers (in principle) may be doing all kinds of innovative traffic engineering using multi-topology routing, load balancing, integrated services, or what have you. It's much better to empower the interface to communicate enough information to support any approach, and let network architects decide who's ultimately in charge depending on known capabilities of routers and radios.

3) In particular, I'm concerned (as others have stated) that link metrics like throughput and latency, when reported for multi-hop neighbors, aren't going to be very accurate. Whether or not we use explicit hop counts, I insist that the mesh Boolean be *per-neighbor*, so the router can distinguish between true single-hop neighbors (which presumably have reliable statistics) and far-flung mesh destinations.

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: Wednesday, April 24, 2013 8:04 AM
To: Rick Taylor; Henning Rogge
Cc: <[email-masked]> List
Subject: Re: [manet] DLEP link metric discussion

Teco 

Op 24 apr. 2013, om 14:13 heeft Taylor, Rick het volgende geschreven:

>>>>> badly abused and poorly defined ... and if you've been raised with 
>>>>> fiber/copper underlying connectivity, the set of assumptions 
>>>>> the layer 2 radio network is baseband capacity prorated across all 
>>>>> the SS in the segment .... minus the overhead used by the MAC.  In 
>>>>> the case of ethernet derivatives (like WiFi), that overhead may 
>>>>> reach 80%!  And it gets worse as the segment gets more congested 
>>>>> ... so one of the metrics you would need to get hold of is how 
>>>>> congested the network segment is ... so you don't overload and 
>>>>> stall it.
>>>> 
>> in case b, a MANET protocol could simplify the flooding and routing 
>> by not considering multihop-forwarding on the radio interface (only 
>> to other destinations beyond other interfaces).
>> 
>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
>> Germany
> The information contained within this e-mail and any files attached to 
> this e-mail is private and in addition may include commercially 
> sensitive information. The contents of this e-mail are for the 
> intended recipient only and therefore if you wish to disclose the 
> information contained within this e-mail or attached files, please 
> contact the sender prior to any such disclosure. If you are not the 
> intended recipient, any disclosure, copying or distribution is 
> prohibited. Please also contact the sender and inform them of the 
> error and delete the e-mail, including any attached files from your 
> system. Cassidian Limited, Registered Office : Quadrant House, Celtic 
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 
> http://www.cassidian.com

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 24 Apr 2013 17:18:14 +0000

What if we simply state that latency and bandwidth MUST reflect the full RF path? And that, where appropriate, latency MUST include delay introduced at any intermediate nodes? 

I could be wrong about this, but it seems like I'm hearing a lot of "Well, the metrics aren't ALWAYS right, so we need all of these other indicators to tell us (or at least give us a hint) whether or not they MIGHT be wrong." I'd much rather more clearly define the metrics, and let the individual radio vendors innovate in the Layer1/2 space. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 24 Apr 2013 20:51:42 +0200

> What if we simply state that latency and bandwidth MUST reflect the full RF path? And that, where appropriate, latency MUST include delay introduced at any intermediate nodes? 

Why can there be any metric on parts on what is needed?

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 25 Apr 2013 03:48:54 +0000

> Why can there be any metric on parts on what is needed?

There shouldn't be. But earlier in this thread, there was an example of a radio vendor that was apparently reporting first-hop bandwidth instead of full-path bandwidth. At least that's what I gathered from the email. I'm concerned about the notion that the router needs to (has to?) know if the physical RF is multihop - frankly, I don't think that kind of visibility should be necessary. 

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 25 Apr 2013 09:18:03 +0000

I'll reply to several points in one go... Sorry for the top post.

@Martin:
I agree that there is enough bandwidth between local radio and router to support extra messages concerning layer-2 topology.  My concern was with the amount of extra specification required in DLEP, and the extra load placed on radio manufacturer's implementations.  IMHO, a simple protocol has a much better chance of achieving widespread uptake by industry than a more complex one.

I imagined a router using the Boolean mesh flag as an indicator that something multi-hop is happening at layer-2 and that it *might* want to rethink its layer-3 strategy, rather than *strictly prevent* the router from doing what it wants.

I can't think of an example of a meshed radio system where some neighbours are 'meshed' and some are not.  If one alters the meaning of the Boolean flag from 'Radio net is meshed' to 'Neighbour is one-hop away' then, yes, it must be per-neighbour, but I believe this is a different approach to the problem.

@Stan:
I completely agree in principle.  If modems report all link metrics correctly (i.e. taking account of layer-2 topology) then there isn't a problem.  But there are already radios in the wild that get it wrong, and the responses to my requests to correct the issue have been 'That's really hard to do with the limited resources on our devices'.

@All:
I'm just trying to discover the consensus of the group on whether a pragmatic compromise/work-around is acceptable, or if people feel the protocol should insist on 'correct' behaviour from radios.

Perhaps a third way might be changing the semantics of the Boolean 'mesh' flag to mean 'The multi-hop metrics are estimates' and include Martin's hop-count TLV so a router can determine if specific link metrics are accurate or estimated.

Rick Taylor

> From: Stan Ratliff (sratliff) [mailto:[email-masked]]
> Sent: 25 April 2013 04:49
> To: Teco Boot
> Cc: Duke, Martin; Taylor, Rick; [email-masked];
> [email-masked]
> >> What if we simply state that latency and bandwidth MUST reflect the
> full RF path? And that, where appropriate, latency MUST include delay
> introduced at any intermediate nodes?
> >
> There shouldn't be. But earlier in this thread, there was an example of a
> radio vendor that was apparently reporting first-hop bandwidth instead of
> full-path bandwidth. At least that's what I gathered from the email. I'm
> concerned about the notion that the router needs to (has to?) know if the
> physical RF is multihop - frankly, I don't think that kind of visibility
> should be necessary.
>
> Regards,
> Stan
>
>
> >
> > Teco
> >
> >

---

From: "Dowdell, John" <[email-masked]>
Date: Thu, 25 Apr 2013 12:29:06 +0000

Stan, Teco

The multihop/mesh problem has a few facets, if for the purposes of this discussion we define a mesh radio being one that is capable of doing its own layer 2 forwarding. Yes I know there is more to it than that, but I think this is what is important here.

Consider that you wish to take a journey across town on the bus. Two busses are available for you to use to your destination, Bus A and Bus B. Bus A is the express bus, and stops at a small number of points along the way. Bus B is the slow bus and stops at many points along the way. Unusually, this bus company is allowed to throw you off the bus before your destination if VIPs want to get on at some intermediate stop and there are not enough seats, and standing is not allowed.

In making your choice of which bus to catch, you are not interested that either bus stops at any place before your destination. You are however interested in how long each bus takes to get to your destination (latency), and you are also interested in whether you will be able to get a seat on the bus for the whole of the journey (congestion).

I would suggest therefore that a router would be interested to learn that a path to a destination is via a mesh radio, if only because it then knows that it will face competition for the bandwidth that the modem reports is available. How the congestion is managed is not DLEP's job.

BUT to re-iterate a point that Rick made earlier, the bus company needs to truthfully report the number of seats available on each bus for you to make able to make an informed decision. Knowing that VIPs are likely to get on is an advantage, but I'm not sure that it is strictly necessary.

Bon Voyage

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: 25 April 2013 04:49
To: Teco Boot
Cc: [email-masked]
Subject: Re: [manet] DLEP link metric discussion

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 25 Apr 2013 17:11:41 +0200

Hi John,

Your example brings up some new elements: need for a congestion TLV (in scope for DLEP?) and multi topology / traffic engineering (not in scope for DLEP, this is handled at IP routing). On congestion: would this be a per DSCP metric?

On your definition for the mesh radio: can I assume the provided IP link is full connected and IP broadcast/multicast capable? If so, we don't need to rebroadcast for flooding or forward over same interface. This is important information for the routers and I support the request for a TLV for it. Doesn't need to be in the core spec, routers can use such links to run their MANET protocol, although it is not that efficient as it could be.

The discussion on "is provided metric for first L2 hop of a multi-hop L2 path" is a different subject. I think this is a real world problem, as hub&spoke type of L2 topologies are widely used and spokes are typically unaware of far end RF links. Multi-hop L2 mesh topologies are also in place. I think DLEP should be capable to transfer any info for the L2 path to the locally connected router. Could be hopcount, total airtime, 1st L2 hop link metrics, to name a few I am aware of.

Teco

---

From: "Dowdell, John" <[email-masked]>
Date: Thu, 25 Apr 2013 15:36:42 +0000

Hi Teco

I believe the mesh radios would directly connect to all similar radios within range, and will mesh to other radios through ones that are in range. The meshing protocol is likely to take care of all forwarding, rebroadcast and multicast forwarding actions (though I'm not completely sure about multicast forwarding). I believe (though not completely sure)some mesh radios we are testing with work out the bandwidth to a destination by looking at each hop in turn and presenting the aggregate result to the source router.

I would agree that point to point or hub and spoke radio system would not care about bandwidth on other links, though the management system might collect this information.

Regards

John

-----Original Message-----
From: Teco Boot [mailto:[email-masked]]
Sent: 25 April 2013 16:12
To: Dowdell, John
Cc: Stan Ratliff (sratliff); [email-masked]
Subject: Re: [manet] DLEP link metric discussion

Hi John,

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 25 Apr 2013 15:59:51 +0000

Guys, 

This is just my opinion, but this is a *classic* case of the tail wagging the dog. The whole discussion is predicated around a radio implementation that is giving incorrect metrics to a router. IIRC, one of the quotes from the radio vendor (I might be paraphrasing here) was "Yeah, but this is hard"…. Really? And we're going to put a bunch of extra stuff into DLEP because of that? Here's the right answer - fix the radio. If the radio reports "appropriate" metrics (predicated on its inherent understanding of the physical topology), then the whole mess just goes away. The existing implementation works. 

Regards,
Stan

---

From: Justin Dean <[email-masked]>
Date: Thu, 25 Apr 2013 16:29:24 -0400

Stan I don't think this is only about radios not being able to report
accurate information.  (Although I do think we live in the real world and
many MANY radio vendors will just report the link rate without taking
multiple hop throughput into consideration.)

With a mesh network broadcasts/multicast messages can be much more
expensive than unicast messages.  A router with multiple radio interfaces,
one of which is connected to all known destinations due to it having layer
two routing, won't know the real cost of broadcasting on that interface.
Unless we build a TLV to handle that into dlep but that seems even more
complicated than just having an interface report that it is running some
mesh at layer 2.

At the very least, having a specification in which radio vendors report
that they are running a mesh, might make them think a little bit more about
the bigger picture; Having their radios integrated into a larger
heterogeneous network.

On Thu, Apr 25, 2013 at 11:59 AM, Stan Ratliff (sratliff) <
[email-masked]> wrote:

> Guys,
>
> This is just my opinion, but this is a *classic* case of the tail wagging
> the dog. The whole discussion is predicated around a radio implementation
> that is giving incorrect metrics to a router. IIRC, one of the quotes from
> the radio vendor (I might be paraphrasing here) was "Yeah, but this is
> hard"…. Really? And we're going to put a bunch of extra stuff into DLEP
> because of that? Here's the right answer - fix the radio. If the radio
> reports "appropriate" metrics (predicated on its inherent understanding of
> the physical topology), then the whole mess just goes away. The existing
> implementation works.
>
> Regards,
> Stan
>
> > I believe the mesh radios would directly connect to all similar radios
> within range, and will mesh to other radios through ones that are in range.
> The meshing protocol is likely to take care of all forwarding, rebroadcast
> and multicast forwarding actions (though I'm not completely sure about
> multicast forwarding). I believe (though not completely sure)some mesh
> radios we are testing with work out the bandwidth to a destination by
> looking at each hop in turn and presenting the aggregate result to the
> source router.
> >
> > I would agree that point to point or hub and spoke radio system would
> not care about bandwidth on other links, though the management system might
> collect this information.
> >
> > Regards
> >
> > John
> >
> > Your example brings up some new elements: need for a congestion TLV (in
> scope for DLEP?) and multi topology / traffic engineering (not in scope for
> DLEP, this is handled at IP routing). On congestion: would this be a per
> DSCP metric?
> >
> > On your definition for the mesh radio: can I assume the provided IP link
> is full connected and IP broadcast/multicast capable? If so, we don't need
> to rebroadcast for flooding or forward over same interface. This is
> important information for the routers and I support the request for a TLV
> for it. Doesn't need to be in the core spec, routers can use such links to
> run their MANET protocol, although it is not that efficient as it could be.
> >
> > The discussion on "is provided metric for first L2 hop of a multi-hop L2
> path" is a different subject. I think this is a real world problem, as
> hub&spoke type of L2 topologies are widely used and spokes are typically
> unaware of far end RF links. Multi-hop L2 mesh topologies are also in
> place. I think DLEP should be capable to transfer any info for the L2 path
> to the locally connected router. Could be hopcount, total airtime, 1st L2
> hop link metrics, to name a few I am aware of.
> >
> > Teco
> >
> >
> > Op 25 apr. 2013, om 14:29 heeft "Dowdell, John"
> <[email-masked]> het volgende geschreven:
> >
> >> Stan, Teco
> >>
> >> The multihop/mesh problem has a few facets, if for the purposes of this
> discussion we define a mesh radio being one that is capable of doing its
> own layer 2 forwarding. Yes I know there is more to it than that, but I
> think this is what is important here.
> >>
> >> Consider that you wish to take a journey across town on the bus. Two
> busses are available for you to use to your destination, Bus A and Bus B.
> Bus A is the express bus, and stops at a small number of points along the
> way. Bus B is the slow bus and stops at many points along the way.
> Unusually, this bus company is allowed to throw you off the bus before your
> destination if VIPs want to get on at some intermediate stop and there are
> not enough seats, and standing is not allowed.
> >>
> >> In making your choice of which bus to catch, you are not interested
> that either bus stops at any place before your destination. You are however
> interested in how long each bus takes to get to your destination (latency),
> and you are also interested in whether you will be able to get a seat on
> the bus for the whole of the journey (congestion).
> >>
> >> I would suggest therefore that a router would be interested to learn
> that a path to a destination is via a mesh radio, if only because it then
> knows that it will face competition for the bandwidth that the modem
> reports is available. How the congestion is managed is not DLEP's job.
> >>
> >> BUT to re-iterate a point that Rick made earlier, the bus company needs
> to truthfully report the number of seats available on each bus for you to
> make able to make an informed decision. Knowing that VIPs are likely to get
> on is an advantage, but I'm not sure that it is strictly necessary.
> >>
> >> Bon Voyage
> >>
> >> John
> >>
> >> There shouldn't be. But earlier in this thread, there was an example of
> a radio vendor that was apparently reporting first-hop bandwidth instead of
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained within
> this e-mail or attached files, please contact the sender prior to any such
> disclosure. If you are not the intended recipient, any disclosure, copying
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files from
> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained within
> this e-mail or attached files, please contact the sender prior to any such
> disclosure. If you are not the intended recipient, any disclosure, copying
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files from
> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 25 Apr 2013 23:16:06 +0200

On 4/25/13, Taylor, Rick <[email-masked]> wrote:
> @All:
> I'm just trying to discover the consensus of the group on whether a
> pragmatic compromise/work-around is acceptable, or if people feel the
> protocol should insist on 'correct' behaviour from radios.

IMHO, I don't think that hopcount is necessary, the layer-2 topology
features may be reported by another standard not DLEP. If routers were
designed not to care about layer 2 topology, then why DLEP reports. We
discussed this before and many don't want to consider layer 2 or even
definition. The DLEP serves the MANET routing protocols, so Henning's
simple proposal is enough for routing optimization.

Only routers (not current ietf manet standards, maybe changed in
future) that consider layer 2 functions should need such hopcount
info.

AB

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Apr 2013 10:28:04 +0200

On 04/24/2013 05:04 PM, Teco Boot wrote:
> DLEP provides info on L2 / sub-IP links to a connected router. In the
> example, radio-A provides info to connected router-A on links to a
> router-B, router-E and router-F (not clear in the example radio-C and
> radio-D have connected routers). The reported metric *should be
> composed from info from al links of the L2 / sub-IP path*. If the
> radio cannot provide such, but instead provides only info on parts of
> the path (such as for radio A reports only link A-C), I wonder what
> the router can do with such information (other than discard...).
>
> @Henning: If NHDP tells that each neighbor has connectivity to all
> other neighbors on that IP link, wouldn't that be "full connected"?
> Are you looking for this FullConnected TLV?

Yes, a "fully connected" might have a similar effect.

In fact, I plan to use this information to make sure the flooding 
algorithm doesn't get the idea to forward OLSRv2 TCs within the layer-2 
mesh domain, because its a huge waste of resources.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Apr 2013 10:31:11 +0200

On 04/24/2013 06:10 PM, Duke, Martin wrote:
> 2) I'm hesitant to say that the mesh Boolean should *strictly
> prevent* the router from doing its own forwarding through the mesh.
> It's true that some routers are unsophisticated and some radios have
> fancy cross-layer mechanisms. It's also true that some radios aren't
> that sophisticated, and that routers (in principle) may be doing all
> kinds of innovative traffic engineering using multi-topology routing,
> load balancing, integrated services, or what have you. It's much
> better to empower the interface to communicate enough information to
> support any approach, and let network architects decide who's
> ultimately in charge depending on known capabilities of routers and
> radios.

The Boolean flag would be a hint to the router, which can be used to 
optimize the routers protocol implementation. But its still the decision 
of the router what to do with the information (or to ignore it at all).

Henning Rogge