Subject: [manet] How is DLEP Timings and Radio Detections?

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 6 Jul 2012 14:05:40 +0200

=================    Possible Duplication   ==================

+1 with Teco,

It is understood from discussion that DLEP is popular and needed by
many, I hope this [draft-dlep-02] future will consider dlep technical
requirements first and consider the community interests directions. In
its abstract; *DLEP* is about : serving the needs of router [MANET] of
a *timely* and *accurate* knowledge of the
characteristics of the link (speed, state, etc.) in order for the
routers [MANET] to make forwarding decisions.

IMHO, timer at L2 within abstract of [draft-dlep-02] is a MUST. As
mentioned before in discussions DLEP server and client have timer
because they time the metric [MAN] in there messaging using RFC5497
(as suggested by one of its authors, and I not sure why not referenced
way of timing in
[draft-dlep-02]?) .

Questions to [draft-dlep-02] Authors:
Does DLEP depend on L2 technology[MAN] (e.g. IEEE802.11) to
radio-detect for any link-metric or DLEP is doing radio-detection? if
depends, how is there detection exchange between dlep-L2 peers with
timings. (I don't want to repeat inputs requests below messages
pointed, so please consider them as well).

I decided to postpone my submission of full review on the
[draft-dlep-02] (I already gave many comments on DLEP, and was about
to submit my full before 84 meeting), because authors may not use
RFC5444 (still not understand their position), but I will try after
the new draft-dlep-03, to summary all list comments and review the
future draft again after, so we can progress.

Previous Timer Discussion Input Messages:
++++++++++++++++++++++++++++++++
http://www.ietf.org/mail-archive/web/manet/current/msg12828.html
http://www.ietf.org/mail-archive/web/manet/current/msg12776.html
http://www.ietf.org/mail-archive/web/manet/current/msg12408.html

References:
=========
[draft-dlep-02] http://tools.ietf.org/html/draft-ietf-manet-dlep-02
[MANET] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

Best Regards
Abdussalam Baryun
University of Glamorgan, UK

=====================================================

To: Stan Ratliff (sratliff) <sratliff at cisco.com>
Subject: Re: [manet] Status of DLEP-draft at Cisco?
From: Teco Boot <teco at inf-net.nl>
Date: Thu, 5 Jul 2012 21:41:59 +0200

> [snip]
>>
>> Could you take a look at olsrv2? It provides a good example. TC generation is "scheduled or triggered by a  change of contents". When congestion may occur, having a shaper is a good thing.
>>
>
> OK, that is a model…. but from a router's perspective, how do you tell the difference between a radio that just hasn't hit any triggers (so it doesn't need to tell you anything), and one that's failed? I guess the answer would be that Layer 3 timers
Just timers, not _layer 3_ timers.

> would eventually clear that up…. but wait - that's what we were trying to avoid in the first place.
I wonder how lost packets (no acks) are retransmitted, without timers.

A simple implementation just has fixed timers. A more advanced mode is
sending updates more often when there is something to tell. In ROLL,
they have such a mechanism standardized.

> The same question applies to a radio - how does it tell the difference between a router that just doesn't have anything to say, and one that's crashed?
I am not a fan of state in the radio.

> We've gone around and around on this issue, and at this point, I don't see either of us changing the other's mind...
We agree on that :-)
But IMHO it is important we know how our protocols actually work.

Thanks, Teco