Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt

From: Henning Rogge <[email-masked]>
Date: Tue, 4 Sep 2012 10:59:30 +0200

Hi,

I spent time during the weekend to read through the new DLEP-03 draft a 
few times.

I see that the DLEP-03 draft has changed a lot since the last draft, so 
I will try to focus both on general issues and small comments. 
Especially the removal of the "Detached Peer Discovery" will safe a lot 
of time on this draft, maybe we can talk about getting the "DLEP over 
radio" feature (or a similar one) back as an extension draft.

I also think we should work on standardizing more optional metric values 
(otherwise interoperability for additional metrics will be difficult), 
but that can be done at a later time.

Here are my comments:

1.) Bi-directional Discovery
----------------------------

In the current draft both the Modem/Radio and the Router can be the 
active or the passive component of discovery.

I am not sure why this was even changed compared to draft 00-02. I 
cannot remember anyone disagreeing with the former solution that the 
Radio/Modem is the active component that sends discovery packets on its 
own and that the Router will react to them.

The new specification mentions the existence of a race condition when 
both discovery packets are processed at the same time, but doesn't 
cleanly specifies how this should be detected and how it is resolved.

It does not mention the possibility that someone buys a Modem/Radio and 
a Router which BOTH only implement the passive/reactive Discovery 
method. In this case the protocol will just do nothing, even with two 
standard compliant devices.

2.) Semi-optional Acknowledgement Mechanism
-------------------------------------------

DLEP-03 makes half of the Acknowledgment messages of DLEP-02 optional 
(the one for neighbor up/down message). But it still doesn't specify how 
their are handled, except by a few rough examples in an appendix.

Is one of the peers allowed to send further messages before the last one 
was acknowledged? What is happening if a message is not acknowledged by 
the other side?

There is also a strange situation if the sender of a message expects an 
ACK but the receiver does not support them. Does the receiver somehow 
recognize the duplicate messages (if yes, how?) and do they need to be 
dropped?

The flow diagrams 30.2.1 and 30.2.2 suggest that Neighbor Updates are 
only sent by the Modem after receiving a Neighbor Up ACK message. Which 
would make tranfering metric data between an ACK-enabled radio and 
router without ACK support impossible.

3.) Mandatory Metric-TLVs with optional content
-----------------------------------------------

Both Latency, Resources and Relative Link Quality are defined as 
mandatory TLVs, but all of them specify that a certain value should be 
transmitted if the radio cannot calculate the value.

Why?

If we use a TLV system and accept that a value cannot be calculated by a 
radio, we should just make the TLV optional. Otherwise we force the 
DLEP-implementation to lie about the value.

This is especially problematic in the case of the Relative Link Quality 
TLV, which defines the "not calculable" value as a perfect link. Which 
means that the routing protocol suddenly optimize their paths to radios 
which cannot measure their links.

4.) DLEP packet format
----------------------

I am still the opinion that stepping away from RFC5444 was a bad choice, 
but we could talk for ages about this so I will focus on the new format 
defined in DLEP-03. The current format is definitely an improvement 
compared to the DLEP-02 "half-RFC5444" one.

As a general comment I think the description of the TLV values should be 
either everywhere in the explaining text above the TLV graphcis or 
below. But thats cleanup work which can be done later.

Section 2:
This section explains how the DLEP sequence number should be done. But 
there is neither a sequence number in the packet format, nor is it 
mentioned somewhere else in the draft. I am not sure if the sequence 
number is missing from the packet format description or if the 
description in section 2 should be removed.

Section 8/10:
Both section 8 and Section 10 specify the basic message format, this 
should be joined into a single section.

Section 9.1:
The Identification TLV is mandatory (what should happen if its missing?) 
and must always be first in a DLEP message, right after the Signal TLV 
header. So why don't put the ID-fields into the header without a TLV 
around them?

In addition to this it would be a good idea to increase the length of 
Router-ID and Modem-ID to six octets each. Every DLEP-capable modem and 
router has an ethernet device, which MAC-address can easily be used as a 
default unique identification number (if no other number is configured).

I am not even sure why the Identification is necessary at all for the 
router. I see a reason for the Radio-ID, because a router can handle 
multiple radios. But the way the DLEP-protocol is described, a radio can 
only communicate with a single router.

Section 9.2:
The Version TLV is optional, I am not sure this makes much sense. Either 
make it mandatory (and maybe put it into the header) or drop it completely.

Section 9.7/9.8:
The Maximum/Current Data Rate TLVs only allow to specify a single link 
speed, but there are a lot of radio devices which allow for asymmetric 
link speeds. Maybe there should be a data-value for incoming and 
outgoing link speed in both TLVs.

Section 9.10:
The definition of the Latency TLV is pretty vague, especially for a 
mandatory TLV.

Section 9.13:
The Status TLV says that the failure codes are message specific, but 
these specific TLVs are nowhere in the whole draft. I would suggest 
adding at least a "generic failure" encoding.

Section 9.14:
The Heartbeat TLVs Threshold should be allowed to be zero if the 
Interval is also zero.

Section 9.15:
The Link Characteristics ACK Timer TLV mentions a "default value", which 
is nowhere defined. Maybe this draft should have a "default value" section?

Section 9.18:
The Credit Request TLV has length zero but an UNUSED 1 octet content. 
Either the content should be removed or the length should be 1. I would 
suggest removing the content until there is an usage for it.

Section 11:
Heartbeat Interval and Heartbeat Threshold have been joined into a 
single TLV.

Also the usage of the metric values within this message (when send from 
Router to Modem/Radio) is vague, because its unspecified how this 
'defaults' are used by the protocol.

Section 13:
This section allows to not use the Status TLV, but its still defined as 
mandatory in the list.

Section 14:
How does one side "determines" that the other side does not implement 
Layer-3 address changes in Peer Updates?

Section 17:
What does a Peer Termination ACK with "Status: failure" mean?

Section 18:
This section mentions that Neighbor Up ACK Messages are required, but 
they were declared optional in section 7.

Section 19:
Shouldn't the Neighbor Up ACK  Message contain a Status TLV too?

Section 22:
The Neighbor Update Message is not ACKed at all. Does the Radio need to 
repeat temporarily unchanging metric values from time to time to make 
sure they were not lost?

Section 23:
It would be good to mention the use of Jitter for the Heartbeat Message.

This section also contains the default for the "Threshold" value if no 
Heartbeat TLV is received. This should go to a "Default Value" section.

Section 24/25:
The texts for "Current Data Rate" of both sections have been mixed up.

-----------------------

My general feeling about the new draft is that it is a bit too vague and 
underspecified. Even more than draft-02, it leaves a lot of things to 
"implementation details" and "options", which create the situation that 
we might get multiple standard compliant devices that are unable to talk 
to each other.

DLEP specifies a protocol between Radio/Modems and Routers, so we should 
work hard on making sure that independent implementations will be 
inter-operable. There is still a lot of work to be done.

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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Sep 2012 09:16:58 +0000

I haven't read this yet, but have just skimmed Henning's comments. One thing jumped out at me from them, they appear to suggest constraints on ordering of TLVs. That may be OK by me (but  as I said, not read) but a word of warning that pre-5444 had TLV ordering constraints, and some people on the IESG really did not like this. I could go into why pre-5444 had such constraints (which ironically, the authors had to be argued into, then back out of) but I don't think that would be helpful. I'd just say if you have such constraints, I suggest having strong arguments for this, and to know what should happen if misordered TLVs are received.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 04 September 2012 10:00
To: [email-masked]
Cc: Bo Berry; Stan Ratliff
Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt

Hi,

Here are my comments:

Why?

4.) DLEP packet format
----------------------

Section 2:

Section 8/10:

Section 9.1:

Section 9.2:

Section 9.7/9.8:

Section 9.10:

Section 9.13:

Section 9.14:

Section 9.15:

Section 9.18:

Section 11:

Section 13:

Section 14:

Section 17:

Section 18:

Section 19:

Section 22:

Section 23:

Section 24/25:

-----------------------

Henning Rogge

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Tue, 4 Sep 2012 11:42:22 +0200

On 09/04/2012 11:16 AM, Dearlove, Christopher (UK) wrote:
> I haven't read this yet, but have just skimmed Henning's comments.
> One thing jumped out at me from them, they appear to suggest
> constraints on ordering of TLVs. That may be OK by me (but  as I
> said, not read) but a word of warning that pre-5444 had TLV ordering
> constraints, and some people on the IESG really did not like this. I
> could go into why pre-5444 had such constraints (which ironically,
> the authors had to be argued into, then back out of) but I don't
> think that would be helpful. I'd just say if you have such
> constraints, I suggest having strong arguments for this, and to know
> what should happen if misordered TLVs are received.

The Identification TLV is the only one with a mandatory position (it is 
mandatory and must be the first TLV), so it would be easy to solve this 
problem by moving the value of the TLV to the message header (instead of 
into an TLV).

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Sep 2012 13:04:59 +0200

Hi Henning,

I have some comments in line, (I am still reading the draft not
completed from my total comments),

> radio" feature (or a similar one) back as an extension draft.

I had a feeling that will be the case that is why we needed to see the
new draft before discussion.
> 1.) Bi-directional Discovery

That maybe an advantage, but suggest to be controled by the DLEP.
> own and that the Router will react to them.

The draft-03 did not delete the option of draft-02 just added new
discovery option, seem to get more complicated but may have good
reasons, hope the authors comment on the reasons for this addition.
> cleanly specifies how this should be detected and how it is resolved.

This support that your concerns to be added in next draft,

> standard compliant devices.

agree

> 4.) DLEP packet format

I like that the draft is now focused on the DLEP functions and needed
information as I suggested before, but RFC5444 packets can be a good
advantage in the future either for this work or another version.
> default unique identification number (if no other number is configured).
I agree with you, but once one author mentioned that DLEP can be used
in small devices so maybe reduce length is a good idea as well.

> only communicate with a single router.

I agree with you in the way this draft is presented, but I think the
authors may have a good reason for this, I am not sure.

> make it mandatory (and maybe put it into the header) or drop it completely.
Why drop completely? it is ok to be optional, if not necessary.

while skimming the draft I felt that alot of work was done which made
it more interesting/progressing. The issue of too vague can be solved
by amendments/discussions to produce the next draft.

> inter-operable. There is still a lot of work to be done.

Your right and hope we get more discussions and suggestions from the
group to add efforts and shorten the time spent to submit this work in
2013.

Regards
AB

---

From: "Mercieca, Victoria" <[email-masked]>
Date: Tue, 4 Sep 2012 13:17:03 +0100

Hi all,

I've also spent some time looking at the new DLEP draft and here are my
thoughts. I have divided my comments into notes on DLEP functionality
and notes on the document itself.

DLEP functionality
----------------------------------
Section 3 - Credit windowing scheme
I don't understand the credit windowing on the amount sent from radio to
router. The router can surely handle data as fast as the radio can
receive it?
I do understand the need for router to limit its outgoing traffic to the
radio. My initial thought was that the router would do this - when it
creates a virtual interface per neighbour, it associates a data rate
with that interface. With that technique though, I can see that a
problem might occur if the router thinks it can send at 5Mbps to
neighbour A and 1Mbps to neighbour B at the same time, if the radio can
only send at a maximum rate of 5Mbps, so I suppose it does make sense
that the radio can govern the total traffic sent to it from the router. 
But, could it also do this by reporting differently, for example if it
is currently sending at 5Mbps to one neighbour when its own MDR is
5Mbps, tell the router that it has no available bandwidth for other
neighbours? Then the Link Characteristic Requests would come into play
so that the router can request that the radio re-organises to allow
communication to another neighbour. The router could even have this same
intelligence to adjust the total rate it sends at based on the
modem-wide MDR for example.

Does the use of credit windowing mean that actually the reported CDR is
not the CDR that can be used? Is it effectively a way of saying there's
an available data rate, in which case why isn't Available Data Rate a
metric which depends on actual traffic being sent, e.g. CDR on link to
neighbour minus data rate in use by radio at current moment?
If data is being sent across the radio, is the CDR reported affected by
this anyway? I guess this depends on the radio itself and how it
determines CDR. We come back to the age-old question of what exactly do
our metrics mean?

Section 9.4
I have a question about multicast/broadcast MAC Addresses. What happens
in terms of IP addresses? Might there be multiple IP addresses
associated with this MAC address or would we have a one-to-one mapping
between multicast IP and multicast MAC? From section 9.5 it looks like
DLEP can deal with multiple IP addresses per MAC address, but storage of
multiple IP addresses is not something I've considered before. Does DLEP
even care how the router stores or acts on this information?

Section 9.14 
If threshold is 0, it says to reject the TLV, but do we then use a
default value for the threshold, or does this mean to reject the message
entirely? If the heartbeat interval is 0, is it an issue if the
threshold value is 0?

Section 9.15
If no reply is received to a Link Characteristic Request in the timeout
period, is the request sent again? Or does no reply mean the request has
not been understood or fulfilled? If the timeout value is 0 does that
mean we wait forever for a reply, how do we know when to send a request
again?

Section 9.16 - 9.18 
Should the request specify how many credits it requires?

Section 12 
If you send a Peer Offer, what happens if you don't get a Peer Offer
ACK?

Section 14
When metrics are reported in a Peer Update, do these reflect the radio
metrics or the router-modem link?
If it's radio metrics, does the full set of the original 5 metrics have
to be included? And does it make sense that all those metrics should be
applied to all neighbours? MDR makes sense, and resources if it applies
to local resources, in which case there's probably no point including it
in a neighbour context. 
If it's router-modem link metrics, MDR and CDR will probably be much
higher than the values on the radio link, resources should be applied to
all neighbours, latency values added to all latencies reported in
neighbour context...?

Section 16
The router should delete neighbours in its information base when a DLEP
peer session is terminated, but a radio need not wipe this information
just because the DLEP session is down, surely? The radio still knows
about those neighbours and can be ready to report on them when a new
DLEP session is established.

Section 16/17 
When you send a Peer Termination, do you wait for the ACK or a timeout
before you delete local information about the session? If you delete it
when you send the Termination, the Termination ACK is meaningless. The
action is not clear. Section 17 doesn't mention freeing resources and
re-entering discovery state but 16 does.

Section 18 
When a router informs the modem of a multicast Neighbour Up, I guess
this doesn't contain any metrics? Should the modem reply with a
Neighbour Update? I guess how it determines the metrics is out of scope
of DLEP, but the Neighbour Up from the router would be the prompt for
the modem to find out and report those?

Section 21 
Deleting entries in the neighbour database when a Neighbour Down is
received - from the router's perspective, this might include deleting IP
address information. If the neighbour comes back up, there may be delays
while neighbour discovery takes place again. To avoid this sort of
thing, some of the neighbour information could remain as long as the
neighbour is marked as down, to save time and bandwidth in case of the
neighbour re-appearing.

Document structure/wording
----------------------------------------
Does DLEP stand for "Data Link Exchange Protocol" (as in introduction,
page 5) or "Dynamic Link Exchange Protocol" (as in the title)?

When "well-known port" is referred to, this could be clarified further
by using "well-known UDP port".

Figure 2 is split over two pages. Also some packet diagrams later in the
document are also split over two pages.

Section 2 
Some of these paragraphs are not really assumptions (1,2,4,5,7). These
paragraphs describe things which are explained in better detail later in
their own sections.

Section 5 - Extensions to DLEP 
I would place this nearer the end of the document, before Section 26 for
example.

Section 6
In the first paragraph the last sentence looks like it's had another
sentence pasted in the middle of it.  Also the discovery procedure
explanation is repeated in the second paragraph. I'd put this whole
section before Credits (section 3 currently).
For the peer session description there's a bulleted list but for
neighbour removal there's numbering in the text. For consistency both
should use the same. My personal preference is to have this within the
text without any numbering/bullets.

Section 7
Are Neighbor Up ACK and Neighbor Down ACK messages optional? Also in
this section, would it be better to have one list of Mandatory Signals
and a separate list of Mandatory Data Items? 
It might be easier to understand if there was a section with a list of
the full set of signals (indicated mandatory or optional) and the data
items that can or must be included with each of them. 
Also, the Identification data item is supposed to be in every message
but is not shown in this section to be part of every mandatory
message/signal. 
Also this section mentions "Attached Peer Discovery". If there's no
longer a Detached Peer Discovery, is the word "Attached" necessary?

Personally, I'd like to see the sections 10-25 on message/signal types
straight after section 8, and the sections about data items afterwards.

Section 8 
Is a DLEP packet only allowed to contain one order/signal/message? It
would be clearer if the label "Signal TLV Type" was changed to "Signal
Type". Also "first TLV" is not strictly a TLV. This is also referred to
as "initial TLV" later in the document at multiple locations.

Section 9
It might be clearer if the diagram showed "Data Item Type" instead of
"TLV Type", to ensure consistency of terminology.

Section 9.1
There is now some confusion / overlap between previous terminology
(Packet/Message/TLV) and new terminology (Packet/Signal-Message/Data
Item).
Also "initial TLV" and "signal TLV" is mentioned again.
Section 9.1 also says the Identification Data Item is mandatory in all
messages but in Section 7 it's not listed for every signal in the
mandatory set.

Section 9.5 and 9.6 
The message types that IPv4 and IPv6 addresses can be given in doesn't
match the message descriptions in later sections. 
IPv4 can be in Peer Offer (section 12), but Peer Offer is not mentioned
in section 9.5. 
Section 9.6 says that IPv6 can be in Peer Discovery (this is not
mentioned in section 11), but doesn't mention that it can be in Peer
Offer (but does in section 12).
Since either side can now send the Peer Discovery, either side can send
the Peer Offer, so are there TLVs which can be sent in either Discovery
or Offer but only if sent from particular side (modem or router)? 

Section 9.7 - 9.8, 9.10 - 9.12 
If metrics can be given in a Peer Discovery message, surely they can be
given in an offer message, since either side can send the first Peer
Discovery. The modem could send the Peer Discovery or the Peer Offer,
and if it needs to get the metric information to the router it might
need to do this in the Peer Offer? It probably makes sense to say
metrics can be used in Peer Discovery, Offer, or Update, or Neighbour
Up, Update or Down messages, but only when sent by the modem?

Section 9.7, 9.11 and 9.12
These sections say MDR, Resources and RLQ can be in the Link
Characteristic Request ACK message, but section 25 doesn't agree. 

Sections 9.14 and 9.15 
These are written as if the modem sends the discovery to router. Is this
text also valid for other way round, since section 6 says either side
can send the discovery? 

Section 9.16 and 9.17 
Should "Credit Grant Request" be labelled "Credit Grant", since 9.18 is
the "Credit Request"? Also it's not clear in Section 9.16 which
messages/signals this can be used in.

Section 9.17
Is this only sent in response to a Credit Request or can it be sent
independently? It's not clear in what order these TLVs should be sent.
I'm guessing first is the Credit Request (section 9.18), then Credit
Grant (section 9.17), then Credit Window Status (9.16)? Would it make
more sense to put the credit sections in this order? Or explain this
earlier in the document?

Section 10
The DLEP Message is exactly the same as the DLEP Packet in Section 8 but
now shows the fields of the mandatory "Identification TLV" /
"Identification Data Item" after the signal type and length fields. It
seems that either Section 8 or 10 is unnecessary, unless it is intended
that multiple messages/signals may appear in one DLEP Packet, though I
don't think I saw this mentioned? I prefer how section 8 describes it.
The packet structure is not clear now. Before, it was easy to
understand: 
1 Packet = 1 or more Message(s). 
1 Message = 1 or more TLV(s).
Now there's extra terms Signal and Data Item, but it seems like 1
(Packet / Signal / Message) = 1 or more (Data item / TLV).
Also if this is clarified, the explanation of packet structure in
section 1 on page 6 should be checked too.

There's a difference in document structure here. Section 9 showed DLEP
data items overview, then 9.1-9.18 showed the data items. Now, section
10 is the DLEP message/packet format (which is probably unnecessary if
section 8 remains), 10.1 is Signal Values overview, so it would make
sense for 10.2-10.x to be the descriptions of signal types. Instead we
have sections 11-25 for the message types. I would have the current 10.1
being 10, then current 11-25 being 10.1-15.

Section 10.1 - Would be easier to follow if this said "Signal Types"
instead of "Signal TLV Values".

I'd suggest to refer to the type as "Signal Type" or "Message Type" not
"initial TLV Type Value". The constants like
DLEP_ATTACHED_PEER_DISCOVERY could be included in the overview in
section 10.1. e.g. 
Signal Type					Signal Description
========================================================
DLEP_ATTACHED_PEER_DISCOVERY (TBD)	Peer Discovery
DLEP_PEER_OFFER (TBD)			Peer Offer
etc...

Section 11
This says the Peer Offer is required to complete the discovery process,
however, in section 6 it says that the Peer Offer ACK is required to
finish the discovery process. 
It also mentions "packet format described in section 11" - does it mean
Section 10 or Section 8? I'd say use section 8 since section 11 then
says the ID TLV is first, and section 10 says "this header structure is
assumed, and will not be replicated". 
Also, why mention the Peer Offer so early in the Peer Discovery section?
Focus should be on the Peer Discovery in this section. 

Section 11 - 25
There's inconsistency in section structure. Section 11 gave "Mandatory
Data Item TLVs" list but section 12 doesn't. Same comment applies to
later sections too.
Again "initial TLV type value" is used. I suggest using "Signal Type" or
"Signal Type field". 

Section 11 and 12
Would metrics be present in the Peer Discovery and Peer Offer only if
these were sent by the modem?
Section 11 says a Peer Discovery from a peer in session should force
processing as if a Peer Termination had been received (does this include
sending Peer Termination ACK?) and then says it MAY process the Peer
Discovery message, but section 12 says it should act like a Peer
Termination was received and does not mention processing the new
discovery message. Which is correct?
For both these sections I'd recommend moving the explanation of "in
session" and subsequent discovery/offer messages to either the end of
the Peer Discovery / Peer Offer section respectively, or the Peer Offer
ACK section.

Section 12
Why mention the Peer Offer ACK before explaining the Peer Offer? 

Section 13 
This says "implementations that do NOT support the Status data item",
however the status data item is listed as mandatory in section 7 and
also later in this section.

Section 14 
The Peer Update can be sent from either side. Are the data items listed
valid only for certain directions? E.g. can the router send metrics?
This could be clarified in the list of optional data items. Also for the
Peer Update message containing metrics, are there certain metrics which
MUST be included or are they all optional?
For a Peer Update from the modem to the router, it does not say if an
ACK is required. Section 15 seems to indicate it is.

Section 18 
Just echoing the earlier point that the Neighbour Up ACK is not given as
mandatory in section 7.

Section 20 
This says mandatory TLVs are Identification and MAC address, and that
the others listed are optional. Then it says that Status TLV is
mandatory and there are no optional TLVs for this message.

Section 21
Echoing the earlier point that Neighbour Down ACK is not given as
mandatory in section 7.
Also this section says "As with the Neighbour Down message, there are NO
OPTIONAL Data Item TLVs" - this may need adjusting if Section 20
changes.

Section 22
For consistency with other sections, I'd suggest not to use a bullet
list for examples of changes. Also we need consistency with other
sections in listing mandatory / optional Data Item TLVs.

Section 24
The first part of this section says the Link Characteristic Request
message is for requesting changes, then later in the section we find out
it has another use. Both uses should be mentioned in the first
paragraph. 
Second paragraph says the message contains either CDR, Latency, or both,
then a bit later says it can send without either too. Suggest rewriting
to make the 4 options clearer from the start. 

Section 25 
When this section mentions "a complete set of metric data item TLVs",
does it mean the 5 mandatory ones or the complete set including EFT and
any experimental ones? The mandatory / optional sections below only show
CDR and Latency.

Section 27.6
When it mentions multicast address, does this mean IPv4 / IPv6 /
Ethernet / all of the above?

Appendix A 
There is no mention of the Peer Discovery ACK, especially in Section
30.1.3.
Neighbor Sessions are mentioned in Sections 30.1.4, 30.2.1, 30.2.2,
30.2.3, 30.2.4, 30.2.5, and 30.2.6.
The Heartbeat Timeout in Section 30.1.5 and 30.1.6 doesn't mention the
heartbeat threshold from Section 9.14. They still mention neighbour
sessions too. 
Are there any retries on the Termination message? Do we expect an ACK at
all? Should neighbour info be deleted AFTER an ACK is received or a
certain timeout after the Termination is sent, or when the Termination
is sent?
Section 30.1.8 is the same procedure as 30.1.7, so these could be
condensed into one section.
There's no message flow to show what happens if the Peer Termination ACK
is lost.
There's no message flow describing the router sending a Neighbour Up
message about multicast destination.
Section 30.2.6 is about neighbour sessions and is probably unnecessary.

Victoria Mercieca

---

From: Henning Rogge <[email-masked]>
Date: Tue, 4 Sep 2012 15:17:38 +0200

On 09/04/2012 02:17 PM, Mercieca, Victoria wrote:
> Hi all,
>
> I've also spent some time looking at the new DLEP draft and here are
> my thoughts. I have divided my comments into notes on DLEP
> functionality and notes on the document itself.

Hi,

triggered by your comment about the credit window system of DLEP I got
another question.

If I understand DLEP right it handles a credit window per neighbor. How
do we handle the common usecase where we have a radio with a "sender
window", which means we have credits for sending data, but not to a
specified receiver.

Lets say our radio (because of some TDMA waveform) has an outgoing
credit window of 1000 bytes.

Do we set the credit window of every neighbor to 1000 bytes? This would
mean we might get 1000 bytes for every neighbor, which is too much.

Do we distribute the 1000 bytes among our neighbors? This would prevent
any outgoing traffic to use the full 1000 bytes.

I think this should be considered before we build a Credit Window Scheme 
into DLEP that is not applicable for this use case.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 4 Sep 2012 13:36:57 +0000

> window", which means we have credits for sending data, but not to a

I've never seen, nor dealt with, such a device, and we have the credit windowing of RFC4938/RFC5578 deployed with multiple radios.  What you imply is a credit scheme that would exist from router to modem, and the 03 DLEP specifically precludes that. 

> credit window of 1000 bytes.

Sorry, but I can't envision a TDMA radio that doesn't have a "specified receiver". After all, isn't that the point of TDMA? That being, that *someone* "out there" is listening at the time you're sending? Now, there could be a broadcast/multicast slot, but that would be handled in DLEP by using the correct MAC address (e.g. for the broadcast/multicast) and creating a neighbor.

Regards,
Stan

> I think this should be considered before we build a Credit Window Scheme into DLEP that is not applicable for this use case.
> 
> Henning Rogge
> 
> --

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 4 Sep 2012 13:58:01 +0000

Henning, 

Thanks for the review. We're going over it now, but it may take a day or two…  one comment inline: 

On Sep 4, 2012, at 4:59 AM, Henning Rogge wrote:

> Hi,
> 
> I spent time during the weekend to read through the new DLEP-03 draft a few times.
> 
> I see that the DLEP-03 draft has changed a lot since the last draft, so I will try to focus both on general issues and small comments. Especially the removal of the "Detached Peer Discovery" will safe a lot of time on this draft, maybe we can talk about getting the "DLEP over radio" feature (or a similar one) back as an extension draft.
> 
> I also think we should work on standardizing more optional metric values (otherwise interoperability for additional metrics will be difficult), but that can be done at a later time.
> 
> Here are my comments:
> 
> 
> In the current draft both the Modem/Radio and the Router can be the active or the passive component of discovery.
> 
> I am not sure why this was even changed compared to draft 00-02. I cannot remember anyone disagreeing with the former solution that the Radio/Modem is the active component that sends discovery packets on its own and that the Router will react to them.
> 
> The new specification mentions the existence of a race condition when both discovery packets are processed at the same time, but doesn't cleanly specifies how this should be detected and how it is resolved.
> 
> It does not mention the possibility that someone buys a Modem/Radio and a Router which BOTH only implement the passive/reactive Discovery method. In this case the protocol will just do nothing, even with two standard compliant devices.
> 
> 
> DLEP-03 makes half of the Acknowledgment messages of DLEP-02 optional (the one for neighbor up/down message). But it still doesn't specify how their are handled, except by a few rough examples in an appendix.
> 
> Is one of the peers allowed to send further messages before the last one was acknowledged? What is happening if a message is not acknowledged by the other side?
> 
> There is also a strange situation if the sender of a message expects an ACK but the receiver does not support them. Does the receiver somehow recognize the duplicate messages (if yes, how?) and do they need to be dropped?
> 
> The flow diagrams 30.2.1 and 30.2.2 suggest that Neighbor Updates are only sent by the Modem after receiving a Neighbor Up ACK message. Which would make tranfering metric data between an ACK-enabled radio and router without ACK support impossible.
> 
> 
> Both Latency, Resources and Relative Link Quality are defined as mandatory TLVs, but all of them specify that a certain value should be transmitted if the radio cannot calculate the value.
> 
> Why?
> 
> If we use a TLV system and accept that a value cannot be calculated by a radio, we should just make the TLV optional. Otherwise we force the DLEP-implementation to lie about the value.
> 
> This is especially problematic in the case of the Relative Link Quality TLV, which defines the "not calculable" value as a perfect link. Which means that the routing protocol suddenly optimize their paths to radios which cannot measure their links.

Not true. Or at least not true in all cases. It depends on *how* the routing protocol optimizes, which as we've said, is outside the scope of this document. For example, assume a routing protocol algorithm that "incrementally penalizes" radio links for "less than perfect" metric values. For those types of algorithms, defaulting RLQ as "perfect link" simply means "don't penalize the link because the modem can't calculate the value". That being said, I don't have an issue with making RLQ optional. 

Regards,
Stan

> 
> 
> 4.) DLEP packet format
> ----------------------
> 
> I am still the opinion that stepping away from RFC5444 was a bad choice, but we could talk for ages about this so I will focus on the new format defined in DLEP-03. The current format is definitely an improvement compared to the DLEP-02 "half-RFC5444" one.
> 
> As a general comment I think the description of the TLV values should be either everywhere in the explaining text above the TLV graphcis or below. But thats cleanup work which can be done later.
> 
> Section 2:
> This section explains how the DLEP sequence number should be done. But there is neither a sequence number in the packet format, nor is it mentioned somewhere else in the draft. I am not sure if the sequence number is missing from the packet format description or if the description in section 2 should be removed.
> 
> Section 8/10:
> Both section 8 and Section 10 specify the basic message format, this should be joined into a single section.
> 
> Section 9.1:
> The Identification TLV is mandatory (what should happen if its missing?) and must always be first in a DLEP message, right after the Signal TLV header. So why don't put the ID-fields into the header without a TLV around them?
> 
> In addition to this it would be a good idea to increase the length of Router-ID and Modem-ID to six octets each. Every DLEP-capable modem and router has an ethernet device, which MAC-address can easily be used as a default unique identification number (if no other number is configured).
> 
> I am not even sure why the Identification is necessary at all for the router. I see a reason for the Radio-ID, because a router can handle multiple radios. But the way the DLEP-protocol is described, a radio can only communicate with a single router.
> 
> Section 9.2:
> The Version TLV is optional, I am not sure this makes much sense. Either make it mandatory (and maybe put it into the header) or drop it completely.
> 
> Section 9.7/9.8:
> The Maximum/Current Data Rate TLVs only allow to specify a single link speed, but there are a lot of radio devices which allow for asymmetric link speeds. Maybe there should be a data-value for incoming and outgoing link speed in both TLVs.
> 
> Section 9.10:
> The definition of the Latency TLV is pretty vague, especially for a mandatory TLV.
> 
> Section 9.13:
> The Status TLV says that the failure codes are message specific, but these specific TLVs are nowhere in the whole draft. I would suggest adding at least a "generic failure" encoding.
> 
> Section 9.14:
> The Heartbeat TLVs Threshold should be allowed to be zero if the Interval is also zero.
> 
> Section 9.15:
> The Link Characteristics ACK Timer TLV mentions a "default value", which is nowhere defined. Maybe this draft should have a "default value" section?
> 
> Section 9.18:
> The Credit Request TLV has length zero but an UNUSED 1 octet content. Either the content should be removed or the length should be 1. I would suggest removing the content until there is an usage for it.
> 
> Section 11:
> Heartbeat Interval and Heartbeat Threshold have been joined into a single TLV.
> 
> Also the usage of the metric values within this message (when send from Router to Modem/Radio) is vague, because its unspecified how this 'defaults' are used by the protocol.
> 
> Section 13:
> This section allows to not use the Status TLV, but its still defined as mandatory in the list.
> 
> Section 14:
> How does one side "determines" that the other side does not implement Layer-3 address changes in Peer Updates?
> 
> Section 17:
> This section mentions that Neighbor Up ACK Messages are required, but they were declared optional in section 7.
> 
> Section 19:
> The Neighbor Update Message is not ACKed at all. Does the Radio need to repeat temporarily unchanging metric values from time to time to make sure they were not lost?
> 
> Section 23:
> This section also contains the default for the "Threshold" value if no Heartbeat TLV is received. This should go to a "Default Value" section.
> 
> Section 24/25:
> My general feeling about the new draft is that it is a bit too vague and underspecified. Even more than draft-02, it leaves a lot of things to "implementation details" and "options", which create the situation that we might get multiple standard compliant devices that are unable to talk to each other.
> 
> DLEP specifies a protocol between Radio/Modems and Routers, so we should work hard on making sure that independent implementations will be inter-operable. There is still a lot of work to be done.
> 
> Henning Rogge
> 
> --

---

From: Henning Rogge <[email-masked]>
Date: Tue, 4 Sep 2012 16:12:20 +0200

Am 04.09.2012 15:36, schrieb Stan Ratliff (sratliff):
>> If I understand DLEP right it handles a credit window per neighbor.
>> How do we handle the common usecase where we have a radio with a
>> "sender window", which means we have credits for sending data, but
>> not to a specified receiver.
>
> I've never seen, nor dealt with, such a device,

I have seen a few of them... and a co-worker from our SDR research group 
told me that both concepts ("allocating transmission time" vs. 
"allocating link") exists.

 > and we have the
> credit windowing of RFC4938/RFC5578 deployed with multiple radios.

I don't say these devices do not exist, I just say they are not the only 
use case for the credit window system.

> What you imply is a credit scheme that would exist from router to
> modem, and the 03 DLEP specifically precludes that.

No, I am not.

> Sorry, but I can't envision a TDMA radio that doesn't have a
> "specified receiver". After all, isn't that the point of TDMA?

The main point of TDMA is that no one else is transmitting when I want 
to transmit. It guarantees me a collision free transmission.

If the TDMA protocol distinguishs between unicast slots to different 
targets or is just used for this transmission time allocation would be 
implementation specific.

I also would like to use DLEP together with consumer technologies like 
WLAN and the credit scheme could be used to prevent the router from 
overflowing the buffer on the WLAN-radio device. In this case I also 
have no different credit windows for each destination, I have only a 
single "outgoing queue" on the radio.

 > That
> being, that *someone* "out there" is listening at the time you're
> sending? Now, there could be a broadcast/multicast slot, but that
> would be handled in DLEP by using the correct MAC address (e.g. for
> the broadcast/multicast) and creating a neighbor.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 4 Sep 2012 17:54:13 +0000

On Sep 4, 2012, at 10:12 AM, Henning Rogge wrote:

> I have seen a few of them... and a co-worker from our SDR research group told me that both concepts ("allocating transmission time" vs. "allocating link") exists.
> 
> > and we have the
> I don't say these devices do not exist, I just say they are not the only use case for the credit window system.

Then describe the use case - as of this point, I still haven't heard it (or understood it). 

> The main point of TDMA is that no one else is transmitting when I want to transmit. It guarantees me a collision free transmission.

Ahhh, I see. So as long as I transmit successfully, it doesn't matter that no one hears it… good to know.

> 
> If the TDMA protocol distinguishs between unicast slots to different targets or is just used for this transmission time allocation would be implementation specific.
> 
> I also would like to use DLEP together with consumer technologies like WLAN and the credit scheme could be used to prevent the router from overflowing the buffer on the WLAN-radio device. In this case I also have no different credit windows for each destination, I have only a single "outgoing queue" on the radio.

Which directly contradicts your earlier statement. You *do* imply a credit scheme at the router/modem level. That's the scheme represented by the single "outgoing queue" on the radio. Implicit in that single outgoing queue is a single rate for traffic to be emitted towards the radio. So essentially, I'd argue that's no different than what we have today - a radio attached to a router's interface, with the appropriate bandwidth set at the router. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 4 Sep 2012 17:17:03 +0200

> I also would like to use DLEP together with consumer technologies like WLAN and the credit scheme could be used to prevent the router from overflowing the buffer on the WLAN-radio device. In this c…

Current consumer WLAN gear should have MME. I expect the more advanced stuff has something better. I don't get how DLEP credit windowing can support this.

Bufferbloat research showed overflowing the buffers gets harder and harder, as memory gets cheaper and cheaper. So we face the task to implement advanced packet dispatching on the bottleneck. Which is in the radio/modem. IMHO transfer of the bottleneck to a router is not the preferred solution. I know not everybody does agree here.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Sep 2012 07:05:01 +0200

> Which directly contradicts your earlier statement. You *do* imply a credit scheme at the router/modem level. That's the scheme represented by the single "outgoing queue" on the radio. Implicit in t…

Where does the single rate idea come from?
WLAN media access is far more complex than single queue single rate.

Teco 

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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Sep 2012 13:36:06 +0200

Am 04.09.2012 19:54, schrieb Stan Ratliff (sratliff):
> Which directly contradicts your earlier statement. You *do* imply a
> credit scheme at the router/modem level. That's the scheme
> represented by the single "outgoing queue" on the radio. Implicit in
> that single outgoing queue is a single rate for traffic to be emitted
> towards the radio. So essentially, I'd argue that's no different than
> what we have today - a radio attached to a router's interface, with
> the appropriate bandwidth set at the router.

The problem with your approach is the Shared Medium access on the radio. 
Even if we assume a fixed radio link speed (which might be heavily 
depend on the destination of the packet), there is no way to predict how 
long it will take until the radio gets access to the medium.

Without information when its packets have been sent over the radio, the 
router doesn't know if it can sent further data over the ethernet link 
or if its just stored in the outgoing queue on the radio.

This is similar to the Bufferbloat problem.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Sep 2012 15:05:54 +0200

Am 04.09.2012 15:58, schrieb Stan Ratliff (sratliff):
>> mandatory TLVs, but all of them specify that a certain value should
>> be transmitted if the radio cannot calculate the value.
>>
>> Why?
>>
>> If we use a TLV system and accept that a value cannot be calculated
>> by a radio, we should just make the TLV optional. Otherwise we
>> force the DLEP-implementation to lie about the value.
>>
>> This is especially problematic in the case of the Relative Link
>> Quality TLV, which defines the "not calculable" value as a perfect
>> link. Which means that the routing protocol suddenly optimize their
>> paths to radios which cannot measure their links.
>
> Not true. Or at least not true in all cases. It depends on *how* the
> routing protocol optimizes, which as we've said, is outside the scope
> of this document. For example, assume a routing protocol algorithm
> that "incrementally penalizes" radio links for "less than perfect"
> metric values. For those types of algorithms, defaulting RLQ as
> "perfect link" simply means "don't penalize the link because the
> modem can't calculate the value".

 > That being said, I don't have an issue with making RLQ optional.

Making Latency, Resources and RLQ optional would resolve the whole issue 
I explained in my section 3. My issue was primarily that we are hiding 
this "cannot calculate" state in an encoding that could also be a valid 
data value.

The current defaults could be still suggested as "the router MIGHT use 
this value if TLV not exist" in the document, to keep the current 
behaviour unless the router software is designed otherwise.

Henning Rogge