Subject: Re: [manet] DLEP thoughts/questions/comments

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 21 Aug 2012 17:42:34 +0100

Hi Bow-Nan and wg-participants,

I thank you for your message and input, and I share with you some thoughts,
and add some comments.

comments in line:

>
> 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.
>
>

IMO, the DLEP is connection based between the server and client but
connectionless between neighbor peers.

>
>  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.
>
>
Yes DLEP is flexible to do both depending on the use case.

>
>  * 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.
>
>
This will depend on the MANET subnet technology (Layer 2) used for
communication, I don't think DLEP is for data-communicating, but it is for
discovery. This idea you refer to is similar what I was thinking so I am
trying to include in draft of manet-technologies [**].

>
> 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).
>
>
IMO, it was mentioning multicast address for discovery not for
communication, but MANET layer 2 is responsible for that.

> * 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.
>
>

This was advised, presented, and discussed in the 82 WG (2011) meeting and
I think the authors are invcestigating it (including other issues). This
was the reason I am writing an I-D [**] related to it.

>
>  * 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.
>
>

I support this idea totally which I think node's radio ability is important
that can benefit the routing. I call that Node Ability of Participation
(NAP), which I believe it will help in DSRv2+DLEP (both are in my
work-in-progress).

> 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.
>
>

I support that ETX is important for DLEP, and to add others depending on
use case.

> * 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.
>
>
IMO, DLEP is not in the data plane, but control plane for neighbor
discovery,

[**] http://tools.ietf.org/id/draft-baryun-manet-technology-00.txt

Best Regards
Abdussalam Baryun
University of Glamorgan, UK

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I maybe wrong or maybe right but it does not matter if we work as a group.
IETF WGs are always right.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---------------------------------------------------------------------------------------
This message 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.
This message is in compliance with the IETF regulations.
---------------------------------------------------------------------------------------