Subject: [manet] Some comments on manet-dlep-03

From: Teco Boot <[email-masked]>
Date: Mon, 1 Oct 2012 23:01:17 +0200

I quickly browsed thru the manet-dlep-03 draft and diff 
with the -02 version. I wonder why the draft is changed 
as it is. Does it reflect any workgroup decisions? Or is 
it a best effort undertaken by some authors? Or maybe, is 
this protocol in hands of Cisco instead of our workgroup?

I can see improvement on readability (router and modem,
not client and server). Thanks for this. I still don't 
like the "participants" term. I prefer the clear router
or modem terms, where the modem is the only participant 
that provides data.

I see a change from RFC 5444 messages to something else, 
with UDP as a suggestion. This is underspecified and does 
not lead to a standard protocol. There is a need to specify 
the basics.

The main purpose of the protocol is to get link metrics
for links between router interfaces, from modem to router. 
In general, (ethernet) interfaces have MAC addresses. I can't 
see why different IDs are needed, where the MAC addresses 
would be fine.

There are a couple of functions in DLEP that are redundant,
because other protocols or mechanisms can provide it.
Credits is one example (packet scheduling is to be performed
on bottleneck, thus the modem). MAC - IP address resolution
is another (standard ARP/ND is to be used, probably with
proxy functions to get quick resolution). And there is SNMP.

The suggested metric types looks rather useful, but some
experience showed me that it is difficult for a router to 
interpret these data. Also, with a large variety of L2
technology, it seems unwise and hard to me to support all of 
that in a general purpose router. Especially when the outcome is 
as simple as a dimensionless additive metric, such as in OLSR. I 
would specify only one mandatory metric type and all the rest 
as optional. This mandatory would be the link metric as we have 
defined in OLSRv2.

I don't get why the Heartbeat Interval/Threshold is optional. It
looks essential to me. And interval could be fractions of a second.

The protocol needs synchronized state machines, maybe with an 
n to m relation between routers and modems. Getting this right 
is not that simple. I would use TCP for unicast connections, or 
use a simple timer-based database update exchange, just like OLSR.
Section 7 misses some ACK signal TLVs. The Neighbor Update ACK is
only mentioned in 9.18 credit request. I can't find details on the 
Ack mechanism, e.g. message sequence numbers.

On Link Characteristics Request, fulfilling the request could take
some time. How the modem should provide feedback on such is unclear.

I'm looking forward to a fruitful discussions how we can work this 
out.

Teco

---

From: "Powell lll, Nelson" <[email-masked]>
Date: Wed, 3 Oct 2012 12:33:37 +0000

Teco,
   From the way I read the changes in the draft 3, DLEP has been modified to support a broader set of L2 devices and not Cisco specific.  If it was Cisco centric, we may still be working with draft 01.  I think Stan and company have done due diligence to reach out to vendors of all varieties and academia to get opinions and requirements in an effort to satisfy a multitude of use cases.  
   That being said, I must disagree with the Modem being the only device providing information.  There are a number of scenarios in which an exchange between the router and modem are beneficial if not crucial to optimized performance.  If you are experimenting with WiFi or WiMAX, you may not see a benefit; therefore, I would concede to the addition of a configuration message or TLV in the discovery process that the modem would send to the router informing the router of the ability to perform bi-directional information exchange.  But we cannot have the information exchange removed all together.
   I agree with the need for a defined protocol (UDP vs. TCP) as well as a need to define a separate FSM for both the Router and the Modem. That will ease integration issues for everyone.  Keep in mind, the specification of UDP or TCP should remain a "suggestion" for IP based connections, as modems may be connected to routers using non-IP based interfaces.
   Regarding the Ethernet MAC address comment, there are many L2 devices on the market that do not utilize the IEEE waveforms or phy, and cannot provide IEEE MAC addresses, nor do the developers wish to push ARP/ND or SNMP over the wireless interface due to bandwidth limitations. Pushing additional protocols over bandwidth constrained waveforms can cripple user data throughput or significantly reduce the user's perceived performance of their devices.  DLEP was designed to allow for optimized performance of wireless devices "in general," not just IEEE wireless devices. Thus, we requested additional features to eliminate the redundant and chatty overhead of the protocols you mentioned.  Furthermore, one should also acknowledge that a modem device may not be connected to the router via an Ethernet interface, but could be a PCI card, USB connection, etc, and therefore not contain an Ethernet MAC address.  
   I agree that the heartbeat is essential.  I guess the definition of the two FSM's would help rectify their behavior. The FSM could allow for a simple heartbeat message whenever a period of time since the last DLEP message was seen had expired. If a DLEP message (in general) is received, then the timer is reset and there is no need for a heartbeat.  This would keep the concept of a heartbeat but reduce the occurrences of heartbeat messages on the link.

Nelson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: Monday, October 01, 2012 5:01 PM
To: <[email-masked]> List
Subject: [manet] Some comments on manet-dlep-03

I quickly browsed thru the manet-dlep-03 draft and diff with the -02 version. I wonder why the draft is changed as it is. Does it reflect any workgroup decisions? Or is it a best effort undertaken by some authors? Or maybe, is this protocol in hands of Cisco instead of our workgroup?

I can see improvement on readability (router and modem, not client and server). Thanks for this. I still don't like the "participants" term. I prefer the clear router or modem terms, where the modem is the only participant that provides data.

I see a change from RFC 5444 messages to something else, with UDP as a suggestion. This is underspecified and does not lead to a standard protocol. There is a need to specify the basics.

The main purpose of the protocol is to get link metrics for links between router interfaces, from modem to router. 
In general, (ethernet) interfaces have MAC addresses. I can't see why different IDs are needed, where the MAC addresses would be fine.

There are a couple of functions in DLEP that are redundant, because other protocols or mechanisms can provide it.
Credits is one example (packet scheduling is to be performed on bottleneck, thus the modem). MAC - IP address resolution is another (standard ARP/ND is to be used, probably with proxy functions to get quick resolution). And there is SNMP.

The suggested metric types looks rather useful, but some experience showed me that it is difficult for a router to interpret these data. Also, with a large variety of L2 technology, it seems unwise and hard to me to support all of that in a general purpose router. Especially when the outcome is as simple as a dimensionless additive metric, such as in OLSR. I would specify only one mandatory metric type and all the rest as optional. This mandatory would be the link metric as we have defined in OLSRv2.

I don't get why the Heartbeat Interval/Threshold is optional. It looks essential to me. And interval could be fractions of a second.

The protocol needs synchronized state machines, maybe with an n to m relation between routers and modems. Getting this right is not that simple. I would use TCP for unicast connections, or use a simple timer-based database update exchange, just like OLSR.
Section 7 misses some ACK signal TLVs. The Neighbor Update ACK is only mentioned in 9.18 credit request. I can't find details on the Ack mechanism, e.g. message sequence numbers.

On Link Characteristics Request, fulfilling the request could take some time. How the modem should provide feedback on such is unclear.

I'm looking forward to a fruitful discussions how we can work this out.

Teco

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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Oct 2012 16:56:57 +0200

On Wed, Oct 3, 2012 at 2:33 PM, Powell lll, Nelson <[email-masked]> wrote:
>    I agree with the need for a defined protocol (UDP vs. TCP) as well as a need to define a separate FSM for both the Router and the Modem. That will ease integration issues for everyone.

Yes, specific FSMs for both the discovery process, the normal message
transfer and the ACK mechanisms are necessary if we want to have a
chance to get interoperable implementations.

>    Regarding the Ethernet MAC address comment, there are many L2 devices on the market that do not utilize the IEEE waveforms or phy, and cannot provide IEEE MAC addresses, nor do the developers wi…

Thats why I suggested increasing the size of the "Radio/Modem ID" to
six bytes. This ALLOWS the Radio/Modem to use a MAC address to provide
an unique idea, but it doesn't make it mandatory to use a MAC.

Henning Rogge

-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 3 Oct 2012 15:24:28 +0000

> chance to get interoperable implementations.

I disagree. I've not seen another IETF spec that contains "specific FSMs". That, IMO, crosses the line between documenting a protocol, and specifying an implementation. 

> an unique idea, but it doesn't make it mandatory to use a MAC.

The Modem ID/Router ID is intended as an internal (implementation specific) tag to allow implementations to correlate the traffic to a specific neighbor. 

Regards,
Stan

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 3 Oct 2012 18:01:29 +0200

> I disagree. I've not seen another IETF spec that contains "specific FSMs". That, IMO, crosses the line between documenting a protocol, and specifying an implementation. 

Well, off the top of my head RFC2328 (OSPF) specifies a number of state machines for various parts of the protocol behavior (interface, neighbor, ..) as does many other protocols.

As a state machine (to me) simply describes what messages a device is allowed to process in a given "state", what messages it is allowed to send in a given "state" and the minimum required actions that must be taken on protocol information bases upon having received a message, for protocol operation to be considered correct - a far cry from specifying an implementation.

For the record, my personal point of view is also that a protocol specification should be sufficiently detailed that any college-graduate programmer-with-no-experience can implement it _correctly_ (but, of course, not efficiently) just from the specification alone. (In the Paris 2005 IETF, I called that "the graduate student criteria for clarity", I think).

Cheer,

Thomas

---

From: Bo Berry <[email-masked]>
Date: Wed, 3 Oct 2012 15:18:13 -0400

Thanks for the comments on the draft.  My thoughts on the state machine suggestion below.
-Bo

> I disagree. I've not seen another IETF spec that contains "specific FSMs". That, IMO, crosses the line between documenting a protocol, and specifying an implementation. 

The draft uses message flow ladder diagrams instead of state diagrams, state tables, etc.  Easier to present in text and are very useful for implementations (including college students)

> The Modem ID/Router ID is intended as an internal (implementation specific) tag to allow implementations to correlate the traffic to a specific neighbor. 

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 3 Oct 2012 21:53:13 +0200

> The draft uses message flow ladder diagrams instead of state diagrams, state tables, etc.  Easier to present in text and are very useful for implementations (including college students)

Message flow ladder diagrams are fine - no they're great - for giving examples of instances of interaction. I don't quite think that state machines and message flow ladder diagrams are equivalent in their expressiveness, though. 

In this particular case, where  the protocol revolves around establishing and maintaining a session between two "devices", I ended up having to draw a state machine to follow the spec (and I got it wrong on the first try, btw), so I'd have thought it much helpful had it been in the spec.

Best,

Thomas

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 3 Oct 2012 20:05:17 +0000

> In this particular case, where  the protocol revolves around establishing and maintaining a session between two "devices", I ended up having to draw a state machine to follow the spec (and I got it…

…and if the FSM was as complicated as OSPF, you'd have a fine point. However, this FSM pretty much has 2 states: You're "in discovery", or you're "in session". Works that way for either the modem or the router. If a college student needs that mapped out…. 

Regards,
Stan

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 03 Oct 2012 15:20:33 -0500

> I disagree. I've not seen another IETF spec that contains
> "specific FSMs". That, IMO, crosses the line between documenting
> a protocol, and specifying an implementation.

RFC 793, September 1981.  Figure 6.

I have no idea if the inclusion of a finite state machine was
controversial over 30 years ago, but the document appears to
have served us well over the last generation.

Of course, RFC 793 is TCP, edited by Jon Postel.

-tjs

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 3 Oct 2012 22:22:15 +0200

Sent from my iPad

> …and if the FSM was as complicated as OSPF, you'd have a fine point. However, this FSM pretty much has 2 states: You're "in discovery", or you're "in session". Works that way for either the modem o…

Sure, you can draw any protocol with two states "turned on" and "turned off". The pictures I ended up drawing whilst reading through the I-D had considerably more than 2 states....

Thomas

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 3 Oct 2012 20:52:18 +0000

> Sure, you can draw any protocol with two states "turned on" and "turned off". The pictures I ended up drawing whilst reading through the I-D had considerably more than 2 states....

If that's the case, I'd be interested in your notes. Are they in the document you posted to the list? 

Regards,
Stan

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 3 Oct 2012 22:56:08 +0200

> If that's the case, I'd be interested in your notes. Are they in the document you posted to the list? 

No, they are - literally - on a napkin from my lunch when I worked through it today.  After all, aren't all IETF protocols designed on napkins? ;)

I've kept that napkin, as I thought it might come handy. I will try to find a scanner and share it. Won't be tonight, though, and likely not tomorrow, but probably Friday (and, if you don't have it then, remind me..) since that's when I know that I'll be back in an office with a scanner.

Cheers,

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Thu, 4 Oct 2012 10:07:21 +0200

> I disagree. I've not seen another IETF spec that contains "specific FSMs". That, IMO, crosses the line between documenting a protocol, and specifying an implementation.

As Thomas Clausen said too, the FSM for DLEP is not that trivia.

The "flow charts" are nice, but they do not tell the whole story,
because you cannot see which parts of them are causally connected and
which just happen one after another.

Teco already raised the question about ACKs and if a Radio had to wait
for an ACK before it sends the next data. A description of the
protocols internal mechanism (similar to the one we have for NHDP or
OLSRv2) would give an implementer an EXAMPLE how it could be
implemented (and a template to test different implementation ideas
against).

> The Modem ID/Router ID is intended as an internal (implementation specific) tag to allow implementations to correlate the traffic to a specific neighbor.

I know... I just want to extend it to 6 byte... we will need an unique
idea for each radio attached to a router. If the ID is 6 bytes, a
radio who has some kind of MAC address (for example its ethernet mac
address) it can use this as the default for an unique number.

But the user of the radio could later change this ID.

I do not want to change the semantics of the ID, I just want enough
bytes to have a source for an unique number (like the MAC address).

Everything you can do with a 4 byte ID you can do with a 6 byte ID too.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 4 Oct 2012 17:31:19 -0400

Henning
Thanks for the feedback.  Further discussion below.

On Oct 3, 2012, at 10:56 AM, Henning Rogge wrote:
> ~~cut

Currently there are two suggestions for the Router/Radio ID fields  
1)move the RR-IDs into the DLSP message header
2)expand the fields from 4-byte field currently intended to
  be a uint32, to 6-bytes so MAC addresses can be used as
  the unique IDs.

Another option, with the new DLEP formatting, is to drop the
IDs and use the underlying transport/driver addressing information 
as the discriminator.  This would save 12-bytes plus TLV bytes
from every message and the associated processing.  

Checking with a few off-list, this has been received in positive 
light. 

Thoughts from the WG welcomed.

Regard
-Bo

---

From: Henning Rogge <[email-masked]>
Date: Fri, 5 Oct 2012 10:03:47 +0200

> from every message and the associated processing.

This might be an interesting option for "one line" radios/modems
(hardware with a single layer-2 interface), similar to the design of
NHDP where you can drop the THIS_IF TLV if you only have one and the
src-ip can be used for THIS_IF.

But there are some "multi line" Software Defined Radios, which are
controlled over a single IP interface. With the current design of DLEP
the port number has to be fixed (well known) on both sides of the
connection, otherwise the "symmetric discovery" doesn't work. I think
DLEP should allow to have multiple radio instances which can
communicate to a router over the same IP interface.

Maybe there could be a rule that IF DLEP uses UDP, then the
combination of IP and port could be used as the ID of the router. Of
course this means that the ID becomes a 16 or 18 byte string for IPv6.

(I am still not convinced that allowing the router to play the active
discovery part is a good idea, this can lead to all kinds of trouble
including non-dlep aware radios suddenly sending DLEP-discovery
beacons of the router over the air).

> Checking with a few off-list, this has been received in positive

Can you maybe suggest that people that they come to this list and
contribute? IETF protocols should be discussed and developed on this
lists, but at the moment DLEP looks a bit like an one-way street of
information.

Henning

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Oct 2012 11:16:19 +0100

> Checking with a few off-list, this has been received in positive

Why it is positive? I think all options have advantages, but when I choose
one I want to know why?

> Thoughts from the WG welcomed.
will do my best,

---

From: Bo Berry <[email-masked]>
Date: Fri, 5 Oct 2012 07:01:24 -0400

> communicate to a router over the same IP interface.

yes, I agree, DLEP should support multiple radios on the same i/f 
if that i/f support such.   Let us review this aspect.  

----
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Oct 2012 12:04:01 +0100

Hi,

I support that we need the FSM (as Teco and Henning requested), to clarify
many issues. The problem with the flow diagram is that it is good only
within a specific protocol, but DLEP states is not dependent only within
one protocol in one layer, but it is a protocol that is interacting with a
MANET Routing protocol. Therefore, IMO, the FSM approach is suitable for
DLEP not flow diagram.

I suggest that who suggested/supports the FSM to submit his/her views and
suggestions, for progress, I will try to do the same

Abdussalam Baryun
University of Glamorgan, UK
++++++++++++++++++++++
On Thu, Oct 4, 2012 at 9:07 AM, Henning Rogge <[email-masked]> wrote:

> > I disagree. I've not seen another IETF spec that contains "specific
> FSMs". That, IMO, crosses the line between documenting a protocol, and
> specifying an implementation.
>
> > The Modem ID/Router ID is intended as an internal (implementation
> specific) tag to allow implementations to correlate the traffic to a
> specific neighbor.
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 5 Oct 2012 13:40:55 +0000

On Oct 5, 2012, at 4:03 AM, Henning Rogge wrote:

> contribute? [snip] ...DLEP looks a bit like an one-way street of
> information.
> 

It would be difficult for me to disagree with you more on this. The DLEP co-authors have presented the draft to the working group, discussed on this list, and held meetings with a number of people, yourself included. To claim that this is a "one-way street of information" is disingenuous, and offensive. We have accepted changes and additions to the draft, and have been as responsive as our "day jobs" allow.

Additionally, you assume facts not in evidence - specifically, that we *haven't* encouraged people to contribute on the list. Nothing could be further from the truth. 

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 5 Oct 2012 13:44:56 +0000

> if that i/f support such.   Let us review this aspect.  

The main issue we've seen with multiple radios on the same interface is how the broadcast domains start to overlap. Assume that all "stations" have a router, and 3 radios that are on different frequencies, etc… Now assume that all radios can establish connection with all other radios - a full mesh connection, on all of the radio devices. So, any router has 3 physical paths (each of the different radios) to the same destination. But, all 3 of those physical paths are represented by a single interface…. so what happens to things like broadcast packets? Do they get picked up and sent via all 3 radios? 

Stan

---

From: <[email-masked]>
Date: Fri, 5 Oct 2012 14:57:33 +0100

Stan,

You have actively discouraged people  with differing views from contributing, and you know it.

It's not as if dlep is the only solution to this problem. I don't see broad industry involvement in draft authorship, either. Isn't there a conflict between the same person chairing the group and pushing dlep for Cisco? Doing one of these things is fine. Doing both at the same time, no.

Lloyd Wood
http://sat-net.com/L.Wood/modem-router-integration

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stan Ratliff (sratliff) [[email-masked]]
Sent: 05 October 2012 14:40
To: Henning Rogge
Cc: <[email-masked]> List; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Oct 2012 15:41:27 +0100

Hi Stan,

> To claim that this is a "one-way street of information" is disingenuous,
and offensive. We have accepted changes and additions to the draft, and
have been as responsive as our "day jobs" allow.

IMHO, I have experienced with one manet-draft that authors taken a one-way
street of information approach, but I think we should not allow it for DLEP
and other WG-drafts, because these are IETF MANET WG drafts, not authors or
companies draft.

I RECOMMEND the WG chair to consider input of the list and announce in the
face-to-face meeting the list concerns. I thank you that you confirm that
the dlep authors are not taking such approach, even though some
participants may felt that for some reasons,

AB
-----

On Fri, Oct 5, 2012 at 2:40 PM, Stan Ratliff (sratliff)
<[email-masked]>wrote:

> It would be difficult for me to disagree with you more on this. The DLEP
> co-authors have presented the draft to the working group, discussed on this
> list, and held meetings with a number of people, yourself included. To
> claim that this is a "one-way street of information" is disingenuous, and
> offensive. We have accepted changes and additions to the draft, and have
> been as responsive as our "day jobs" allow.
>
> Additionally, you assume facts not in evidence - specifically, that we
> *haven't* encouraged people to contribute on the list. Nothing could be
> further from the truth.
>
> Stan
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 5 Oct 2012 19:24:13 +0200

Throwing a bone at Stan and bo here: I have discussed dlep with Stan out-of-band on many occasions, and he has (as far as I remember) always encouraged that I bounce my thoughts off the mailing list (especially when he didn't agree with me ;) ). 

That I haven't done so as frequently as I maybe should have is entirely to blame on me. I've been trying to catch up, though...

Of course, I cannot speak for the other folks Stan/Bo/etc have spoken to, but I would assume that they've encouraged them to the same.

I do agree that the more discussion happens on the list for WG documents, the better - of course. I guess that it goes without saying that the WG chairs agree ;)

Thomas 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 5 Oct 2012 19:32:34 +0200

Lloyd,

That is a fairly serious accusation to make.
 
I'd like to go on record that while I know of cases in the IETF where a conflict-of-interest was at play, I have noticed no such thing in MANET.

Thomas

Sent from my iPad

---

From: Teco Boot <[email-masked]>
Date: Sat, 6 Oct 2012 11:05:59 +0200

> The main issue we've seen with multiple radios on the same interface is how the broadcast domains start to overlap. Assume that all "stations" have a router, and 3 radios that are on different freq…

This is a somewhat more complex scenario that can be supported easily. STP is the old days solution. TRILL and other members in that family could be used. With MANET, sub-IP protocols can take care of it.

On how to support it: it is up to the radios to deliver the frame (it's L2, so I use frame), they may use the wired link or the wireless link.

I expect DLEP to provide data to the router, so the router can (should) select the best L2-path to the L3 next-hop. If dlep-03 can't do it, let's fix it. I proposed a solution for it multiple times (in the 802.11s context).

Teco

---

From: Teco Boot <[email-masked]>
Date: Sat, 6 Oct 2012 11:08:25 +0200

Op 5 okt. 2012, om 13:04 heeft Abdussalam Baryun het volgende geschreven:
> I support that we need the FSM (as Teco and Henning requested), to clarify many issues.

I did not request FSM.

My comment was that the -03 DLEP protocol is somewhat underspecified. Especially on session setup, loss/retransmit and optional heartbeats. My suggestion was to simplify the protocol and keep using RFC 5444, on a more efficient way.

Teco

---

From: Bo Berry <[email-masked]>
Date: Sun, 7 Oct 2012 19:00:18 -0400

Henning, All, hope everyone had a great weekend. 

I'll try to highlight the three points in this thread 
so we do not miss one, and offer a proposal that we can 
work towards consensus.

Relative to the IDs, suggest we remove the Router/Radio IDs
to reduce the overhead on every message and leverage the
transport/driver.  In the case of UDP, we can leverage the
src addr/port and dest addr/port for discrimination. 

Relative to router side discovery, suggest we drop the 
router side discovery and simplify the discovery process.  
The router becomes passive (server).  The radio is the 
active node responsible for initiating the discovery 
process.  This would essentially revert back to the 
original text.

Relative to DLEP supporting multiple radios on an interface, 
suggest DLEP allow for multiple radios on an interface that 
supports such.  Similar to UDP above, DLEP can leverage
the src addr/port and dest addr/port information. 

Thanks
-Bo

>> beacons of the router over the air).

Agree, the router side discovery can be removed. 

> ~~~cut

---
We cannot solve our problems with the same thinking we used when we created them. 
Albert Einstein

---

From: Teco Boot <[email-masked]>
Date: Mon, 8 Oct 2012 07:43:18 +0200

> Henning, All, hope everyone had a great weekend. 
I did :-)

> so we do not miss one, and offer a proposal that we can 
There are more topics in this thread. Please check my 1st 
posting, or summary below.

Good idea to use the ticketing system?

> src addr/port and dest addr/port for discrimination.
For the DLEP session, source address would be OK, I think.
This is more or less how IP works.

For the remote router, I still think a MAC address would be
the best choice. 6-byte ID field is OK.

> process.  This would essentially revert back to the 
With radio sending data with refresh interval and validity
time, there is no need for discovery. 

Or as alternative: radio sends announcements, and router 
asks for more.

> the src addr/port and dest addr/port information.
I didn't get the need for addr/port. Maybe because I don't
get the reason for the complexity in the current protocol.
Why can't the radio not just send out the data? And allow
multiple radio's and multiple routers on same link?
Multiple radio's, with links to same destination, could be
a sub-IP problem. Other scenario's are OK.

Other comments I posted, where you did not respond before:
 - please add change log
 - terminology radio, modem, server and participant for
   same object is not as clear as it could be. Please
   reduce to one or two.
 - please specify transport protocol, so we make sure
   implementations are compatible
 - please add OLSRv2 compliant dimensionless metric,
   and make this one mandatory. Rest can be optional.
 - please split the draft and remove in the proposed 
   standard document only the elements that requires a
   new protocol. Much of what is in current draft overlaps
   what we have today already.
 - please remove the reliable protocol function and use
   validity time, as for example NHDP/OLSR. If not, ACKs
   are mandatory. And there is a lot more to specify a 
   reliable protocol. Therefore I suggest TCP for a
   reliable unicast connection.
And there is the RFC 5444 discussion.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 8 Oct 2012 09:19:27 +0000

Teco
> And there is the RFC 5444 discussion.

I think that, the draft being where it is, it's appropriate for anyone saying it should be 5444 to propose concretely how (I think we are agreed not the previous version) and why that is an improvement. Note that I'm not arguing one way or the other. Note that the WG mandate to use 5444 applies to protocols using the manet protocol/port, not protocols developed by the WG. If the protocol is an AHRP the presumption is that it should use that protocol/port, but that doesn't apply to DLEP.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

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

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 8 Oct 2012 10:54:27 +0000

5444 is a solution (I won't comment on how good a solution, as I'm not neutral) to the basic problem of how to flexibly associate pieces of information with addresses (that are assumed to identify something, typically another router in a network) plus to include some flexible information not associated with addresses.

If you want to do this (flexibly include pieces of information in this way, some associated with addresses - which actually means any size identifiers) then 5444 is a possibly way to format such information, with advantages and disadvantages. If you want to carry information not of that form you can of course do it (you can carry almost anything, within the size limits) but it will have more disadvantages and fewer advantages.

So 5444 for DLEP (which I'm neither advocating for or against) would need to be set against that, one or more candidates produced, and pros and cons assessed. As I've said, the onus at this point must be on a proponent, if any, to do so.

I don't think any actual worked out good candidate was ever published here, only pieces of one.

-----Original Message-----
From: Taylor, Rick [mailto:[email-masked]] 
Sent: 08 October 2012 11:43
To: Dearlove, Christopher (UK); Teco Boot; Bo Berry
Cc: List
Subject: RE: [manet] Some comments on manet-dlep-03

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Teco,

With the greatest respect, I can't see how 5444 is applicable to DLEP.

Yes, it is possible to reshape the DLEP protocol into 5444, but it reduces the clarity of the protocol as it is transformed.

But more importantly, DLEP is not intended to travel over the network.  It is link-local by design.  Any communication between devices required to provide state for a DLEP implementation might use a 5444 formatted protocol, but as Stan so elegantly says, that's just 'radio magic' and is a layer hidden from DLEP.

DLEP describes the link-local communication between a router and some modems.  It should be formatted to maximize A) Clarity and correctness, B) Ease of implementation.  Efficient on the wire representation is not a requirement.

I previously had an extended exchange with Henning on this list, and between us we managed to fit DLEP-00 into RFC5444 in several ways.  But the more I consider it, the more I must conclude that we were solving the wrong problem.

Rick Taylor

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dearlove, Christopher (UK)
> Sent: 08 October 2012 10:19
> To: Teco Boot; Bo Berry
> Cc: List
> I think that, the draft being where it is, it's appropriate for anyone
> saying it should be 5444 to propose concretely how (I think we are agreed
> not the previous version) and why that is an improvement. Note that I'm
> not arguing one way or the other. Note that the WG mandate to use 5444
> applies to protocols using the manet protocol/port, not protocols
> developed by the WG. If the protocol is an AHRP the presumption is that it
> should use that protocol/port, but that doesn't apply to DLEP.
>
> --
> Christopher Dearlove
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: Bo Berry <[email-masked]>
Date: Mon, 8 Oct 2012 07:09:45 -0400

DLEP started with 5444 but ran into problems getting closure IP/MAC
TLVs that were defined, and we could not get changes to 5444.  Hence
discussion lead to the simplier, standard TLV draft, as I understand 
things.  From my perspective, I like the using standard TLVs.

-Bo

---

---

From: Bo Berry <[email-masked]>
Date: Mon, 8 Oct 2012 07:23:21 -0400

Teco

> Good idea to use the ticketing system?

after last week, simply making an effort to start fresh
with the items in my thread, not implying these are all topics. 
Trust that is OK with you, everyone.

Thanks for your comments and other suggestions below, they 
have helped the discussion as evident by the threads.

---

---

From: Bo Berry <[email-masked]>
Date: Mon, 8 Oct 2012 07:24:02 -0400

On Oct 8, 2012, at 6:52 AM, Taylor, Rick wrote:

> Teco,
> 
> Sorry, I am catching up on the MANET backlog...
> 
> I really don't want to see an OLSRv2 compliant dimensionless metric in DLEP.

agree

> 
> My understanding of one of the purposes of DLEP is to provide hard, measured metrics to routers from modems.  If an OLSRv2 implementation wishes to use a DLEP module to reduce the available metrics provided by modems to a metric for its own use then that is fine, but there are other consumers of DLEP metrics who have no need of the OLSRv2 metric.
> 
> As a counter-argument: why shouldn't DLEP report an OSPF hop-count?
> 
> I am not a radio-engineer, but from my perspective DLEP should present metrics that generically cover: Latency, Bandwidth, Reliability, Availability and Congestion.

agree

>> Teco Boot
>> Sent: 08 October 2012 06:43
>> To: Bo Berry
>> Cc: List

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 8 Oct 2012 12:35:34 +0000

While, as I have said, I'm not arguing for or against use of 5444, I think that when it was being discussed it was clear that MAC address should be the address type indexed against, which 5444 supports, and IP addresses then needed a TLV. Getting TLVs does not require a change to 5444. (Getting an IP-address carrying TLV might run into disagreements over  e.g. to compress or not to compress, but that's another story.)

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: 08 October 2012 12:10
To: Dearlove, Christopher (UK)
Cc: Taylor, Rick; Teco Boot; List
Subject: Re: [manet] Some comments on manet-dlep-03

-Bo

---

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 8 Oct 2012 14:49:03 +0000

Teco, 

OK, I've tried to pare this down some - only because the thread is getting pretty long. If I've left anything off, please let me know. A couple of these issues have been brought up, and declined. 

So far, the issues brought up are basically: 

1. Use the ticketing system - No promises, but I'll look into it… ;-)

2. The ID TLV:  This was intended solely as a transport-independent mechanism for a router or a radio to correlate traffic. As it turns out, nobody is using it. We're recommending that the correlation occur via the normal, standard 4-tuple that exists for any UDP traffic (source address, source port, dest address, dest port). The correlation is needed to support 1-N connection models (e.g. multiple radios feeding to 1 router, or multiple routers, feeding to 1 radio). And yes, we *do* have a "multiple routers to 1 radio" scenario in mind. That being said, the issue still exists with overlapping broadcast domains with multiple radios - whether a packet gets transmitted multiple times, across the multiple radios. However, the current DLEP protocol doesn't *force* you to put one (and only one) radio on a given interface. We're still advocating using MAC address to identify the far-end neighbor (aka the remote router). So, I'm with the others on the list who are good with removing it altogether.

3. Change log: My vote is "No". The existing IETF toolset contains the ability to "diff" 2 versions of a draft; it is far better than humans are in identifying the changes from version to version. I say we let the tools do what they do best. 

4. Terminology: I've made multiple runs at this, and apparently, still haven't satisfied you. Suggest some text. 

5. Transport protocol: I thought the draft made it pretty clear that DLEP uses UDP, with port numbers to be assigned by IANA. If that's not clear, then suggest some text. 

6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently routing protocol agnostic; I think it's best to keep it that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or….

7. Splitting the draft into two: Same as above. No. DLEP as currently specified has core and optional parts. I don't see any overlap. Also, as an implementer of the protocol, I like it when all of the pertinent information (on both core and optional parts) is in one document. 

8. "…remove reliable protocol function and use validity time": Again, I disagree. That IMO increases the complexity dramatically. 

Regards,
Stan

[snip]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 8 Oct 2012 15:46:22 +0000

As a matter of process, declined by whom? And when "nobody is using it", what's the set of people considered?

I agree with point 3.

I started writing something on point 6, starting from "what does OLSRv2 metric mean" but scrapped it when it was going to take too long to write. But in short I agree, but had to go through that argument (not presented) to do so. It leaves it open to others to disagree, but they need to explain what they are actually specifying in a lot more detail to then be considered.

I don't have any comments currently on the other points.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: 08 October 2012 15:49
To: Teco Boot
Cc: List; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Teco, 

1. Use the ticketing system - No promises, but I'll look into it. ;-)

6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently routing protocol agnostic; I think it's best to keep it that way. If we add an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or..

8. ".remove reliable protocol function and use validity time": Again, I disagree. That IMO increases the complexity dramatically. 

Regards,
Stan

[snip]

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 8 Oct 2012 16:41:10 +0000

> As a matter of process, declined by whom? And when "nobody is using it", what's the set of people considered?

My apologies, I should have been clearer about that. The points were discussed on the WG mail list; there wasn't consensus behind them.

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 8 Oct 2012 17:58:28 +0100

+1
my vote in line below,

> 1. Use the ticketing system - No promises, but I'll look into it… ;-)
no objection

>
> 2. The ID TLV:  This was intended solely as a transport-independent
> mechanism for a router or a radio to correlate traffic. As it turns out,
> nobody is using it. We're recommending that the correlation occur via the
> normal, standard 4-tuple that exists for any UDP traffic (source address,
> source port, dest address, dest port). The correlation is needed to support
> 1-N connection models (e.g. multiple radios feeding to 1 router, or
> multiple routers, feeding to 1 radio). And yes, we *do* have a "multiple
> routers to 1 radio" scenario in mind. That being said, the issue still
> exists with overlapping broadcast domains with multiple radios - whether a
> packet gets transmitted multiple times, across the multiple radios.
> However, the current DLEP protocol doesn't *force* you to put one (and only
> one) radio on a given interface. We're still advocating using MAC address
> to identify the far-end neighbor (aka the remote router). So, I'm with the
> others on the list who are good with removing it altogether.
>
agreed

>
> 3. Change log: My vote is "No". The existing IETF toolset contains the
> ability to "diff" 2 versions of a draft; it is far better than humans are
> in identifying the changes from version to version. I say we let the tools
> do what they do best.
>
agree with No vote,

>
> 4. Terminology: I've made multiple runs at this, and apparently, still
> haven't satisfied you. Suggest some text.
>
still needed details,

>
> 5. Transport protocol: I thought the draft made it pretty clear that DLEP
> uses UDP, with port numbers to be assigned by IANA. If that's not clear,
> then suggest some text.
>
agree its clear

>
> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is currently
> routing protocol agnostic; I think it's best to keep it that way. If we add
> an "OLSRv2 metric", then why not an "OSPFv2 metric", and/or an "OSPFv3
> metric", and/or a "BGP metric", and/or….
>
agreed with  No vote,

>
> 7. Splitting the draft into two: Same as above. No. DLEP as currently
> specified has core and optional parts. I don't see any overlap. Also, as an
> implementer of the protocol, I like it when all of the pertinent
> information (on both core and optional parts) is in one document.
>
agreed with No vote

>
> 8. "…remove reliable protocol function and use validity time": Again, I
> disagree. That IMO increases the complexity dramatically.
>
 no objection

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 13:12:45 +0200

> src addr/port and dest addr/port for discrimination.

The combination of this four should easily identify a "session" (pair of 
DLEP radio and router).

of course the routers port number will be fixed (IANA assigned), but 
that shouldn't matter.

> process.  This would essentially revert back to the

I support this, I am not even sure why the change was introduced in the 
first place.

This will remove both the starvation (passive discovery on router AND 
radio) and the race condition (active discovery on router AND radio). 
And it prevents a router from spamming non-DLEP radio (which will most 
likely be also bridges) with discovery beacons.

> the src addr/port and dest addr/port information.

If each radio-instance runs on a different port (which the router can 
learn by listening to the discovery beacons of both) this should work.

I would have preferred a "single socket" solution, but this is still an 
easy way to do it.

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: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 13:18:29 +0200

On 10/08/2012 11:19 AM, Dearlove, Christopher (UK) wrote:
> I think that, the draft being where it is, it's appropriate for
> anyone saying it should be 5444 to propose concretely how (I think we
> are agreed not the previous version) and why that is an improvement.

I could do this if the list wants to see it.

I would like to see RFC5444 in DLEP, but I think working on the protocol 
mechanisms and tie down the specification so we get a high chance of 
interoperability is more important.

At the moment I think it will be easy to build multiple DLEP 
implementations that are consistent with the draft and are NOT 
interoperable with each other.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 13:23:15 +0200

On 10/08/2012 04:49 PM, Stan Ratliff (sratliff) wrote:
> mechanism for a router or a radio to correlate traffic. As it turns
> out, nobody is using it. We're recommending that the correlation
> occur via the normal, standard 4-tuple that exists for any UDP
> traffic (source address, source port, dest address, dest port). The
> correlation is needed to support 1-N connection models (e.g. multiple
> radios feeding to 1 router, or multiple routers, feeding to 1 radio).

> And yes, we *do* have a "multiple routers to 1 radio" scenario in
> mind.

Are you talking about connecting a DLEP radio locally to multiple DLEP 
routers (I think I mentioned something similar a few months ago).

> 6. OLSRv2 dimensionless metric: Again, my vote is "No". DLEP is
> currently routing protocol agnostic; I think it's best to keep it
> that way. If we add an "OLSRv2 metric", then why not an "OSPFv2
> metric", and/or an "OSPFv3 metric", and/or a "BGP metric", and/or….

One question about the "relative link quality".

Why is the range 0-100? If we decide to use a single byte, wouldn't it 
be better to use 0-255?

I know PPPoE use 0-100, but just because PPPoE does strange things we 
don't need to follow their example.

> 8. "…remove reliable protocol function and use validity time": Again,
> I disagree. That IMO increases the complexity dramatically.

It can simplify the protocol but add the need for a few more timers in 
the implementation.

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 13:30:50 +0200

I'd like to second what Henning says, but in a different way.

I think that the first order of business is to tie down the protocol features -- it seems that there still is divergence on if some features should/should-not be in there. For example, sessions, timers, periodic signals, and some of the other things that Teco mentioned (stuff already done by other protocols, or not?) ....

The second order of business is to specify the mechanics of those protocol features, by way of state machines, procedural descriptions, pseudocode or whatnot.

And then, we can fiddle with the frame format used ;)

(Like Chris, I am not neutral as to the RFC5444 discussion)

Thomas

On Oct 9, 2012, at 1:18 PM, Henning Rogge <[email-masked]> wrote:

> I would like to see RFC5444 in DLEP, but I think working on the protocol mechanisms and tie down the specification so we get a high chance of interoperability is more important.
> 
> At the moment I think it will be easy to build multiple DLEP implementations that are consistent with the draft and are NOT interoperable with each other.
> 
> Henning Rogge
> 
> 
> --

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 13:41:08 +0200

Op 9 okt. 2012, om 13:12 heeft Henning Rogge het volgende geschreven:

> I support this, I am not even sure why the change was introduced in the first place.
> 
> This will remove both the starvation (passive discovery on router AND radio) and the race condition (active discovery on router AND radio). And it prevents a router from spamming non-DLEP radio (which will most likely be also bridges) with discovery beacons.

We have to add text for dlep filters on the radio. For non-dlep radio's we run into problems in that the dlep traffic is bridged into the wireless network over there. Using VLANs would be a solution, but I do not prefer making VLANs mandatory. So we could add text saying that the dlep filters are necessary and that we cannot solve problems with links between router and radio, with multiple radio's, where some of them are non-delp.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 13:47:53 +0200

On 10/09/2012 01:41 PM, Teco Boot wrote:
>>> Relative to router side discovery, suggest we drop the router
>>> side discovery and simplify the discovery process. The router
>>> becomes passive (server).  The radio is the active node
>>> responsible for initiating the discovery process.  This would
>>> essentially revert back to the original text.
>>
>> This will remove both the starvation (passive discovery on router
>> AND radio) and the race condition (active discovery on router AND
>> radio). And it prevents a router from spamming non-DLEP radio
>> (which will most likely be also bridges) with discovery beacons.
>
> We have to add text for dlep filters on the radio. For non-dlep
> radio's we run into problems in that the dlep traffic is bridged into
> the wireless network over there. Using VLANs would be a solution, but
> I do not prefer making VLANs mandatory. So we could add text saying
> that the dlep filters are necessary and that we cannot solve problems
> with links between router and radio, with multiple radio's, where
> some of them are non-delp.

If only the radio produces multicast packets (for discovery) and all 
answers of the router (if any at all) are unicasts, we will not have 
this problem.

The switch between the router and the radios should learn about the 
unicast target by listening to the DLEP-radios Source-MAC address of the 
discovery packets.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 13:48:38 +0200

Op 9 okt. 2012, om 13:23 heeft Henning Rogge het volgende geschreven:

> Why is the range 0-100? If we decide to use a single byte, wouldn't it be better to use 0-255?
> 
> I know PPPoE use 0-100, but just because PPPoE does strange things we don't need to follow their example.
+1
(it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578)

> It can simplify the protocol but add the need for a few more timers in the implementation.
Could be one timer, for housekeeping. The protocols should be designed in such a way the dat in information databases is explicitly revoked and nothing depends on the housekeeping timer, except the cleanup. Many protocols we have today work this way. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 14:01:02 +0200

Op 9 okt. 2012, om 13:47 heeft Henning Rogge het volgende geschreven:

> If only the radio produces multicast packets (for discovery) and all answers of the router (if any at all) are unicasts, we will not have this problem.

The dlep multicast packets are seen by the other, non-dlep radio. Then, they are forwarded towards the wireless net.

> 
> The switch between the router and the radios should learn about the unicast target by listening to the DLEP-radios Source-MAC address of the discovery packets.
This is unicast.
For multicast and IGMP/MGP snooping and related tricks: I have some experiences with bad implementations. I simply turn such off. 

In case of DLEP, what can stop multicast from one dlep radio, to another non-dlep radio, towards the wireless network? I can think of the following:
 - Separate interfaces, VLANS are OK.
 - Multicast filters on switch, with IGMP/MDP snooping (buggy).
 - L2 filters on these non-dlep radio's. Hard to implement on existing gear.
 - Usage of unicast, use multicast for discovery only. There are L2 discovery protocols already, so we could integrate.
 - Simply add text: "don't do that".

Teco

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 08:04:50 -0400

Henning, All
My reading of the discussion on these topics, it seems we are
reaching consensus.  If there are disagreements, please let us
know. 

Suggest we agree to close on these topics end of this week 
if no further discussion.  

Thanks
-Bo

On Oct 9, 2012, at 7:12 AM, Henning Rogge wrote:

> The combination of this four should easily identify a "session" (pair of DLEP radio and router).
> 
> of course the routers port number will be fixed (IANA assigned), but that shouldn't matter.
> 
> If each radio-instance runs on a different port (which the router can learn by listening to the discovery beacons of both) this should work.
> 
> I would have preferred a "single socket" solution, but this is still an easy way to do it.
> 
> Henning Rogge
> 
> -- 

---

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 08:11:53 -0400

Teco, Henning
in-line

> (it is PPPoE Extensions for Credit Flow and Link Metrics, RFC 5578)

The RLQ is defined as a percentage value to facilitate consistent
definition across different radio types.  When processing the RLQ,
the router can apply the same heuristics to the RLQ.  Otherwise
there is risk of that the router would have to aware of these
differences. We've been through this discussion many times.  So 
from our experiences, my vote is to leave the RLQ as defined.  

---

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 14:32:46 +0200

> from our experiences, my vote is to leave the RLQ as defined.  

Having a minimum and a maximum is OK. I don't see much difference in semantics, just improved efficiency of bits used, or even better, use more bits.

>> Could be one timer, for housekeeping. The protocols should be designed in such a way the dat in information databases is explicitly revoked and nothing depends on the housekeeping timer, except th…

I posted on unneeded complexity and partial specification.
I suggested two options, both could be supported by the protocol:
a) use unreliable protocol, with vtime
b) use TCP

Discussed whole morning with app guys on why there is a need for UDP congestion control and better capabilities for retransmit. Let's circumvent and do it right this time. Read BCP 145 for the details.

Teco

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 08:58:43 -0400

Teco
in-line
-Bo

> Having a minimum and a maximum is OK. I don't see much difference in semantics, just improved efficiency of bits used, or even better, use more bits.

Thanks, I read as agreement.
As we know, there are many diff types of radios and
they 'all' do things differently, even SDRs. 

> Discussed whole morning with app guys on why there is a need for UDP congestion control and better capabilities for retransmit. Let's circumvent and do it right this time. Read BCP 145 for the deta…

OK, I'll look at 145. Suggest we split this topic into its
own thread for easy discussions and closure, when people respond.
These emails get long and stuff may be missed by anyone of us.

---

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 15:24:23 +0200

> they 'all' do things differently, even SDRs.

As long as we remove the "if cannot be calculated, insert 100" part I 
can live with this.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 9 Oct 2012 13:34:28 +0000

I would like to slightly modify Thomas's comment as it applies to me.

While a part of me says it's nice having people use your stuff, I'm reasonably neutral on the question as to whether DLEP should use 5444. I'm not neutral on whether I think 5444 does the job it was designed for.

(But of course neither am I saying it's perfect, it contains known compromises as well as the possibility someone could point out improvements we missed. However I'm completely non-neutral - as a user rather than an author - on whether we should update it. No.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: 09 October 2012 12:31
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 15:35:57 +0200

Yeah, what Chris said - much more eloquently - also represents my position on this matter.

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 09:55:05 -0400

Thomas, Christopher
I understand your perspectives towards using 5444. 

DLEP is not a manet routing protocol and is thus not required to use
5444.  We have tried to resolve the issues on this list which lead
us to using standard TLVs.  This is simplier, more efficient than
the 5444 encoding.  

So I do not agree that we need to re-open this discussion.  

Thanks
-Bo

---

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 15:56:54 +0200

Bo,

I think that neither of Chris nor I suggested that it should (or should not) be opened.

I think that we, generally, agreed that there were other, more important, thing to get right before considering if it should (or should not) be opened.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:02:16 +0000

You comment implies you think I do think the issue should be re-opened. Speaking only for myself, I've explicitly said I neither am saying we should or we should not. I'm saying anyone who thinks we should re-open it, should supply a candidate alternative solution. If I see one then I'll make a judgement.

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: 09 October 2012 14:55
To: Thomas Clausen
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

Thomas, Christopher

Thanks
-Bo

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:04:52 +0000

Actually, I haven't caught up properly yet, so I can't judge if the things being discussed are converging successfully or still have major issues. (I can make guesses, but they aren't well-enough informed.)

-----Original Message-----
From: Thomas Clausen [mailto:[email-masked]] 
Sent: 09 October 2012 14:57
To: Bo Berry
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

Bo,

Thomas

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 10:16:15 -0400

Christopher
I'm getting the impression that we're at rough consensus, if not very close.

Any other comments, perspectives from the WG?

-Bo

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:24:48 +0000

> interoperable with each other.

That looks a bit short of rough consensus to me. (Note that I'm not either agreeing or disagreeing with the quote.)

I also see Henning still saying today " I would like to see RFC5444 in DLEP".

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: 09 October 2012 15:16
To: Dearlove, Christopher (UK)
Cc: Thomas Clausen; [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

Christopher

-Bo

---

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 16:30:02 +0200

I think we have a rough consensus that the discovery mechanism should
be "radio active, router passive" (still waiting for an "agreed" from
Stan on this) and that the existing metric TLVs can be put into the
standard, if we keep out this "lie about the value if you do not
know".

I think there might be also a VERY rough consensus that the packet
format is not the most important thing we should work on right now. If
we get the basic building blocks right and the specification of the
protocol mechanisms, the packet format will be not that difficult to
do.

Both Teco and me still think that using RFC5444 would be the better
solution for DLEP, but I could live with the current one IF we get the
protocol and specification issues fixed. Please call for a packet
format consensus after we did it, its meaningless at the moment.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:36:22 +0000

On Oct 9, 2012, at 10:30 AM, Henning Rogge wrote:

> Stan on this)

agreed.

> and that the existing metric TLVs can be put into the

I plan on making Latency, Resources, and RLQ optional TLVs in DLEP-04. Since they are optional, I plan on leaving the additional text on "default settings" intact - e.g., if an implementation decides to utilize this OPTIONAL TLV, AND said implementation (for whatever reason) either can't calculate at the given moment (or wants to default it), then as you put it - "Lie about the value".

Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 16:40:32 +0200

Op 9 okt. 2012, om 15:24 heeft Henning Rogge het volgende geschreven:

> As long as we remove the "if cannot be calculated, insert 100" part I can live with this.

Lets first find out min_value and max_value, and precision. I read your posting as: "if cannot be calculated, insert max_value, which is 100%, or 1". I agree.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 9 Oct 2012 14:41:42 +0000

There has been some discussion about 0-100 or 0-255. Why not reserve 255 for unknown (treat as X for X not necessarily equal to 255) and use 0-100 or 0-254, or even use 0-127 (or 0-100) and MSB set says "actually unknown".

(Apologies if I have mixed up two things incorrectly here.)

If you do use anything not full range, what do you do if you get another value? If discard, discard what?

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 09 October 2012 15:36
To: Henning Rogge
Cc: Bo Berry (boberry); Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

agreed.

Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 16:41:49 +0200

> I plan on making Latency, Resources, and RLQ optional TLVs in DLEP-04. Since they are optional, I plan on leaving the additional text on "default settings" intact - e.g., if an implementation decid…

The suggested defaults are a good advise for the DLEP-Router
implementation, so I agree we should keep them.

Maybe we should even put them into a "default section" for protocol
parameters and suggested default TLV values.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 16:42:58 +0200

> If you do use anything not full range, what do you do if you get another value? If discard, discard what?

Everyone agrees we want to have a TLV value. Why put an "unknown"
value into it if we can just skip the whole TLV?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 16:52:25 +0200

> value into it if we can just skip the whole TLV?
Just to fill up the pipe :-)
Or a beter argument: if we discuss addressblock TLVs, the "unknown" value could be used for increased efficiency, if only few nodes miss the value, and other values in addressblock are available. Then, a single address block can be used, instead of splitting up the set.
So IMHO it is a nice to have option to send "unknown" value or suppress sending, with the same effect.
I agree with options that this a bit of a dirty hack.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 16:57:13 +0200

> format consensus after we did it, its meaningless at the moment.

If we keep the reliable transfer, and use our TCP for it, RFC 5444 doesn't make sense.
If we go for refresh with vtime, RFC 5444 makes the protocol rather efficient.

I agree on postponing this topic and do not make premature conclusions on consensus, or not.

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 07:58:06 -0700

The only concern with reporting an unknown value by simply not including the TLV is if the link state transitions from a known value to an unknown value. I'm not sure how often this would happen, but it seems easy enough to reserve 255 (or whatever) as an 'unknown' code point.

*********

To change the subject radically, I think the text in sections 9.9 and 9.10 fail to make the case for distinct expressions of "expected forwarding time" and "latency." 

In the text, EFT is carefully defined. I understand that latency will be implementation-dependent, but if I were to implement a router or radio with this feature, I have no idea how what I'm expected to calculate/interpret differs from EFT. After poking around a bit in the list archives, it seems like EFT is just a really good way to compute latency, in which case it's not a separate metric but just a really good vendor implementation of Latency.

Moreover, on a purely editorial note, 9.9 defines the metric in the main body in the text, while 9.10 defines latency in the field definition.

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Tuesday, October 09, 2012 7:43 AM
To: Dearlove, Christopher (UK)
Cc: [email-masked]; Bo Berry (boberry); Stan Ratliff (sratliff)
Subject: Re: [manet] Some comments on manet-dlep-03

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government."
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 17:03:06 +0200

> The only concern with reporting an unknown value by simply not including the TLV is if the link state transitions from a known value to an unknown value. I'm not sure how often this would happen, b…

If a radio supports RLQ it should ALWAYS include the TLV... if it does
not, it should NEVER include it.
(maybe this should be a MUST in the final RFC)

So the transition should not happen at all.

> In the text, EFT is carefully defined. I understand that latency will be implementation-dependent, but if I were to implement a router or radio with this feature, I have no idea how what I'm expect…

Yes, that was my feeling about this too. We need a good specification
what a TLV is about and how it should be generated/interpreted.
Otherwise we will get non-interoperable implementations.

Henning Rogge

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 08:08:13 -0700

RLQ calculation is so loosely defined that it's hard to precisely describe how this kind of thing might happen. Latency is a bit easier. But in either case, I can imagine a situation where a radio is RLQ/Latency capable, but it hasn't heard from a neighbor in a while, at least in a way where it can make any sort of reasonable estimate of either quantity. In this case, it should report to the router a transition from an RLQ of "foo" to an RLQ of "unknown". Therefore, we need an unknown code point.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 8:03 AM
To: Duke, Martin
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry (boberry); Stan Ratliff (sratliff)
Subject: Re: [manet] Some comments on manet-dlep-03

> The only concern with reporting an unknown value by simply not including the TLV is if the link state transitions from a known value to an unknown value. I'm not sure how often this would happen, b…

If a radio supports RLQ it should ALWAYS include the TLV... if it does not, it should NEVER include it.
(maybe this should be a MUST in the final RFC)

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 15:10:02 +0000

> Otherwise we will get non-interoperable implementations.

Then, I would say "suggest some text". I have a desire to keep the "Latency" TLV for interoperability with RFC 5578 (the PPPoE extensions). We do have potential deployments that would use both a PPPoE-based radio, as well as a DLEP radio. I think that making Latency optional pretty much resolved the situation - e.g., and implementation is free to use EFT if that is deemed to be "better". 

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 15:11:18 +0000

> RLQ calculation is so loosely defined that it's hard to precisely describe how this kind of thing might happen. Latency is a bit easier. But in either case, I can imagine a situation where a radio…

I'm having a hard time with the notion of a Link Quality that is "unknown". Seems like a radio would report a quality of "0" (worst case) in that event. 

Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 08:12:37 -0700

I would be happy to suggest text if I understood the difference between EFT and Latency. What is the former trying to capture that isn't a commonly understood part of latency? What would a router do with an EFT report that it couldn't do with a latency report? If no one can articulate the difference, then let's just have a latency TLV and be done with it.

Martin

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 8:10 AM
To: Henning Rogge
Cc: Duke, Martin; Dearlove, Christopher (UK); [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 17:13:24 +0200

> Then, I would say "suggest some text". I have a desire to keep the "Latency" TLV for interoperability with RFC 5578 (the PPPoE extensions). We do have potential deployments that would use both a PP…

I do not even get whats the difference between the two.

Can EFT be used to describe the Latency? If yes, maybe dropping the
EFT as a TLV of its own and mentioning it as one way of calculation in
the Latency TLV might be a good idea.

> I'm having a hard time with the notion of a Link Quality that is "unknown". Seems like a radio would report a quality of "0" (worst case) in that event.

Or drop the neighbor from the current list if the situation doesn't
improve... *nod*

Henning Rogge

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 08:15:52 -0700

Although I have never implemented a router that uses these metrics, I suspect that I would want to treat RLQ=100 links as best for forwarding, RLQ=0 links worst, and RLQ=unknown as somewhere in between.

Martin

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 8:11 AM
To: Duke, Martin
Cc: Henning Rogge; Dearlove, Christopher (UK); [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 9 Oct 2012 17:23:02 +0200

> I would be happy to suggest text if I understood the difference between EFT and Latency. What is the former trying to capture that isn't a commonly understood part of latency? What would a router d…

We need normative text or pointer to such. Diff could be counting queueing delay, or not. Another: retransmit time, or not. 

An old suggestion, that didn't make it in dlep yet: airtime, as clearly specified in 802.11_2012.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 17:31:54 +0200

> An old suggestion, that didn't make it in dlep yet: airtime, as clearly specified in 802.11_2012.

There are quite a few useful values even a primitive Linux wificard
will supply that cannot be expressed at the moment. Having a
standardized way to express them (as optional TLVs) would further
improve interoperability.

Its a scary idea that several companies will create TLVs with the same
"concept" (airtime for example) but use different encodings and
different "private metric types".

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 17:34:50 +0200

> the Latency TLV might be a good idea.

I will articulate this ever so slightly differently.

What would a device do *differently* when receiving a LatencyTLV, depending on if the value was calculated using EFT or something else?

If the answer is "nothing", then we should probably have just the LatencyTLV.

If the answer is "something", then we should want to have that "something" detailed. 

If the answer is "mostly nothing, but it is good to know how it is calculated for XXX other reason(s)", then perhaps a LatencyTLV with a field (LatencyType) and an associated IANA registry for that field would be a good idea?

I admit, I do not know enough about this myself, to have the answer immediately available, but those would be questions I'd like to see answered on this point.

Best,

Thomas

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 11:36:05 -0400

All, just a happy note to acknowledge the diversity of discussion
from the WG.
-Bo

---

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 17:36:26 +0200

> If the answer is "mostly nothing, but it is good to know how it is calculated for XXX other reason(s)", then perhaps a LatencyTLV with a field (LatencyType) and an associated IANA registry for that…

That sounds like a TLV extension type... ;)

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 17:38:12 +0200

> Although I have never implemented a router that uses these metrics, I suspect that I would want to treat RLQ=100 links as best for forwarding, RLQ=0 links worst, and RLQ=unknown as somewhere in bet…

I'm in somewhat of the same boat as you, experience-wise but my conclusions would be somewhat different:

RLQ=MAXVALUE would be best, RLQ=0 worst.

RLQ=UNKNOWN, I might imagine that one could  envision to prefer to "use a link with known characteristics, even if not with RLQ=MAXVALUE" over using a link with entirely unknown characteristics.

At least, using a link with known characteristics could allow (for example) parametrizing the traffic to something guaranteed to "fit" over the link.....

I do not know if that is a realistic usecase or not (I know that I've deployed something where it made sense like that for L3 routing)

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 17:41:02 +0200

> different "private metric types".

Stating the obvious here, but that - to me - indicates:

	o	An IANA registry
	o	A sufficiently large field (code-point space - is 1 octet going to be enough?)
	o	A requirement for getting a code-point from that registry being the existence
		of an RFC, stipulating how the values are calculated, encoded and interpreted

Best,

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 17:45:11 +0200

Sent from my iPad

> value into it if we can just skip the whole TLV?

Might the presence of a TLV with an unknown value serve to say "I do not know yet, but will soon" to the other end have some semantic value?

I will take an example that I know, but which is not in itself relevant (So take it as just an illustrative point): security. There's a difference between saying "I do not have the ability to establish a security association" (no TLV) and "I have not yet been able to establish a security association" (TLV with unknown). In the former case, on might a priori discard the link, in the latter try to set it up?

Again, this is just an illustrative point, I do not know if there's something of that kind in this precise scenario?

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Oct 2012 17:47:21 +0200

> I do not know if that is a realistic usecase or not (I know that I've deployed something where it made sense like that for L3 routing)

I wonder if adding a complete "LINK_STATUS" similar to the one in NHDP
would make sense... "HEARD", "SYMMETRIC", "LOST" or even "PENDING"
might make sense for some Linklayers.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 17:49:25 +0200

> That sounds like a TLV extension type... ;)

Yes, it does. I wonder where that idea came from ;)

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 16:23:51 +0000

> I do not know if that is a realistic usecase or not (I know that I've deployed something where it made sense like that for L3 routing)

Well, having implemented a DLEP router that uses the metrics, I don't understand what I'd do with an "Unknown" value… Just on a purely esoteric level, Thomas has a point in that there's a difference between "I can't calculate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." To extend that definition slightly, from the router's perspective, leads me to trying to deal (in general) with the notion of the radio telling the router: "I have a new neighbor! However, I don't have the foggiest notion as to what the link characteristics are to said neighbor. Have a nice day!"  Again, just from the perspective of the router, I'm tempted to want to respond to that by effectively saying "Call me when you figure it out…" Maybe I'm not seeing the forest for all of these trees… 

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 09:30:08 -0700

Perhaps I've missed an email, but I think the choices we're debating are
(1) Radios that don't have an RLQ estimate MUST NOT send an RLQ TLV; or
(2) Those radios MAY send an RLQ TLV with code UNKNOWN.

I think the case where a radio is taking time to acquire an estimate is handled well using either design; it just starts adding the TLV whenever it has an estimate. The case that isn't handled is if the radio loses that ability for one reason or another. In (1) I don't see any obvious syntax to explain that there is no longer a good estimate.

You could say that this is a corner case, and you'd be right. But the cost of this is RLQ field code points that we're not using anyway and a couple of lines of text in the spec. So why not support it?

Martin

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 9:24 AM
To: Thomas Heide Clausen
Cc: Duke, Martin; Dearlove, Christopher (UK); [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

> I do not know if that is a realistic usecase or not (I know that I've deployed something where it made sense like that for L3 routing)

Well, having implemented a DLEP router that uses the metrics, I don't understand what I'd do with an "Unknown" value... Just on a purely esoteric level, Thomas has a point in that there's a difference between "I can't calculate RLQ. Ever." and "I can calculate RLQ, but I don't know what it is yet." To extend that definition slightly, from the router's perspective, leads me to trying to deal (in general) with the notion of the radio telling the router: "I have a new neighbor! However, I don't have the foggiest notion as to what the link characteristics are to said neighbor. Have a nice day!"  Again, just from the perspective of the router, I'm tempted to want to respond to that by effectively saying "Call me when you figure it out..." Maybe I'm not seeing the forest for all of these trees... 

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 9 Oct 2012 09:33:04 -0700

And as for "not knowing" how we would handle code UNKNOWN: I don't really know either, though I have my biases. But why not allow router vendors to innovate here? Maybe I know what the radio type is, and have a heuristic for RLQ in the absence of radio data.

Martin

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2012 9:24 AM
To: Thomas Heide Clausen
Cc: Duke, Martin; Dearlove, Christopher (UK); [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 16:44:36 +0000

> You could say that this is a corner case, and you'd be right. But the cost of this is RLQ field code points that we're not using anyway and a couple of lines of text in the spec. So why not support…

I haven't specifically said I'm against the idea. I've said I don't understand it.  I'm trying to avoid future emails, from people that haven't yet engaged in the DLEP debate, that say "Unknown? Why did you do something like that? What would I use this for? This could potentially cause interoperability problems."

>> RLQ=UNKNOWN, I might imagine that one could  envision to prefer to "use a link with known characteristics, even if not with RLQ=MAXVALUE" over using a link with entirely unknown characteristics.

It seems to me that a radio could (should?) report this "unknown" value as RLQ=WORST_VALUE, or 0. At least in my implementation, that would make the link "the link of last resort", which is what I think everyone is looking for. 

Having said all of that, I do agree with you that it doesn't take much to support "Unknown", except that I would be looking for text suggestions to clearly explain the "We just put this in to allow for innovation, and we're not sure what you'd use it for" arguments. 

Regards,
Stan

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 18:51:45 +0200

Stan,

> Well, having implemented a DLEP router that uses the metrics, I don't understand what I'd do with an "Unknown" value… Just on a purely esoteric level, Thomas has a point in that there's a differenc…

Thanks for taking time to answer to this, and for taking it in the inquisitive spirit my mail was meant. I insist, I am no expert in this domain of DLEP and I do not know if it is realistic.

What you are saying is, that proper behavior is "don't say anything about a neighbor until you have an useful RQL to report"? If so, then your argument is probably right (could, then, that be specified behavior?)

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 18:54:35 +0200

I understood from Stan's mail that the situation where a radio would have to report "UNKNOWN" was not even esoteric, but a deliberate design-decision to not ever happen?

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Oct 2012 17:04:38 +0000

> What you are saying is, that proper behavior is "don't say anything about a neighbor until you have an useful RQL to report"? If so, then your argument is probably right (could, then, that be speci…

Yes, that's what I'm advocating for. 

Regards,
Stan

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 9 Oct 2012 19:36:59 +0200

> Yes, that's what I'm advocating for. 

Great. If documented thus, I am happy with that outcome.

Thomas

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 15:30:48 -0400

Teco
I reviewed 
   Request for Comments: 5405  
   BCP: 145, Unicast UDP Usage Guidelines for Application Designers

DLEP is only control plane traffic between the router and its 
connected radio.  The draft should allow for driver implementations 
(pci SDRs for example) as well as ethernet protocols: UDP, SCTP, 
TLS. So abstracting DLEP from the transport is good. 

I'd like to see a flexible DLEP such that it allows for easy 
adoption by different radios with different requirements.  I 
think we should be careful not to assume all radios can/should
implement DLEP the same.  Some may enable heart beats, some
may not.  Some radios may be able to generate RLQ and some
not.  Some radios may want to use a broadcast/multicast for 
discovery and some may use unicast. 

I'm OK with the current direction. 

-Bo

On Oct 9, 2012, at 8:58 AM, Bo Berry wrote:
~~~cut

---

From: Bo Berry <[email-masked]>
Date: Tue, 9 Oct 2012 18:18:14 -0400

>> Yes, that's what I'm advocating for. 

This sounds like a radio requirement. I do not think having a RLQ should be a prerequisite for a neighbor.  The radio should be able to report neighbor status by excluding the TLV.  For example, if I build one radio that constantly sends (hard codes) RLQ=100 and another radio that dynamically computes-reports RLQ and another radio that never sends RLQ (and the spectrums are compatible), DLEP should handle all.

Another metric, resources, is also a percentage (0-100).  What if a radio has no means to compute resources?  The radio should be able to exclude this TLV also, or simply report 100.  Again if I build a simple radio and hard code resources to 100, its compliant. 

Suggest these tlvs be optional or let the radio send 100.  I'm OK with an unknown value (255). 

The router obviously will need to handle the diff cases.

---

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 08:16:26 +0200

On 10/10/2012 12:18 AM, Bo Berry wrote:
> This sounds like a radio requirement. I do not think having a RLQ
> should be a prerequisite for a neighbor.  The radio should be able to
> report neighbor status by excluding the TLV.  For example, if I build
> one radio that constantly sends (hard codes) RLQ=100 and another
> radio that dynamically computes-reports RLQ and another radio that
> never sends RLQ (and the spectrums are compatible), DLEP should
> handle all.
>
> Another metric, resources, is also a percentage (0-100).  What if a
> radio has no means to compute resources?  The radio should be able to
> exclude this TLV also, or simply report 100.  Again if I build a
> simple radio and hard code resources to 100, its compliant.
>

As long this is well documented, the 255 value should be easy to handle.
If the local router does not want to deal with it, it just can drop the
TLV processing internally.

I think that is exactly what we have to work on through the whole draft.
It contains too many degrees of freedom which have to be interpreted, we 
need to specify the one that could create incompatible implementations.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 08:17:52 +0200

> TLS. So abstracting DLEP from the transport is good.
Having a ling list of options is bad for a proposed standard protocol. 
BTW, don't forget PGM/NORM and a random subset out of a long list 
of distributed databases.

No, lets define the standard for it, certainly for the loosely 
coupled scenario, based on IP (although using L2 link local protocol 
could be a good alternative).

I agree that DLEP could be reused for embedded radios, this 
needs more thoughts. Using IP inside an enclosure could be
an option. Or emulate IP and UDP/xxx. Would such a pluggable 
interface function as a bridge, i.e. router interface is ethernet? 
IMHO, this needs a separate document. Lets not solve all problems 
right now.

> may not.
Transfer of data has to be reliable. We cannot accept half 
functioning devices.

>  Some radios may be able to generate RLQ and some
> not.
Sure. Few TLVs should be mandatory. I suggest only one.

>  Some radios may want to use a broadcast/multicast for 
Yes. But it has to be reliable and risks on congestion is always
on the corner. I am quite experienced here. Also on limited
resources on LANs / HW.
> I'm OK with the current direction. 
I'm fine with our discussion. 

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 08:29:05 +0200

> TLS. So abstracting DLEP from the transport is good.

If we allow this (especially the pci part), we cannot use the IP/port 
tuple as a router/radio identification.

I see the reason for this (and one of the suggestions of the original 
DLEP proposal was to make it transport independent).

Can we maybe handle this with an OPTIONAL identification TLV of (at 
least) six bytes for both router and radio? The standard could define 
that in the absence of this tuples and the usage of IP/UDP, the IP/Port 
combination MUST be used as an id.

The problem is that with IPv6 we will have 18-bytes tuples for radio and 
for router (for a total of 36 bytes). Either we have to specify that 
this is a valid ID or we might break some router/radio implementations 
because they expect only 4 or 6 bytes.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 09:30:39 +0200

Some thoughts on how we may get out of some issues. If we use 
RFC 2119 SHOULD language for what is needed for a standard, 
we can accept modified implementations.

So we can say:
  o  And DLEP implementations SHOULD use UDP
  o  And DLEP implementations SHOULD use heartbeats
  o  And DLEP implementations SHOULD use ACK
etc.

If we think TCP is overkill (I can accept that), we can specify
each single packet (or message) SHOULD be ACKked. This provides
reliability and eliminates any congestion. Bulk transfer is slowed
down, but with sending updates only, this should not be a problem.
Startup message transfer would take a little bit longer, but might 
be faster than TCP in many cases.
An alternative for congestion avoidance would be rate limiting. This 
needs a parameter. Not my preference.

Teco

Op 10 okt. 2012, om 08:29 heeft Henning Rogge het volgende geschreven:

> If we allow this (especially the pci part), we cannot use the IP/port tuple as a router/radio identification.
> 
> I see the reason for this (and one of the suggestions of the original DLEP proposal was to make it transport independent).
> 
> Can we maybe handle this with an OPTIONAL identification TLV of (at least) six bytes for both router and radio? The standard could define that in the absence of this tuples and the usage of IP/UDP, the IP/Port combination MUST be used as an id.
> 
> The problem is that with IPv6 we will have 18-bytes tuples for radio and for router (for a total of 36 bytes). Either we have to specify that this is a valid ID or we might break some router/radio implementations because they expect only 4 or 6 bytes.
> 
> Henning Rogge
> 
> --

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 10:20:22 +0200

>    o  And DLEP implementations SHOULD use ACK

If ACK stays optional, we have to make sure this will not lead to 
starvation.

What happens if we have a Radio that supports ACKs (and expects them) 
but the Router does NOT?

Wouldn't the Radio wait for ACKs that will never arrive and maybe even 
terminate the session because of this?

> be faster than TCP in many cases.

Without a sequence number in the messages and ACKs we can only do "Stop 
and Wait", which means the Radio has to wait for the ACK before it can 
send a second message.

Henning Rogge

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 11:02:31 +0200

Op 10 okt. 2012, om 10:20 heeft Henning Rogge het volgende geschreven:

> If ACK stays optional, we have to make sure this will not lead to starvation.
It is not "we have to make sure".
The implementer of the protocol that does not implement 
the SHOULD must take care if this.

<e.g. heartbeat, restart connection/>

> 
> What happens if we have a Radio that supports ACKs (and expects them) but the Router does NOT?
The router vendor MUST solve this problem. We are done.

> 
> Wouldn't the Radio wait for ACKs that will never arrive and maybe even terminate the session because of this?
I don't care. I will not buy such a router.

> Without a sequence number in the messages and ACKs we can only do "Stop and Wait", which means the Radio has to wait for the ACK before it can send a second message.
Yes. This circumvents congestion.
If windowing is required, I suggest TCP.

I recommend sequence numbers in any case, this makes 
the protocol somewhat more robust. Also more easy to troubleshoot.

Teco

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 10 Oct 2012 11:04:34 +0200

>  o  And DLEP implementations SHOULD use ACK

Uhh, I am no great fan of SHOULD - it seems a cop-out, unless it is well argued under which circumstances and with which consequences one can deviate from the SHOULD.

Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go ;) 

> reliability and eliminates any congestion.

Not if it is a SHOULD; it may increase congestion (if someone does not ACK, for example, with an aggressive retransmission schedule).

My preference is a much much tighter specification than generous use of SHOULD.

Thomas

> Bulk transfer is slowed

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 11:08:07 +0200

> the SHOULD must take care if this.

This doesn't work if its not well specified how the protocol will handle 
this case.

> The router vendor MUST solve this problem. We are done.

The router vendor CAN NOT solve this problem, because the protocol does 
not specify how the radio will react.

> I don't care. I will not buy such a router.

If the protocol does not describe how interaction will work between an 
implementation supporting an optional feature and one NOT supporting it, 
the feature should not be optional.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 13:11:01 +0200

> Generally, most SHOULD SHOULD be MUST - or so I've heard the saying go ;) 

Yes, RFC 2119 does say something like that.
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I read this as that the implementer MUST do something to be compliant and takes full responsibility of all problems not fulfilling the requirement.

> Not if it is a SHOULD; it may increase congestion (if someone does not ACK, for example, with an aggressive retransmission schedule).

Again, blame and shame the implementer. And to be honest with you, I try to keep some distance with implementers that do not implement the SHOULD and do not take responsibility.

> My preference is a much much tighter specification than generous use of SHOULD.

Me too.

Teco

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 07:19:05 -0400

> The problem is that with IPv6 we will have 18-bytes tuples for radio and for router (for a total of 36 bytes). Either we have to specify that this is a valid ID or we might break some router/radio…

The driver will know how to discriminate and address the card.

---

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 13:23:14 +0200

On 10/10/2012 01:19 PM, Bo Berry wrote:
>> If we allow this (especially the pci part), we cannot use the
>> IP/port tuple as a router/radio identification.
>>
>> I see the reason for this (and one of the suggestions of the
>> original DLEP proposal was to make it transport independent).
>>
>> least) six bytes for both router and radio? The standard could
>> define that in the absence of this tuples and the usage of IP/UDP,
>> the IP/Port combination MUST be used as an id.
>>
>> The problem is that with IPv6 we will have 18-bytes tuples for
>> radio and for router (for a total of 36 bytes). Either we have to
>> specify that this is a valid ID or we might break some router/radio
>> implementations because they expect only 4 or 6 bytes.
>

We should at least mention in the DLEP document that the ID that 
determines the router/radio pair can be up to 36 bytes (when using IPv6).

An optional ID TLV for transports without addresses/ports could be 
smaller (still would like 6 bytes for radio and 6 bytes for router here).

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 07:25:01 -0400

On Oct 10, 2012, at 2:16 AM, Henning Rogge wrote:

> It contains too many degrees of freedom which have to be interpreted, we need to specify the one that could create incompatible implementations.

The degrees of freedom are important from my perspective/experiences. 
Radios tend to very tight on resource with specialized processing.  If
I build a new radio with DLEP in mind perhaps I would choose to 
implement all the features.  If I'm adopting an existing radio by
adding DLEP functionality, I may be able to support a minimum set 
of features. 

Adding DLEP to an 802.11 radio is much different that adding DLEP to
mi smart phone which is diff than adding DLEP to a specialized radio.

---

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 13:35:53 +0200

On 10/10/2012 01:25 PM, Bo Berry wrote:
>> I think that is exactly what we have to work on through the whole
>> draft. It contains too many degrees of freedom which have to be
>> interpreted, we need to specify the one that could create
>> incompatible implementations.
>
> The degrees of freedom are important from my
> perspective/experiences. Radios tend to very tight on resource with
> specialized processing.  If I build a new radio with DLEP in mind
> perhaps I would choose to implement all the features.  If I'm
> adopting an existing radio by adding DLEP functionality, I may be
> able to support a minimum set of features.

I don't want to remove all "degrees of freedom", I am just worried that 
some of them will break interoperability for DLEP. Restricting the 
number of working optional features is no problem, but if DLEP doesn't 
work at all because of a different set of optional features we forgot to 
put something important into the draft.

I think we are doing good work with the "radio metric" TLVs and the 
Discovery mechanism at the moment.

But I would really like to hear your opinion how the "optional ACK" 
mechanism will work.

Because DLEP Radio and DLEP Router will (most likely) come from 
different companies, these companies might choose to differently with 
the options. And they should be able to do so without breaking the basic 
protocol.

The case I worry about is a Radio company choosing to "support" ACKs 
(its expecting an ACK as a reply to its neighbor updates) and a Router 
company choosing not to support ACKs.

I think the combination of this two devices will break the basic 
protocol with the current specification.

> mi smart phone which is diff than adding DLEP to a specialized

I know.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 08:07:06 -0400

On Oct 10, 2012, at 7:35 AM, Henning Rogge wrote:

> I don't want to remove all "degrees of freedom", I am just worried that some of them will break interoperability for DLEP. Restricting the number of working optional features is no problem, but if DLEP doesn't work at all because of a different set of optional features we forgot to put something important into the draft.
> 
> I think we are doing good work with the "radio metric" TLVs and the Discovery mechanism at the moment.

Agree, a lot of good is happening!  Thanks for your points.

> But I would really like to hear your opinion how the "optional ACK" mechanism will work.
> 
> Because DLEP Radio and DLEP Router will (most likely) come from different companies, these companies might choose to differently with the options. And they should be able to do so without breaking the basic protocol.

exactly.  The ability to configure DLEP values (timeouts, retrys, etc) and enable/disable options will be key, for both the radio and the router.   A router implementation that offers greater degrees of freedom (to use the term above) would be better positioned to support a wider spectrum of radios.  

I'm not a fan of optional ACKs. It makes a messy spec and would be difficult support/sustain.  Through the WG, we've reduced the number of sessions and associated messages.  Agree we need to clarify various aspects and nail down a few features, but let's do so carefully with flexibility in mind and careful not to exclude opportunities.

I think DLEP is (and should be) a simple protocol, one that can be extended for new features.  

> 
> The case I worry about is a Radio company choosing to "support" ACKs (its expecting an ACK as a reply to its neighbor updates) and a Router company choosing not to support ACKs. 
> 
> I think the combination of this two devices will break the basic protocol with the current specification.
> 

---

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 14:14:23 +0200

On 10/10/2012 02:07 PM, Bo Berry wrote:
>> different companies, these companies might choose to differently
>> with the options. And they should be able to do so without breaking
>> the basic protocol.
>
> exactly.  The ability to configure DLEP values (timeouts, retrys,
> etc) and enable/disable options will be key, for both the radio and
> the router.   A router implementation that offers greater degrees of
> freedom (to use the term above) would be better positioned to support
> a wider spectrum of radios.
>
> I'm not a fan of optional ACKs. It makes a messy spec and would be
> difficult support/sustain.  Through the WG, we've reduced the number
> of sessions and associated messages.  Agree we need to clarify
> various aspects and nail down a few features, but let's do so
> carefully with flexibility in mind and careful not to exclude
> opportunities.

Yes.

DLEP should work as well on a 30$ 802.11 access point as on a 10000$+ 
multi-line software defined radio.

> extended for new features.

I see two "easy" ways out.

1.) the router has to tell the radio if it will reply with ACKs. If the 
radio supports ACKs too, the radio can adapt its strategy according to 
the information from the router.

2.) the router MUST produce ACKs, but the radio can choose to ignore them.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 14:24:12 +0200

Op 10 okt. 2012, om 14:14 heeft Henning Rogge het volgende geschreven:

> DLEP should work as well on a 30$ 802.11 access point as on a 10000$+ multi-line software defined radio.
> 
> 1.) the router has to tell the radio if it will reply with ACKs. If the radio supports ACKs too, the radio can adapt its strategy according to the information from the router.
> 

Or just implement the ACKs. That solves lots of problems.
(or the vtime mechanism as alternative option, with pros and cons).

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 14:26:46 +0200

On 10/10/2012 02:24 PM, Teco Boot wrote:
>> 1.) the router has to tell the radio if it will reply with ACKs. If
>> the radio supports ACKs too, the radio can adapt its strategy
>> according to the information from the router.
>>

This would be similar to option 2).

But you are right, make ACK handling (on radio AND router) mandatory 
would be a 3rd option.

> (or the vtime mechanism as alternative option, with pros and cons).

Yes. I still would prefer this solution, but it will be more work to 
modify the draft in this way.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 10 Oct 2012 15:04:29 +0200

> This would be similar to option 2).
Let the radio wait on ACK, or not, is very different.

If router wants to send data to radio, the protocol gets more complex. I lost the status on this, do we want to keep it?

> 
> But you are right, make ACK handling (on radio AND router) mandatory would be a 3rd option.
> 
> Yes. I still would prefer this solution, but it will be more work to modify the draft in this way.
The work is adjusting running and shipped code. The need for updating the draft cannot be a reason to get it right. I guess we have enough volunteers to help.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2012 15:07:46 +0200

> Let the radio wait on ACK, or not, is very different.

I was talking about "router sends ACK" and radio process it or ignores it.

> If router wants to send data to radio, the protocol gets more complex. I lost the status on this, do we want to keep it?

Ahh sorry, you are right...

had only thought about the "neighbor up/down" ACK, not about the Peer 
Terminate ACK.

(I think that are the only messages that have an ACK in the current DLEP 
draft)

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 09:19:44 -0400

I suggest we define the ACKs.  A radio implementation may choose
to ignore an ack is a specific case.  I'm OK with that.

So let's rally around defining the ACKS.

On Oct 10, 2012, at 9:07 AM, Henning Rogge wrote:

> had only thought about the "neighbor up/down" ACK, not about the Peer Terminate ACK.
> 
> (I think that are the only messages that have an ACK in the current DLEP draft)
> 
> Henning Rogge
> 
> -- 

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 10 Oct 2012 17:13:18 +0000

In the grandmother egg-sucking department, also what to do when ACKS don't come - retries, number, any backoff, etc. Are there any state issues?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Berry
Sent: 10 October 2012 14:20
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] Some comments on manet-dlep-03

---

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 13:26:27 -0400

> In the grandmother egg-sucking department, also what to do when ACKS don't come - retries, number, any backoff, etc. Are there any state issues?

yes, these should be explained, defined

---

---

From: "Powell III, Nelson" <[email-masked]>
Date: Thu, 11 Oct 2012 00:32:41 +0000

Bo,
   Sorry I'm a bit "late to the party" on this thread. I was thinking, if a radio does not have the channel capacity to support the messaging to determine RLQ to a distant station (e.g. narrowband waveforms that require serious optimization to push traffic), then a waveform design would automatically assume the RLQ is 100% for all transmissions.  Maybe that is a bit presumptuous on my part, but I would not want to assume less than 100% of a RLQ unless I could actually measure it.  
   Even if I could measure it, I would probably use discrete steps based on the waveforms capabilities, such as auto-rating. Even for auto-rating, IMO, it would make more sense to modify the Current Data Rate (CDR) rather than issue a change to the RLQ.  But my experience in the area is specific to certain frequency ranges, so maybe there is some cellular industry advantage I'm missing with the RLQ.
   That being said, I'm not opposed to RLQ; but would I assume RLQ=100% if the value cannot be derived by the radio device.  That would normalize any algorithm used to generate a routing protocol metric to the MDR and CDR.

Nelson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Berry
Sent: Tuesday, October 09, 2012 6:18 PM
To: Thomas Heide Clausen
Cc: Dearlove, Christopher (UK); [email-masked]; Stan Ratliff (sratliff)
Subject: Re: [manet] Some comments on manet-dlep-03

---

---

From: Bo Berry <[email-masked]>
Date: Wed, 10 Oct 2012 20:42:09 -0400

Hi Nelson
Thanks for the insights.  
-Bo

---

---

From: "Powell III, Nelson" <[email-masked]>
Date: Thu, 11 Oct 2012 00:42:21 +0000

Thomas,
   I agree, I prefer the use of MUST in the case of heartbeats and ACKs.  As a radio designer, if I decide to make the radio block on an ACK, that's my bad for not recognizing the possibility of a lost response.  The use of heartbeats and message timers allow for retries without the use of TCP.

Nelson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: Wednesday, October 10, 2012 5:05 AM
To: Teco Boot
Cc: [email-masked]; Bo Berry
Subject: Re: [manet] Some comments on manet-dlep-03

On Oct 10, 2012, at 9:30 AM, Teco Boot <[email-masked]> wrote:

> Some thoughts on how we may get out of some issues. If we use RFC 2119 
> SHOULD language for what is needed for a standard, we can accept 
> modified implementations.
> 
> So we can say:
>  o  And DLEP implementations SHOULD use UDP  o  And DLEP 
> implementations SHOULD use heartbeats  o  And DLEP implementations 
> SHOULD use ACK etc.
> 

> If we think TCP is overkill (I can accept that), we can specify each 
> single packet (or message) SHOULD be ACKked. This provides reliability 
> and eliminates any congestion.

Thomas

> Startup message transfer would take a little bit longer, but might be 
> faster than TCP in many cases.
>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
>> Germany

---

From: "Powell III, Nelson" <[email-masked]>
Date: Thu, 11 Oct 2012 00:44:08 +0000

I know the idea of the FSM is not popular, but if we have some event/transition strategy or FSM that drives the client and one for the server, err... radio and router, then we would be able to include session recovery.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Wednesday, October 10, 2012 5:08 AM
To: Teco Boot
Cc: [email-masked]; Bo Berry
Subject: Re: [manet] Some comments on manet-dlep-03

Am 10.10.2012 11:02, schrieb Teco Boot:
>>> Some thoughts on how we may get out of some issues. If we use RFC 
>>> 2119 SHOULD language for what is needed for a standard, we can 
>>> accept modified implementations.
>>>
>>> So we can say:
> The implementer of the protocol that does not implement the SHOULD 
> must take care if this.

This doesn't work if its not well specified how the protocol will handle this case.

> The router vendor MUST solve this problem. We are done.

The router vendor CAN NOT solve this problem, because the protocol does not specify how the radio will react.

> I don't care. I will not buy such a router.

If the protocol does not describe how interaction will work between an implementation supporting an optional feature and one NOT supporting it, the feature should not be optional.

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
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 09:29:17 +0200

> yes, these should be explained, defined

Even if we do not specify the retries/backoff-mechanism (they could be 
"implementation specific" variants), we must specify what happens if 
this mechanisms fail.

Even if its just a "drop connection, start from scratch". Otherwise the 
protocol is not in a defined state anymore.

I think we need at least something like this:

1) transport data to other side
2) if you succeed, go to step "okay"
3) "something happens here to compensate the loss"
4) if you succeed, go to step "okay"
5) go to step "fail"

We have defined step 1) and 2)... and I think we must also (at least) 
define step 4) and 5) in the specification.

Of course giving a good example how to handle a packet loss and state 
that every modification of the example must END in the same states (but 
not necessarily by doing the same steps) might be even better.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 09:34:33 +0200

On 10/11/2012 02:32 AM, Powell III, Nelson wrote:
> Bo, Sorry I'm a bit "late to the party" on this thread. I was
> thinking, if a radio does not have the channel capacity to support
> the messaging to determine RLQ to a distant station (e.g. narrowband
> waveforms that require serious optimization to push traffic), then a
> waveform design would automatically assume the RLQ is 100% for all
> transmissions.  Maybe that is a bit presumptuous on my part, but I
> would not want to assume less than 100% of a RLQ unless I could
> actually measure it. Even if I could measure it, I would probably use
> discrete steps based on the waveforms capabilities, such as
> auto-rating. Even for auto-rating, IMO, it would make more sense to
> modify the Current Data Rate (CDR) rather than issue a change to the
> RLQ.  But my experience in the area is specific to certain frequency
> ranges, so maybe there is some cellular industry advantage I'm
> missing with the RLQ. That being said, I'm not opposed to RLQ; but
> would I assume RLQ=100% if the value cannot be derived by the radio
> device.  That would normalize any algorithm used to generate a
> routing protocol metric to the MDR and CDR.

The main issue I have with this is that we are moving a decision on 
"network level" (how to handle bad/unknown links) to the radio.

The router can easily implement a configuration setting like "how to 
handle no RLQ/unknown RLQ" with options like "drop this links", 
"consider link perfect" or even "consider link as user-defined value X".

The "unknown = perfect" assumes that RLQ will be 100 for a "typical 
radio link", which might not be the case on some radios. In which case 
the DLEP specification would make the network to consider 
"non-measurable/unknown" links better than the typical ones.

I think we can do anything with the "special codepoint for unknown, no 
TLV for non-supported" RLQ TLV than we can do with the current 
specification. And we can sidestep some potential pit traps with it.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 10:08:23 +0200

On 10/11/2012 02:42 AM, Powell III, Nelson wrote:
> Thomas, I agree, I prefer the use of MUST in the case of heartbeats
> and ACKs.  As a radio designer, if I decide to make the radio block
> on an ACK, that's my bad for not recognizing the possibility of a
> lost response.  The use of heartbeats and message timers allow for
> retries without the use of TCP.

The current packet format of DLEP does not contain a sequence number. 
You cannot send a second packet before you received a successful ACK. 
You can just try to send the packet again or drop the connection.

But maybe you see yourself that the DLEP transport mechanism will get 
quite complex if we want to avoid all that problems.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 10:10:01 +0200

On 10/11/2012 02:44 AM, Powell III, Nelson wrote:
> I know the idea of the FSM is not popular, but if we have some
> event/transition strategy or FSM that drives the client and one for
> the server, err... radio and router, then we would be able to include
> session recovery.

But for this we will need a well-specified FSM. Otherwise the "recovery 
strategies" of one side might not fit to the receiver on the other side.

Even if a part of the strategy can be "implementation detail", the final 
states must be well defined.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 07:35:38 -0400

Henning,
I agree, we should add a seq number to the header, needed to support retries.

-Bo

On Oct 11, 2012, at 4:08 AM, Henning Rogge wrote:

> The current packet format of DLEP does not contain a sequence number. You cannot send a second packet before you received a successful ACK. You can just try to send the packet again or drop the connection.
> 
> But maybe you see yourself that the DLEP transport mechanism will get quite complex if we want to avoid all that problems.
> 
> Henning Rogge
> 
> -- 

---

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 07:40:07 -0400

On Oct 11, 2012, at 3:34 AM, Henning Rogge wrote:

> The main issue I have with this is that we are moving a decision on "network level" (how to handle bad/unknown links) to the radio.

No, not really.  The router can also use configuration, as you mention below, to handle optional features and metrics.  The router implementation and computing routing metrics for different routing protocols is out of scope for DLEP. 

> The router can easily implement a configuration setting like "how to handle no RLQ/unknown RLQ" with options like "drop this links", "consider link perfect" or even "consider link as user-defined value X".
> 
> The "unknown = perfect" assumes that RLQ will be 100 for a "typical radio link", which might not be the case on some radios. In which case the DLEP specification would make the network to consider "non-measurable/unknown" links better than the typical ones.
> 
> I think we can do anything with the "special codepoint for unknown, no TLV for non-supported" RLQ TLV than we can do with the current specification. And we can sidestep some potential pit traps with it.
> 
> Henning Rogge
> 
> -- 

---

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 13:41:49 +0200

> I agree, we should add a seq number to the header, needed to support retries.

If you only want to do "stop and wait", you do not need them... you just 
wait for the ACK before sending anything new.

On the other side, if you want "send multiple messages before receiving 
ACK" you need them both in the message header and in the ACKs TLVs.

And we will need to think about sliding windows.

And we need to consider that it cannot send out messages that depend on 
the context of another message that is still not ACKed.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 13:43:58 +0200

On 10/11/2012 01:40 PM, Bo Berry wrote:
> No, not really.  The router can also use configuration, as you
> mention below, to handle optional features and metrics.  The router
> implementation and computing routing metrics for different routing
> protocols is out of scope for DLEP.

If the Radio HIDES the difference between "perfect RLQ" and "unknown 
RLQ", the Router is unable to make this decision.

And I think most of us (including you) already agreed adding a "255 = 
unknown" codepoint (and allowing to leave out the whole TLV) is a better 
strategy than putting two things into the same encoding before.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 07:49:19 -0400

On Oct 11, 2012, at 7:43 AM, Henning Rogge wrote:

> If the Radio HIDES the difference between "perfect RLQ" and "unknown RLQ", the Router is unable to make this decision.

I said I'm OK with defining it.  But making use of it when computing a routing cost is a different matter.
The 'unknown' value would be discarded most likely.

> 
> And I think most of us (including you) already agreed adding a "255 = unknown" codepoint (and allowing to leave out the whole TLV) is a better strategy than putting two things into the same encoding before.
> 
> Henning Rogge
> 
> -- 

---

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 13:51:17 +0200

> The 'unknown' value would be discarded most likely.

As long as we make using this codepoint on the RADIO side mandatory this 
is fine.

As I said above, its a network/routing-layer decision how to interpret a 
"unknown RLQ" value... discarding it is a perfectly fine decision for 
the ROUTER.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 07:54:38 -0400

On Oct 11, 2012, at 7:51 AM, Henning Rogge wrote:

> As long as we make using this codepoint on the RADIO side mandatory this is fine.

I do not think this is necessary and do not think it should be mandatory.

> 
> As I said above, its a network/routing-layer decision how to interpret a "unknown RLQ" value... discarding it is a perfectly fine decision for the ROUTER.
> 
> Henning Rogge
> 
> -- 

---

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 14:12:16 +0200

On 10/11/2012 01:54 PM, Bo Berry wrote:
>>>>>> The main issue I have with this is that we are moving a
>>>>>> decision on "network level" (how to handle bad/unknown
>>>>>> links) to the radio.
>>>>>
>>>>> No, not really.  The router can also use configuration, as
>>>>> you mention below, to handle optional features and metrics.
>>>>> The router implementation and computing routing metrics for
>>>>> different routing protocols is out of scope for DLEP.
>>>>
>>>> If the Radio HIDES the difference between "perfect RLQ" and
>>>> "unknown RLQ", the Router is unable to make this decision.
>>>
>>> I said I'm OK with defining it.  But making use of it when
>>> computing a routing cost is a different matter. The 'unknown'
>>> value would be discarded most likely.
>>

I hope I do not misinterpret you, but I will try to summarize the two 
positions.

First, some radios want to publish an RLQ value, even when their 
algorithm couldn't measure one. This might make sense, depending on the 
method how the RLQ is calculated and how the linklayer works.

Second, some routers want to decide for themselves how they handle links 
with a RLQ which the radio cannot measure.

Maybe we can decouple this two things to get a good compromise (I think 
it was already proposed yesterday):

We allow the radio to publish any kind of RLQ it wants (even when 
incalculable), but we add a second byte (or just a bit?) information to 
the RLQ TLV, which contains a flag that tells the router if the RLQ 
value was measured or not.

With this the radio is able to suggest an RLQ value for unmeasurable 
links, but its still the routers implementation decision if the router 
accepts this value or not.

Do you think that could fit to both suggested use-cases?

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 08:25:40 -0400

On Oct 11, 2012, at 8:12 AM, Henning Rogge wrote:

> I hope I do not misinterpret you, but I will try to summarize the two positions.
> 
> First, some radios want to publish an RLQ value, even when their algorithm couldn't measure one. This might make sense, depending on the method how the RLQ is calculated and how the linklayer works.
> 
> Second, some routers want to decide for themselves how they handle links with a RLQ which the radio cannot measure.
> 
> Maybe we can decouple this two things to get a good compromise (I think it was already proposed yesterday):
> 
> We allow the radio to publish any kind of RLQ it wants (even when incalculable), but we add a second byte (or just a bit?) information to the RLQ TLV, which contains a flag that tells the router if the RLQ value was measured or not.
> 
> With this the radio is able to suggest an RLQ value for unmeasurable links, but its still the routers implementation decision if the router accepts this value or not.
> 

Why? Don't see the value. Just define the TLV as optional. I do not think we need to start defining flags.

I do not think we want to mandate a TLV transfer from a resource constrained (typically) radio that would indicate an unknown value.  While one radio may choose to generate TLVs with 100 or with 'unknown', another may not. 

The same shuold be applied to the Resource TLV, optional. 

Just because the radio sends a valid metric, does not imply it will be used in a routing cost. 

---

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Oct 2012 14:29:01 +0200

On 10/11/2012 02:25 PM, Bo Berry wrote:
>> algorithm couldn't measure one. This might make sense, depending on
>> the method how the RLQ is calculated and how the linklayer works.
>>
>> Second, some routers want to decide for themselves how they handle
>> links with a RLQ which the radio cannot measure.
>>
>> Maybe we can decouple this two things to get a good compromise (I
>> think it was already proposed yesterday):
>>
>> incalculable), but we add a second byte (or just a bit?)
>> information to the RLQ TLV, which contains a flag that tells the
>> router if the RLQ value was measured or not.
>>
>> With this the radio is able to suggest an RLQ value for
>> unmeasurable links, but its still the routers implementation
>> decision if the router accepts this value or not.
>>
> I do not think we want to mandate a TLV transfer from a resource
> constrained (typically) radio that would indicate an unknown value.
> While one radio may choose to generate TLVs with 100 or with
> 'unknown', another may not.
>

The point is that if we do as you suggest, the router will not know how 
to interpret the "100" value. A protocol like DLEP should not be 
ambiguous with its transmitted values, especially if the data has been 
available to the sender!

The radio does not know the need of the router, so it should not decide 
if it hides the "unknown" value from the router or not.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 11 Oct 2012 08:35:54 -0400

On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote:

> The point is that if we do as you suggest, the router will not know how to interpret the "100" value. A protocol like DLEP should not be ambiguous with its transmitted values, especially if the data has been available to the sender!

We can mandate the RLQ TLV and an unknown value.  A radio that cannot compute RLQ can hard code 100. Another radio hard codes unknown.  

Or make it optional.

Either way the router has to account for.  

Optional works for me.

> 
> The radio does not know the need of the router, so it should not decide if it hides the "unknown" value from the router or not.
> 
> Henning Rogge
> 
> -- 

---

---

From: "Powell III, Nelson" <[email-masked]>
Date: Thu, 11 Oct 2012 12:39:19 +0000

Bo,
   +1 to the optional approach.

I would rather the radio be able to inform the router that it cannot provide an RLQ and never send that TLV.  Could the session establishment procedures allow for enabling or disabling the use of TLV's like LCP does for PPP connections?

Nelson

-----Original Message-----
From: Bo Berry [mailto:[email-masked]] 
Sent: Thursday, October 11, 2012 8:36 AM
To: Henning Rogge
Cc: [email-masked]; Powell III, Nelson
Subject: Re: [manet] Some comments on manet-dlep-03

On Oct 11, 2012, at 8:29 AM, Henning Rogge wrote:

>>> incalculable), but we add a second byte (or just a bit?) information 
>>> to the RLQ TLV, which contains a flag that tells the router if the 
>>> RLQ value was measured or not.
>>> 
>>> links, but its still the routers implementation decision if the 
>>> router accepts this value or not.
>>> 

Or make it optional.

Optional works for me.

---

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Oct 2012 14:05:39 +0000

I've read the thread, trying to catch-up on the conversation. To be honest, I'm not sure where we're at, presently. 

I think there's consensus around making RLQ (and Latency, and Resources) OPTIONAL TLVs. As to reserving a code point for an RLQ value of "unknown", I don't think we have consensus. I for one am at a complete loss trying to understand the circumstances under which a router would get an "unknown" value, and what the router would actually do with it (other than ignore and discard it). Lastly, I'm still going to need someone to suggest some text as to how we explain this in the draft, to avoid the obvious questions after publication. 

My position (FWIW) is that we make RLQ, Resources, and Latency optional, and put some text in explaining to implementers that if they get in a situation where, for example, RLQ cannot be calculated (e.g. the "unknown" case), then simply don't send the TLV. 

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Thu, 11 Oct 2012 07:43:08 -0700

I don't understand the objection that we don't know yet what to do with code UNKNOWN. My understanding of the DLEP draft is it provides a way for radios to present information to the routers and routers to send requests to radios, and does not cover what the router does with those reports. It's entirely reasonable for the radio to throw out RLQ or latency reports because traffic doesn't care much about either.

It seems to odd to create an ambiguity for one particular codepoint that represents both an acceptable value (e.g., 100 or 0) and an unknown value. I agree that simply omitting the TLV is adequate, except in cases when the metric transitions from a known state to an unknown one. I think this is a corner case, but a corner case that's low-cost to resolve. Why not give as much information as possible to the router and let the smart guys who build routers figure out what they can do with it?

To be clear, I'm not trying to disallow the case that radios with no measurement simply omit the TLV.

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: Thursday, October 11, 2012 7:06 AM
To: Powell III, Nelson
Cc: [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Oct 2012 15:24:22 +0000

Again, my objection is purely based on the fat that I don't understand how/where/when/why this would be used. It's hard to insert even generic, "hand-waving" level text on something without at least having some notion of why it would be used. I keep asking for suggested text to explain, and I don't get a response. So, IF we get consensus on "unknown", my proposed text is: 

"Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ is supported, but not currently calculable. The authors have no idea under what circumstances this would occur. Routers receiving a value of RLQ_UNKNOWN are free to take any action deemed appropriate, including (but not limited to) ignoring the value, producing log messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the request of the working group, as consensus formed around the key ideas that this MAY allow for innovation, even though none of the working group members were able to note a set of circumstances under which this innovation might take place. So, in an effort to stop the email storm, the authors added the additional code point."

Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 11 Oct 2012 18:07:22 +0200

> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ is supported, but not currently calculable. The authors have no idea under what circumstances this would occur. Routers recei…

I did read more useful descriptions having the RLQ_UNKNOWN. If a radio did send something, but want to revoke it, there must be a mechanism for such. Without, the protocol is not complete.

With TLV, we can have Length=0. IMHO a better choice than RLQ_UNKNOWN.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Oct 2012 17:41:35 +0000

> With TLV, we can have Length=0. IMHO a better choice than RLQ_UNKNOWN.

My apologies for begin frustrated. It's simply that I'm in the position of documenting something that I don't understand. That makes it fairly difficult to explain. So, basically what I'm saying is "Tell me what you want this to say. I'll cut and paste your text into the document."

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Oct 2012 17:54:08 +0000

The above mentioned draft has been moved to Last Call status. This document has a 2-week last call period, ending on October 25, 2012. 

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Oct 2012 11:15:29 -0700

I am in favor of proceeding with the publication of this document. My
previous review of an earlier revision has been addressed. The document
retains important rationale that should be documented by the IETF.

Regards
Ulrich

On Thu, Oct 11, 2012 at 10:54 AM, Stan Ratliff (sratliff) <
[email-masked]> wrote:

> The above mentioned draft has been moved to Last Call status. This
> document has a 2-week last call period, ending on October 25, 2012.
>
> Regards,
> Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 12 Oct 2012 08:58:28 +0200

On 10/11/2012 07:41 PM, Stan Ratliff (sratliff) wrote:
> My apologies for begin frustrated. It's simply that I'm in the
> position of documenting something that I don't understand. That makes
> it fairly difficult to explain. So, basically what I'm saying is
> "Tell me what you want this to say. I'll cut and paste your text into
> the document."

Do you think you are the only one?

I thought we had a rough consensus with the "drop the RLQ TLV if you 
cannot measure the RLQ".

But then people began to argue "not supporting RLQ is different from 
incalculable RLQ". Thats what lead to the suggestion of the 
255=incalculable codepoint.

Some time later we got the argument that the radio still wants to push 
its "guessed" RLQ, even when it cannot calculate it. I talked with a 
co-worker and he suggested using an additional bit/byte as a flag, so we 
can support both use-cases (radio can always suggest RLQ, but mark it as 
'not measured' if necessary).

But that was "too complex".

I do not care which of the three solutions we take.

I just want a way to penalize links that have not been measured. Because 
non-measurable links (especially with "perfect link quality") degrade 
the routing metric to hopcount, which can be a disaster for adhoc networks.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 12 Oct 2012 09:20:39 +0200

Op 11 okt. 2012, om 19:41 heeft Stan Ratliff (sratliff) het volgende geschreven:

>>> It's hard to insert even generic, "hand-waving" level text
....
>  So, basically what I'm saying is "Tell me what you want this to say. I'll cut and paste your text into the document."

The UNKNOWN condition does not apply to RLQ only. Resources is somewhat equivalent. In fact all TLVs can be unknown, just after Neighbor Up and no optional TLVs, and no info from peer. Also, the protocol is not complete if there is no way to get back to a previous state of the information base.
I straightforward solution is to have a method to revoke everything that is send before. Length=0 or the existing drop indicator. Text would be:

   Length      - (the value for TLV with info)
                 A zero length can be used to revoke previous provided information for this Data Item TLV.

This could also be used to override the peer provided defaults.

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Oct 2012 09:53:59 +0200

+1

It is an excellent draft/work, I support the draft and your process.
Thanks to all: authors, you and the WG,

AB

On 10/11/12, Stan Ratliff (sratliff) <[email-masked]> wrote:
> The above mentioned draft has been moved to Last Call status. This document
> has a 2-week last call period, ending on October 25, 2012.
>
> Regards,
> Stan

---

From: Teco Boot <[email-masked]>
Date: Fri, 12 Oct 2012 09:56:42 +0200

Another somewhat old discussion on DLEP (August 11th 2010):

>>>>>>>>> Another topic is the choice on which side of a link gets what information.
>>>>>>>>> Draft-dearlove-olsrv2-metrics proposes the routing protocol instance gets
>>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take care of metric
>>>>>>>>> transfer to TC originator. Other protocols work otherwise (e.g the
>>>>>>>>> OSPF-MANET family). There, in case of asymmetric metrics, it is assumed that
>>>>>>>>> the radios would run another (L2 or L3) protocol for metric transfer, if
>>>>>>>>> needed. Are asymmetric metrics supported, and if so, what model is proposed?
>>>>>> 
>>>>>> I believe the DLEP draft would support asymmetric links -- at least links where bi-directional connectivity exists, though potentially at different speeds. This is analogous to RFC 5778 operation. In RFC 5778, each side of a connection gets metrics that represent the ability of that side to send to the partner. If one side runs at a slower speed than the other, different "send metrics" are reported to the respective routers.
>>>>> 
>>>>> I think it is important to specify the semantics of the provided metrics. For what direction does this data apply?
>>>>> OSPF-MANET and OLSR have different requirements here: OSPF requires outbound direction, OLSR inbound.
>>>>> Maybe DLEP could support both models, and mode is negotiated.
>>>>> 
>>>> 
>>>> OK, what if we changed the metric packet to include both inbound and outbound bandwidth? That way, no negotiation would be required, and the routing protocol could select the data it needs.
>>> If information is available, it can be provided without high costs.
>>> If it is optionally available, e.g. it requires transfer over the radio, it should be made available only if needed.
>>> This can be configuration or negotiation. 
>>> 
>>> It is not only bandwidth, it applies to other metrics also. Maybe the whole set. 
>> 
>> I'm OK with this. Are there other opinions on the list?
> 
> Look in the IEEE 802.16 specification.  Table 14 (in Chapter 6 of the
> -2004 version I have) contains the roughly four dozen MAC messages that
> control the network segment.  Many of the variables trafficked here are
> reflected one way or another in the MIB.  
> 
> Is not what your asking for is some way to reflect some of this data up
> to layer 3?

I don't think the draft was updated to reflect the outcome of this discussion.
@Stan: is there a follow-up?

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Oct 2012 10:00:22 +0200

+1

AB

On 10/12/12, Teco Boot <[email-masked]> wrote:
>>  So, basically what I'm saying is "Tell me what you want this to say. I'll
>> cut and paste your text into the document."
>
>
> The UNKNOWN condition does not apply to RLQ only. Resources is somewhat
> equivalent. In fact all TLVs can be unknown, just after Neighbor Up and no
> optional TLVs, and no info from peer. Also, the protocol is not complete if
> there is no way to get back to a previous state of the information base.
> I straightforward solution is to have a method to revoke everything that is
> send before. Length=0 or the existing drop indicator. Text would be:
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Oct 2012 10:04:30 +0200

Thanks for this reminder,

I think there is no much follow up, because many say they are bussy
with other work, but I recommend we all follow up together for the
best of our WG drafts. I remember giving some feedback on dlep but not
put in as well, however, always reminders are important :)

AB

On 10/12/12, Teco Boot <[email-masked]> wrote:
>>>>>>> I believe the DLEP draft would support asymmetric links -- at least
>>>>>>> links where bi-directional connectivity exists, though potentially at
>>>>>>> different speeds. This is analogous to RFC 5778 operation. In RFC
>>>>>>> 5778, each side of a connection gets metrics that represent the
>>>>>>> ability of that side to send to the partner. If one side runs at a
>>>>>>> slower speed than the other, different "send metrics" are reported to
>>>>>>> the respective routers.
>>>>>>
>>>>>> I think it is important to specify the semantics of the provided
>>>>>> metrics. For what direction does this data apply?
>>>>> OK, what if we changed the metric packet to include both inbound and
>>>>> outbound bandwidth? That way, no negotiation would be required, and the
>>>>> routing protocol could select the data it needs.
>>>> If it is optionally available, e.g. it requires transfer over the radio,
>>>> it should be made available only if needed.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 12 Oct 2012 10:09:26 +0200

> Thanks to all: authors, you and the WG,

The document will be a great help as a pointer for people who still 
arguing the use of link metrics. Good to see it here.

Henning Rogge

---

From: Christoph Barz <[email-masked]>
Date: Fri, 12 Oct 2012 11:21:08 +0200

Dear Nelson,
> I would rather the radio be able to inform the router that it cannot provide an RLQ and never send that TLV.  Could the session establishment procedures allow for enabling or disabling the use of T…

+1
If we want to got towards a session oriented approch, having the radio
and router exchange their capabilities could make many things easier.
This would not only include enabling or disabling TLVs. It could also
include other protocol mechanisms like acknowledgements. In the end,
it could also help regarding problem diagnosis and to identify
supported features regarding special radio and router combinations.

Best regards
Christoph

---

From: Bo Berry <[email-masked]>
Date: Fri, 12 Oct 2012 07:34:21 -0400

> put in as well, however, always reminders are important :)

Making a suggestion does not mean the suggestion is automatically added
to the draft.  The suggestion needs consensus and agreement. 

---

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 12 Oct 2012 14:01:41 +0000

On Oct 12, 2012, at 3:20 AM, Teco Boot wrote:

> I straightforward solution is to have a method to revoke everything that is send before.

That depends on how you define "everything that is sent before". If, for instance, this was the 10th metric update, are you talking about rolling back to the 9th update? If so, I'm opposed. That's a huge burden on the router. If you're talking about clearing out a metric value and setting it to some defined value, like the router's defaults, then I'm OK with that. 

> Length=0 or the existing drop indicator. Text would be:
> 

Overriding the defaults makes no sense to me. 

Stan

---

From: Bo Berry <[email-masked]>
Date: Fri, 12 Oct 2012 10:20:08 -0400

Teco,
I'm trying to understand, but having trouble. Are we talking about rolling back metrics to a previous state?
If so, the radio can simply send a new set of metrics.  Using metrics from some time back makes no sense to me and computing/making a routing change with old data seems dangerous. How much history does the router keep?  

Help me understand.

-Bo

---

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Oct 2012 15:27:17 +0100

> to the draft.  The suggestion needs consensus and agreement.
Hi Bo,

That is not always true, IF the authors made  mistake, THEN there SHOULD be
no need for consensus,
we are engineers and we need to be reasonable,

I suggested before the correct the mistake in page 4 draft-02>
*the Data Link Exchange Protocol, or DLEP* To be *Dynamic Link Exchange
Protocol, or DLEP*

But its still wrong name and was not corrected in draft-03, another
participant has repeated my request, and hope the authors follw up.
Any suggestion by a participant SHOULD be followed up by all participants,
including editors and Chair, if no reply from any, the input SHOULD be
respected and taken, otherwise we are waisting time and efforts here.

AB

> >>>>>>>>>>> the L2 metrics for incoming side of links, OLSR/NHDP take care
> of
> >>>>>>>>>>> metric
> >>>>>>>>>>> needed. Are asymmetric metrics supported, and if so, what
> model is
> >>>>>>>>>>> proposed?
> >>>>>>>>

---

From: Teco Boot <[email-masked]>
Date: Fri, 12 Oct 2012 17:31:24 +0200

> I'm trying to understand, but having trouble. Are we talking about rolling back metrics to a previous state?
I did not have "roll back to a previous state, please" in mind.

> If so, the radio can simply send a new set of metrics.  Using metrics from some time back makes no sense to me and computing/making a routing change with old data seems dangerous. How much history…
None. Radio is responsible to get the information bases on radio and router in sync.

> Help me understand.
Example scenario, with minimal exchanged data:
  Radio sends Peer Discovery, ID only
  Router sends Peer Offer, ID only
  Radio sends Peer Offer Ack, ID and Status   
  Radio sends Neighbor Up, ID and MAC.
  Router sends Neighbor Up Ack, ID and MAC
Now, there is no RLQ for that neighbor in the information base in the router.
  Radio sends Neighbor Update, ID, MAC and RLQ.
  (Router should send Neighbor Update Ack, ID and MAC)
Now, we have the RLQ.

By some magic, the RLQ becomes invalid. Could be antenna switch, modulation switch or even an RF engine switch.
Assume neighbor does not go into down state.
How can the radio send a message to the router that the RLQ is in UNKNOW state again, just as right after the UP state?

This can happen with 802.11 CDR. The routing hello protocol detects symmetrical connectivity. Until there is some unicast traffic, data rate is unknown. The DLEP radio may start providing CDR after adaptive rate selection. It may want to revoke stale information.
I do not say an 802.11 radio should behave like this.

Teco

---

From: Bo Berry <[email-masked]>
Date: Fri, 12 Oct 2012 13:38:52 -0400

Hi Teco, thanks for the clarification.  Discussion in-line.
-Bo

> How can the radio send a message to the router that the RLQ is in UNKNOW state again, just as right after the UP state?

No magic here, metrics constantly change. The rate that the radio reports metrics will depend upon the design, some may report at periodic intervals some may be event driven.  In any case, it is important for the radio to provide heuristics that dampen the rate of metric updates, such as crossing thresholds or percent change from previous.  For example, a radio may calculate metrics every 100ms.  Each epoch the metrics are filtered through the heuristics, if conditions merit, the update is sent. 

The router calculates an updated route cost upon receiving the metrics.  The effect of the newly computed route cost is run through heuristics so not to over drive route/link cost updates.  Of course the cost calculation and the heuristics are unique per routing protocol.  For example, the newly calculated link cost could be compared to the current, if conditions merit, the new link cost is inserted from which the routing protocol floods/updates.

Since the raw data for calculating metrics is in the radio, the radio should send a new neighbor update with the new calculations.  If the RLQ is no longer valid other parameters will be changing.  

Similar fashion, the radio heuristics to determine the presence of a new neighbor from which a neighbor up is generated will be important.  So to the radio heuristics when deciding to generate the neighbor down.

Typing this response does help me understand your perspective.  Between sending a new update message to indicate a single metric is no longer valid and back-up, compared to a new set of metrics, I'd rather have the most current metrics.

---

---

From: Teco Boot <[email-masked]>
Date: Fri, 12 Oct 2012 19:58:14 +0200

> Typing this response does help me understand your perspective.  Between sending a new update message to indicate a single metric is no longer valid and back-up, compared to a new set of metrics, I'…

I don't follow. Do you suggest the router should keep using the now outdated metrics, for as long as the radio cannot provide an information element?

State_1: router calculated metric_1, RLQ was not available
State_2: router calculated metric_2, RLQ was available
State_3: RLQ is not available, router cannot calculate a metric

My opinion: in state_3, router has to be able to calculate a metric_3 which would be equal to metric_1. Keep using metric_2 is wrong.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 12 Oct 2012 18:02:23 +0000

> My opinion: in state_3, router has to be able to calculate a metric_3 which would be equal to metric_1. Keep using metric_2 is wrong.

Specifically for the case of RLQ, do you expect the router's metric for "RLQ not available" to be different from "RLQ = 0"? If so, why? 

Stan

---

From: Teco Boot <[email-masked]>
Date: Sat, 13 Oct 2012 10:02:58 +0200

> Specifically for the case of RLQ, do you expect the router's metric for "RLQ not available" to be different from "RLQ = 0"? If so, why? 

My point is that the DLEP protocol should be "complete", in that the radio is able to get the router in a certain state, in another state and get back in the earlier state. RLQ is just an example.

If you think this makes no sense with the radios you have seen up to now, you could be right. Tomorrow, you could have a different opinion. I saw on this mailing list some of us see already the requirement the protocol shall be "complete".

Teco

---

From: Bo Berry <[email-masked]>
Date: Sat, 13 Oct 2012 07:29:21 -0400

> If you think this makes no sense with the radios you have seen up to now, you could be right. Tomorrow, you could have a different opinion. I saw on this mailing list some of us see already the req…

This makes no sense to me, and I do not agree that the radio should be able to get the router into a certain state.  If we talking metrics, the radio should send the latest metrics as routers probably do not maintain a cache of previous metrics.  If there becomes a new requirement, we can extend the protocol once we understand the details.

---

From: Teco Boot <[email-masked]>
Date: Sat, 13 Oct 2012 13:47:49 +0200

Op 13 okt. 2012, om 13:29 heeft Bo Berry het volgende geschreven:

> This makes no sense to me, and I do not agree that the radio should be able to get the router into a certain state.  If we talking metrics, the radio should send the latest metrics as routers probably do not maintain a cache of previous metrics.
Did you read my clarification? I don't think so. I never suggested a router would have such a cache.

>  If there becomes a new requirement, we can extend the protocol once we understand the details. 
It is not new. Others came with it and I do support this *current* requirement. I made it more general, as I say optional Data Item TLVs are truly optional. They can come and they can go. The discussion is on how they go.

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 13 Oct 2012 14:02:06 +0200

I agree we should design for the present MANET technologies and
future, for the protocol completion. Do you mean router-state as the
DLEP-server state? IF yes THEN I agree with you. IF not THEN, I Don't
understand why we need to consider router states.

DLEP considers the session between server and client states, other
states are not inscope. For simplicity, DLEP should be abstract from
MANET-Router's (OLSRv2 or AODVv2) states, decisions or processes, an
optional future interaction may be useful but complicated (will need
RFC5444).

AB

On 10/13/12, Teco Boot <[email-masked]> wrote:
My point is that the DLEP protocol should be "complete", in that the
radio is able to get the router in a certain state, in another state
and get back in the earlier state. RLQ is just an example.

If you think this makes no sense with the radios you have seen up to
now, you could be right. Tomorrow, you could have a different opinion.
I saw on this mailing list some of us see already the requirement the
protocol shall be "complete".

---

From: Teco Boot <[email-masked]>
Date: Sat, 13 Oct 2012 15:14:16 +0200

DLEP is (mainly) getting the neighbor information base from radio to 
router, as accurate as possible. It is up to the router to use this for
route calculation.

This discussion is not about using RFC 5444. 

It is about transfer of "hey there, I don't have this info anymore". 
Bo and Stan say, this is not needed. Others say, there is a need for it. 
I agree with the others, because I cannot see a reason a radio is only 
allowed *once* during neighbor_up state to miss data items. We better 
prepare for data items that can fall back to unknown. I say: let's allow
this for all optional data items.

Teco

---

From: Bo Berry <[email-masked]>
Date: Sat, 13 Oct 2012 10:26:26 -0400

Teco,
I do not understand it and it's not been described in a manner
that I can.  But if we can not understand it, we will not be 
successful describing it such that it can be useful. 

If you can provide meaningful, descriptive text, that would help.  
At this time, "prepare for data items that can fall back to unknown"
does not help me.  What do you propose as optional data items
and how do you propose, by what mechanism, they fall back?  Do
they fall back in the radio or router, or both?

-Bo

---

From: Teco Boot <[email-masked]>
Date: Sat, 13 Oct 2012 16:50:50 +0200

> they fall back in the radio or router, or both?

The optional Data Item TLVs for Neighbor Up are in the draft:
              - IPv4 Address
              - IPv6 Address
              - Maximum Data Rate
              - Current Data Rate
              - Latency
              - Expected Forwarding Time
              - Resources 
              - Relative Link Factor
              - Credit Window Status
Neighbor Up messages would be send by router, although the draft
mentions the router can send it also.
Relative Link Factor should be Relative Link Quality (posted before, 
I think). In Neighbor Update, Expected Forwarding Time is missing.

My comment is on the protocol. Optional data item TLVs can be present,
or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ.
I don't see much difference in UNKNOWN and not sending the TLV. Then,
this UNKNOWN applies to all optional Data Item TLVs. So if we just
add a mechanism that enables sending UNKNOWN for all optional Data 
Item TLVs, we are done. Addresses have the drop already. The other
TLVs can have the length=0. That's all. I provided the text already.

I can't be more clear. Sorry.

Teco

---

From: Bo Berry <[email-masked]>
Date: Sat, 13 Oct 2012 11:06:55 -0400

Teco
Thanks, this helps.  So let's see what others think.  
Have a great wkend.

-Bo

---

From: Henning Rogge <[email-masked]>
Date: Sun, 14 Oct 2012 12:01:06 +0200

I think the idea is not bad.

IF we decide to use a special codepoint for "unknown TLV value", using
"length = 0" would give us a generic way for doing it for all kind of
additional metric TLVs... instead of doing this "what to use for
UNKNOWN" brainstorming again.

It also makes it easier to include the UNKNOWN codepoint into metrics
which have no bits/values left.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 14 Oct 2012 13:32:51 +0100

+1 support to the below input,

and without any router state reflect on dlep-server.

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 15 Oct 2012 00:08:30 +0000

Stan

---

From: Teco Boot <[email-masked]>
Date: Mon, 15 Oct 2012 07:27:01 +0200

The -03 version only requires the MAC for neighbors. Other data items are optional. The router should be happy with only having required data items. The more there is, the happier the router will be. A router that is connected to a DLEP RFC compliant radio, getting little info, should not act as crazy as you described. I would say:

In general, when a router has received information that a neighbor is up, it should send out hello messages to make sure the link to that neighbor is bi-directional. If so, the link can be added in the routing topology. The router may calculate link metrics for that link, based on the DLEP provided data items. The router may use other information for link metric calculation.
(no capitals here)

I suggested a number of times (>3) a single dynamic, mandatory link metric. Could be RLQ. But I prefer a wider precision. 0-100 scale is OK, which is functionally equivalent to 0-255 or 0-(2^24-1). Having a mandatory fixed MDR at peer discovery (or Neigbor Up) would be OK also. This would be a way-out of your fear for burning routers.

Henning suggested improved up/down state signals, so the router can learn form radio that link is bi-directional. This would speed up getting the L3 link up. Router may set link on two-way if radio says so.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Mon, 15 Oct 2012 07:39:54 +0200

>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where RLQ is supported, but not currently calculable. The authors have no idea under what circumstances this would occur. Routers rece…

If we use Teco's suggested solution (using 'length = 0' to make an 
unknown but supported TLV):

----
Radio implementations MAY use a metric TLV without value and length 0 to 
signal a not measurable but supported TLV.

Most router implementations will process this metric TLV in the same way 
as a missing metric TLV.
----

The "will" in the second sentence could also be a "SHOULD" or "MAY", I 
am not sure about this.

"Metric TLV" would be a list of all DLEP TLVs that transport a metric 
value like RLQ, delay, current/maximum link speed, ...

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Mon, 15 Oct 2012 07:32:31 -0400

On Oct 15, 2012, at 1:39 AM, Henning Rogge wrote:

> If we use Teco's suggested solution (using 'length = 0' to make an unknown but supported TLV):
> 
> ----
> Radio implementations MAY use a metric TLV without value and length 0 to signal a not measurable but supported TLV.
> 
> Most router implementations will process this metric TLV in the same way as a missing metric TLV.
> ----
> 
> The "will" in the second sentence could also be a "SHOULD" or "MAY", I am not sure about this.
> 
> "Metric TLV" would be a list of all DLEP TLVs that transport a metric value like RLQ, delay, current/maximum link speed, ...
> 

For my clarity, the proposal above only applies to metrics.  Not credits or other TLVs.

I understand the proposal to use 0-length but I'm still not understanding the value.
If I'm developing the radio code to send the metrics, why send a 0-length
TLV when the TLV can be omitted?  This adds test vectors to be verified for no
or little value. 

Taking the extreme of the proposal the radio can send a Neighbor Up filled with 
0-length TLVs which would have no value or purpose from a router's perspective.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 15 Oct 2012 13:44:07 +0200

> For my clarity, the proposal above only applies to metrics.  Not credits or other TLVs.
Yes, I think so.

> 0-length TLVs which would have no value or purpose from a router's perspective.

As I wrote in my mail to Stan, I am primarily interested in getting the 
fact that a router cannot calculate or support a TLV like RLQ. I 
personally do not care about the difference of both, so I would be okay 
with a "if RLQ is not calculable or supported, the radio MUST not 
include the RLQ TLV into the message". This "RLQ=100 for non-measurable 
links" as in PPPoE is a disaster for Adhoc networks.

But people argued that the difference between "not supported" and "not 
calculable" is important... thats where the discussion about "additional 
encoding for non-calculable" started.

Maybe it would be a cleaner way to look into the proposal of Powell Ill 
and Christoph Barz to give the radio a way to tell the router what 
things it supports (in the discovery message?). This would allow us to 
drop this "length 0/value=255" thing for RLQs, because the Radio could 
just drop the TLV if it cannot calculate it.

Henning Rogge

---

From: "Duke, Martin" <[email-masked]>
Date: Mon, 15 Oct 2012 07:10:40 -0700

The reason I haven't responded to this request is because I haven't been able to find anywhere in the draft that instructs the router on how to handle ANY of these metrics- RLQ, Latency, whatever. In fact, I thought the way the router used information about the radio was out of scope for this draft.

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: Sunday, October 14, 2012 5:09 PM
To: Henning Rogge
Cc: [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

Stan

On Oct 14, 2012, at 6:01 AM, Henning Rogge wrote:

>>>> I do not understand it and it's not been described in a manner that 
>>>> I can.  But if we can not understand it, we will not be successful 
>>>> describing it such that it can be useful.
>>>> 
>>>> does not help me.  What do you propose as optional data items and 
>>>> how do you propose, by what mechanism, they fall back?  Do they 
>>>> fall back in the radio or router, or both?
>>> 
>>> My comment is on the protocol. Optional data item TLVs can be 
>>> present, or not. There was a proposal for TLV with an UNKNOWN codepoint, for RLQ.
>>> I don't see much difference in UNKNOWN and not sending the TLV. 
>>> Then, this UNKNOWN applies to all optional Data Item TLVs. So if we 
>>> just add a mechanism that enables sending UNKNOWN for all optional 
>>> Data Item TLVs, we are done. Addresses have the drop already. The 
>>> other TLVs can have the length=0. That's all. I provided the text already.
>>> 
>>>>> DLEP is (mainly) getting the neighbor information base from radio 
>>>>> to router, as accurate as possible. It is up to the router to use 
>>>>> this for route calculation.
>>>>> 
>>>>> I agree with the others, because I cannot see a reason a radio is 
>>>>> only allowed *once* during neighbor_up state to miss data items. 
>>>>> We better prepare for data items that can fall back to unknown. I 
>>>>> say: let's allow this for all optional data items.
>>>>> 
>>>>> Teco
>>>>> 
>>>>> 
>>>>>> future, for the protocol completion. Do you mean router-state as 
>>>>>> the DLEP-server state? IF yes THEN I agree with you. IF not THEN, 
>>>>>> I Don't understand why we need to consider router states.
>>>>>> 
>>>>>> DLEP considers the session between server and client states, 
>>>>>> other states are not inscope. For simplicity, DLEP should be 
>>>>>> abstract from MANET-Router's (OLSRv2 or AODVv2) states, decisions 
>>>>>> or processes, an optional future interaction may be useful but 
>>>>>> complicated (will need RFC5444).
>>>>>> 
>>>>>> AB
>>>>>> 
>>>>>> My point is that the DLEP protocol should be "complete", in that 
>>>>>> the radio is able to get the router in a certain state, in 
>>>>>> another state and get back in the earlier state. RLQ is just an example.
>>>>>> 
>>>>>> If you think this makes no sense with the radios you have seen up 
>>>>>> to now, you could be right. Tomorrow, you could have a different opinion.
>>>>>> I saw on this mailing list some of us see already the requirement 
>>>>>> the protocol shall be "complete".
>>>>> 
>>>> 
>>> 
>>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 15 Oct 2012 16:12:33 +0200

> The reason I haven't responded to this request is because I haven't been able to find anywhere in the draft that instructs the router on how to handle ANY of these metrics- RLQ, Latency, whatever.…

I still think we need rules how the RADIO side produce the
information. Otherwise the router will not be sure what the
information means.

Henning Rogge

---

From: "Goff, Thomas" <[email-masked]>
Date: Tue, 16 Oct 2012 12:34:58 -0700

Just a couple of comments inline below.

  Tom

> Sent: Monday, October 15, 2012 4:33 AM
> To: Henning Rogge
> Cc: [email-masked]
 
> >> I've asked twice now (this email makes attempt number 3) for someone
> to suggest some text to clarify what a router or modem would do with an
> UNKNOWN metric. So far, what I've seen is a potentially new *way* of
> specifying UNKNOWN - one that makes more sense than picking some
> arbitrary code point. But no actual text to suggest what either of the
> endpoints would *do* with the data. Maybe I'm old, feeble, and not very
> bright - but I'm looking for suggestions that start with "A router
> receiving a metric value of UNKNOWN MUST." or "An implementation
> receiving an UNKNOWN indication SHOULD." or something along those
> lines. Barring that, the only text I've got to insert is what I
> suggested before:
> >>>
> >>> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where
> RLQ is supported, but not currently calculable. The authors have no
> idea under what circumstances this would occur. Routers receiving a
> value of RLQ_UNKNOWN are free to take any action deemed appropriate,
> including (but not limited to) ignoring the value, producing log
> messages, or bursting into flames. The RLQ_UNKNOWN (TBD) value was
> added at the request of the working group, as consensus formed around
> the key ideas that this MAY allow for innovation, even though none of
> the working group members were able to note a set of circumstances
> under which this innovation might take place. So, in an effort to stop
> the email storm, the authors added the additional code point."
> >
> > Radio implementations MAY use a metric TLV without value and length 0
> to signal a not measurable but supported TLV.
> >

I would suggest that a TLV of length 0 could simply invalidate a previously sent (optional) value without implying anything about measurability.

> TLV when the TLV can be omitted?  This adds test vectors to be verified

Maybe I'm missing something here, but it seems to me that this depends on if you assume a complete set of metrics is sent with each neighbor update.  If so then there's no ambiguity when an optional TLV is missing.  Is this implied by Section 22?

If neighbor updates can contain incremental changes to optional items then having a way to invalidate previous values could be useful.

---

From: Teco Boot <[email-masked]>
Date: Tue, 16 Oct 2012 22:40:40 +0200

> Maybe I'm missing something here, but it seems to me that this depends on if you assume a complete set of metrics is sent with each neighbor update.  If so then there's no ambiguity when an optiona…

I did not read it that way. If we go for this alternative, we can skip the add/drop indicator in address TLVs. A mix of two mechanisms sounds crazy to me.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 17 Oct 2012 17:04:52 +0000

> I did not read it that way. If we go for this alternative, we can skip the add/drop indicator in address TLVs. A mix of two mechanisms sounds crazy to me.

In either event, I don't think we can skip the add/drop indicator in address TLVs. It is possible for an interface to have multiple IP addresses of the same family (IPv4 or IPv6) assigned, so merely sending a 0-length TLV would be ambiguous. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Oct 2012 19:22:44 +0200

> In either event, I don't think we can skip the add/drop indicator in address TLVs. It is possible for an interface to have multiple IP addresses of the same family (IPv4 or IPv6) assigned, so merel…
Sure.
I ment that if I read that with each Neighbor Update, all Data Item TLVs MUST be send, the drop is not needed. I did not read such a requirement, so the radio just send actual updates. 
This update mechanism has the add, modify and delete operators. The address TLVs have such operator, add/drop is enough. For the others, length can be used. Length!=0 is add (did not exists before) or modify (the existing data object). Delete was missing and I suggested the Length=0.

If we have fixed this, there is the discussion on the peer defaults. I think that we better skip this function, then we don't have to describe how to handle late add, modify and delete operators of those defaults.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 17 Oct 2012 17:27:12 +0000

On Oct 17, 2012, at 1:22 PM, Teco Boot wrote:

> I ment that if I read that with each Neighbor Update, all Data Item TLVs MUST be send, the drop is not needed.

That hasn't been the intent with DLEP to this point. I've always assumed a "send only the changed data" model of operation. Now that I say that, I guess there was a discussion about sending all TLVs in some sort of "session-less" mode of operation, but that's gone by the wayside.

Regards,
Stan

> I did not read such a requirement, so the radio just send actual updates.

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Oct 2012 19:58:25 +0200

Op 17 okt. 2012, om 19:27 heeft Stan Ratliff (sratliff) het volgende geschreven:

> That hasn't been the intent with DLEP to this point. I've always assumed a "send only the changed data" model of operation.
You make this clear in -04, right?

Teco

> Now that I say that, I guess there was a discussion about sending all TLVs in some sort of "session-less" mode of operation, but that's gone by the wayside.
> 
> Regards,
> Stan
> 
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 17 Oct 2012 18:08:10 +0000

> You make this clear in -04, right?

Sigh… I thought it already was. ;-) I'll make a run at it, but as before, suggest some text. 

Stan

---

From: "Dowdell, John" <[email-masked]>
Date: Tue, 23 Oct 2012 14:23:11 +0100

Stan et al

Some thoughts on why we might want a metric value of UNKNOWN instead of
just not sending one.

Suppose we have a network device which supports the reporting of certain
metrics. Those metrics for which values are not reported are simply
never sent (or actually I would rather the device declared that those
were unsupported but that is another discussion entirely). On occasion,
perhaps when the device is re-synchronising its connection to the
network in some manner, or is waiting for a central scheduler to perform
some action (e.g. for beyond line of sight hub and spoke communications
devices), one or more metric values become invalid. Rather than not
reporting the metric, I propose that the device reports UNKNOWN for
those metrics which do not produce sensible results.

It might be argued that such an event will coincide with a LINK DOWN
event, and I would be very happy that during a LINK DOWN that such an
event was handled within the existing specification, but if a
measurement went out of range during LINK UP, then that is where the
UNKNOWN value would be of used.

As to proposed text, dlep-03 section 9.12 (relative link quality)
already has a value of 100 to be reported where RLQ cannot be
calculated. I would remark that the case of 'cannot be calculated' is
not stated to refer to a case where that state is temporary, maybe
because of a fault, or permanent in the sense that the device does not
calculate RLQ. If we are going to have a value of UNKNOWN, then I would
suggest that this needs to be a common value across all metrics, and not
change according to the metric. A value of zero (0) would seem a good
choice for UNKNOWN. Some text would need to be inserted in every section
that discusses a metric (9.7-9.12) indicating that where the metric is
reported by the device under normal operation, but that the device is
temporarily unable to do so, that a value of UNKNOWN be reported to
signal this temporary state.

Regards

John  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stan Ratliff (sratliff)
Sent: 15 October 2012 01:09
To: Henning Rogge
Cc: [email-masked]; Bo Berry (boberry)
Subject: Re: [manet] Some comments on manet-dlep-03

I've asked twice now (this email makes attempt number 3) for someone to
suggest some text to clarify what a router or modem would do with an
UNKNOWN metric. So far, what I've seen is a potentially new *way* of
specifying UNKNOWN - one that makes more sense than picking some
arbitrary code point. But no actual text to suggest what either of the
endpoints would *do* with the data. Maybe I'm old, feeble, and not very
bright - but I'm looking for suggestions that start with "A router
receiving a metric value of UNKNOWN MUST..." or "An implementation
receiving an UNKNOWN indication SHOULD..." or something along those
lines. Barring that, the only text I've got to insert is what I
> "Implementations MAY use the value RLQ_UNKNOWN (TBD) in cases where
RLQ is supported, but not currently calculable. The authors have no idea
under what circumstances this would occur. Routers receiving a value of
RLQ_UNKNOWN are free to take any action deemed appropriate, including
(but not limited to) ignoring the value, producing log messages, or
bursting into flames. The RLQ_UNKNOWN (TBD) value was added at the
request of the working group, as consensus formed around the key ideas
that this MAY allow for innovation, even though none of the working
group members were able to note a set of circumstances under which this
innovation might take place. So, in an effort to stop the email storm,
the authors added the additional code point."

Stan

>>> My comment is on the protocol. Optional data item TLVs can be
present,
>>> I don't see much difference in UNKNOWN and not sending the TLV.
Then,
>>>>> DLEP is (mainly) getting the neighbor information base from radio
to
>>>>> I agree with the others, because I cannot see a reason a radio is
only
>>>>>> future, for the protocol completion. Do you mean router-state as
the
>>>>>> DLEP considers the session between server and client states,
other
>>>>>> My point is that the DLEP protocol should be "complete", in that
the
>>>>>> If you think this makes no sense with the radios you have seen up
to
>>>>>> I saw on this mailing list some of us see already the requirement
the