Subject: [manet] DLEP thoughts/questions

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 20 Aug 2012 15:57:19 -0400

Hi all,

I tried to filter through all the MANET list the past few months and apologize if a few of these have been asked and resolved already..  We've been working with DLEP and had a few thoughts/questions:

* Connectionless radios (e.g. CSMA) - Currently DLEP is connection based and expects the radio to detect link state changes and link characteristic changes. If the radio does it detect these changes, there is no session setup and no metrics exchanged. The issue arises with radios that do not maintain a concept of a "link". For example, 802.11 only exchanges link information when there's data to be sent. Is there some thoughts on how to make DLEP more flexible to handle radios that do not maintain this state, for example 802.11 based radios. Perhaps, DLEP should be allow the server end to start neighbor sessions instead of just the radio end.

Also, it might be good to revisit the whole necessity of setting up per neighbor sessions. This is particularly relevant for the radios that don't really know link status or can't do a good job of predicting it with RSSI. Maybe just signaling would suffice. This way the radio still sends metric information to the radio without the need of knowing the link availability.

* Multicast – Currently there is no way to handle radios that operate at different power/modulation rates for different types of multicast traffic. At different power rates different multicast packets may be able to reach different amounts of neighbors.

In Draft 02, they say that you can use a multicast address to define a neighbor. The question is do they expect that for every multicast group in the network, a "neighbor session" will be established?  This can blow up quickly, but it does provide the possibility of doing radios with multiple power modulation (I.e. Map a mcast group to a certain power level).

* Flow Control – Up until Draft 02 there has been no flow control and rate based control was assumed, which does not work well in shared medium. Draft 02 added a paragraph about an optional credit based flow control, similar to RFC4978. It is unclear how credit based flow control will perform for a broadcast medium and some work is needed to investigate a right approach. Maybe a pause frame flow control or some sort of a hybrid approach is better suited.

* Link Metrics - More work is needed on proper link metrics. Maybe DLEP should be able to provide a core set of link metrics like it does now but also allow for each radio to provide radio specific metrics that a routing protocol may chose to take advantage of.

In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which is a combo of a bunch of different latencies. Maybe it just makes sense to report that in the latency field instead. Then they list for EFT, the metric ETX in parenthesis which is something else. ETX (expected transmission count) as can be seen in the following paper: pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf is widely used in MANET for the metric instead of hop count because it estimates loss. We agree on using the ETX, but not sold on EFT.

* Data and Control Paths – Currently DLEP only allows both data and DLEP control plane packets to travel over the same interface. DLEP needs to be more flexible to allow for the cases where data and control plane need to be separated over different interfaces.

-Bow-Nan

---

From: Joseph Macker <[email-masked]>
Date: Mon, 20 Aug 2012 17:11:51 -0400

Bow-nan:

Thanks for posting its a good time to post WG comments/question on DLEP
futures since authors are likely in the revision process.

Thanks,
Joe

On Mon, Aug 20, 2012 at 3:57 PM, Cheng, Bow-Nan - 0665 - MITLL <
[email-masked]> wrote:

> Hi all,
>
> I tried to filter through all the MANET list the past few months and
> apologize if a few of these have been asked and resolved already..  We've
> been working with DLEP and had a few thoughts/questions:
>
> * Connectionless radios (e.g. CSMA) - Currently DLEP is connection based
> and expects the radio to detect link state changes and link characteristic
> changes. If the radio does it detect these changes, there is no session
> setup and no metrics exchanged. The issue arises with radios that do not
> maintain a concept of a "link". For example, 802.11 only exchanges link
> information when there's data to be sent. Is there some thoughts on how to
> make DLEP more flexible to handle radios that do not maintain this state,
> for example 802.11 based radios. Perhaps, DLEP should be allow the server
> end to start neighbor sessions instead of just the radio end.
>
> Also, it might be good to revisit the whole necessity of setting up per
> neighbor sessions. This is particularly relevant for the radios that don't
> really know link status or can't do a good job of predicting it with RSSI.
> Maybe just signaling would suffice. This way the radio still sends metric
> information to the radio without the need of knowing the link availability.
>
> * Multicast – Currently there is no way to handle radios that operate at
> different power/modulation rates for different types of multicast traffic.
> At different power rates different multicast packets may be able to reach
> different amounts of neighbors.
>
> In Draft 02, they say that you can use a multicast address to define a
> neighbor. The question is do they expect that for every multicast group in
> the network, a "neighbor session" will be established?  This can blow up
> quickly, but it does provide the possibility of doing radios with multiple
> power modulation (I.e. Map a mcast group to a certain power level).
>
> * Flow Control – Up until Draft 02 there has been no flow control and rate
> based control was assumed, which does not work well in shared medium. Draft
> 02 added a paragraph about an optional credit based flow control, similar
> to RFC4978. It is unclear how credit based flow control will perform for a
> broadcast medium and some work is needed to investigate a right approach.
> Maybe a pause frame flow control or some sort of a hybrid approach is
> better suited.
>
> * Link Metrics - More work is needed on proper link metrics. Maybe DLEP
> should be able to provide a core set of link metrics like it does now but
> also allow for each radio to provide radio specific metrics that a routing
> protocol may chose to take advantage of.
>
> In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which
> is a combo of a bunch of different latencies. Maybe it just makes sense
> to report that in the latency field instead. Then they list for EFT, the
> metric ETX in parenthesis which is something else. ETX (expected
> transmission count) as can be seen in the following paper: pdos.csail.*mit
> *.edu/papers/grid:mobicom03/paper.pdf is widely used in MANET for the
> metric instead of hop count because it estimates loss. We agree on using
> the ETX, but not sold on EFT.
>
> * Data and Control Paths – Currently DLEP only allows both data and DLEP
> control plane packets to travel over the same interface. DLEP needs to be
> more flexible to allow for the cases where data and control plane need to
> be separated over different interfaces.
>
> -Bow-Nan
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 21 Aug 2012 16:53:07 +0000

Bow-Nan,

+1 on the "Thanks for posting".

Yes, the authors are in the middle of producing an 03 version of the draft. Will post as soon as we reach consensus on the set of edits.

Regards,
Stan

On Aug 20, 2012, at 5:11 PM, Joseph Macker wrote:

Bow-nan:

Thanks for posting its a good time to post WG comments/question on DLEP futures since authors are likely in the revision process.

Thanks,
Joe

On Mon, Aug 20, 2012 at 3:57 PM, Cheng, Bow-Nan - 0665 - MITLL <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

-Bow-Nan

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

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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 29 Aug 2012 11:02:13 +0200

> Hi all,

Hi.

There has been quite a lot of discussion about DLEP at Vancouver, Joe 
Macker is right thats its a good time to get the discussion running on 
this mailing list again.

> apologize if a few of these have been asked and resolved already..
> We've been working with DLEP and had a few thoughts/questions:
>
> * Connectionless radios (e.g. CSMA) - Currently DLEP is connection
> based and expects the radio to detect link state changes and link
> characteristic changes. If the radio does it detect these changes,
> there is no session setup and no metrics exchanged. The issue arises
> with radios that do not maintain a concept of a "link". For example,
> 802.11 only exchanges link information when there's data to be sent.
> Is there some thoughts on how to make DLEP more flexible to handle
> radios that do not maintain this state, for example 802.11 based
> radios. Perhaps, DLEP should be allow the server end to start
> neighbor sessions instead of just the radio end.

Like we discussed on this list, I think we could simplify DLEP to get 
rid of the necessary sessions between the radio and the router. In the 
simplest use-case this might lead to a radio just multicasting its known 
data about interfaces and neighbors to the control-plane without even 
knowing if a router is present.

> * Multicast – Currently there is no way to handle radios that operate
> at different power/modulation rates for different types of multicast
> traffic. At different power rates different multicast packets may be
> able to reach different amounts of neighbors.
>
> In Draft 02, they say that you can use a multicast address to define
> a neighbor. The question is do they expect that for every multicast
> group in the network, a "neighbor session" will be established?  This
> can blow up quickly, but it does provide the possibility of doing
> radios with multiple power modulation (I.e. Map a mcast group to a
> certain power level).

I think it might be necessary for DLEP to send a set of data for each 
MAC address a local router can communicate with, including the default 
broadcast MAC and optional multicast MAC addresses. This would allow a 
transparent way to deliver data about multicast rates.

> * Flow Control – Up until Draft 02 there has been no flow control and
> rate based control was assumed, which does not work well in shared
> medium. Draft 02 added a paragraph about an optional credit based
> flow control, similar to RFC4978. It is unclear how credit based flow
> control will perform for a broadcast medium and some work is needed
> to investigate a right approach. Maybe a pause frame flow control or
> some sort of a hybrid approach is better suited.

It might be a good idea to split the DLEP draft into multiple parts, so 
we have a core document about "radio discovery and metric 
transportation" and one about "set neighbor link characteristics and 
flow control."

I think flow control is really useful for DLEP capable radios, because 
the router will have no information about the outgoing queue on the 
radio (all data of the router will leave its outgoing queue through the 
fast/gigabit ethernet interface!). I do not know if RFC 4978 is the 
right way to do this on shared medium radio.

> * Link Metrics - More work is needed on proper link metrics. Maybe
> DLEP should be able to provide a core set of link metrics like it
> does now but also allow for each radio to provide radio specific
> metrics that a routing protocol may chose to take advantage of.
Yes, we need a larger set of pre-defined metrics, some of them 
mandatory, some of them optional. If every radio needs to create lots of 
radio specific metrics, the usefulness of DLEP will be much less.

> * Data and Control Paths – Currently DLEP only allows both data and
> DLEP control plane packets to travel over the same interface. DLEP
> needs to be more flexible to allow for the cases where data and
> control plane need to be separated over different interfaces.

I am not sure the current draft-02 talks about how the control path is 
implemented. One option I had in mind for it was to use a VLAN-tag to 
separate it from the bridged data path.

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-961,   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: Abdussalam Baryun <[email-masked]>
Date: Wed, 29 Aug 2012 14:31:48 +0200

Mostly agree with Henning, but not sure when the new draft will be
published. I don't think I can discuss further until read new I-D or
the authors decide on the WG concerns and many discussions/ideas
related on the list.

AB