Subject: [manet] questions & comments about manet-dlep-03

From: Nathan Samson <[email-masked]>
Date: Mon, 19 Nov 2012 13:06:40 +0100

Hi All,

I have just read the dlep V03 draft and I have some comments and small
questions.

First I have some general questions.

1) Transport
=========================
Draft V3 Specifies that this protocol is transport independent. Although
new consensus (as far as I can see from recent messages on the mailing
list) is that UDP would be the standard transport protocol.
Some also have suggested to use TCP, which also removes the need for many
of the different ACK messages we currently have.
Using UDP(or TCP) would also allow for the removal of the Identification
TLV (which seems to be already planned).

Why is the TCP idea not applied?  Some discussion on the list seems that
using TCP (and removing the ACKs) would make it more difficult to move to
another protocol, which also means that UDP/TCP would not be the only
transport protocol?

2) Sequence Numbers
=========================
I didn't see any sequence numbers in the messages, which makes it hard to
correlate any ACK with the corresponding message. Can someone confirm that
indeed will appear in V4 (as I saw somewhere on the list).
Note that I have seen a reference to the sequence numbers in the assumptions

Sequence Numbers for DLEP messages start at 0 and are incremented by
> one for each original and retransmitted message. The unsigned 16-bit
> Sequence Number rolls over at 65535 to 0. Sequence Numbers are unique
> within the context of a DLEP session. Sequence numbers are used in
> DLEP to correlate a response to a request.
>

To fix the rollover problem a better mechanism could be introduced like in
RFC 3220 (Mobile IP) [1]. With that scheme you can easily detect if a
rollover happened or the other participant was reset.

Another inconsistency can happen with the current scheme:

Modem                  Router
     ------------------------->  #1 (Modem sends router message with
sequence number 1)
    <------------------------    ACK #1
Now the sequence counter is at 1 on each side.
Both the modem and router wants to send something at exactly the same
moment to each other. Both will be using sequence number 2 which might pose
a problem in some implementations.

I propose to solve this issue by rewriting it as

Numbers are unique within the context of a DLEP session *per
participant*. *Each
> participant  keeps track of its own current sequence number, and the
> sequence number of the other party. *Sequence numbers are used in DLEP to
> correlate a response to a request.

This means that every packet will be correlated by the implicit sequence
number #PARTICIPANTID-SEQUENCE_NUMBER. ACKing a message will only include
the Sequence number since the participant ID (the receiver of the ACK or
the sender of the original message) is implicit.

3) Many items are specified as out of scope. I am a little bit worried that
implementations can exist without being able to be inter-operable.
=========================
 A)

> The modem, once it is aware of the existence of this
> logical neighbor, reports link characteristics just as it would for
> any other destination in the network. The specific algorithms a modem
> would use to report metrics on multicast (or logical) destinations is
> outside the scope of this specification, and is left to specific
> implementations to decide.
>
Is there  any reason why this is not specified? Or might it not be a good
idea to specify at least an example algorithm as indication?
B)

>  Either entity (the router or the modem) can initiate the discovery
> process.
>
What if both are configured to wait for the other? Isn't it better that at
least one (eg. the modem?) should be obliged to broadcast its existence?

C)

> In cases where both entities initiate discovery, a race condition can
> occur.
> When this race condition occurs, the router MUST cease its active
> discovery, and respond to the modem’s request.
>

What is meant by "the router MUST cease its active discovery"?
I understand this that the router must stop sending any Peer discovery
message.
What in the (not so uncommon) case one router has several modems attached
(from different vendors and/or with different configurations) where one
modem is not configured to send Peer discovery messages.
In these circumstances both would not be able to find each other (see also
B).
D)

This document details the mechanism whereby the data is
> transmitted, however, the specific algorithms (precedence, etc) for
> utilizing the dual-context metrics is out of scope and not addressed
> by this document.
>
Same remark as A)

E) 9.11 Resources
The message has no method to be able to tell what resource usage is
described.
>From a consumer of this information this doesn't make sense, since having a
50% memory usage might be quite different from having only 50% battery left.

What should the sender do in case he has many types of resources (very
common since any type of modem/router working on battery will have some
sort of memory)? Should he take some sort of average. How to weigh 50%
battery usage vs 75% memory usage?
I think a less general, more specific approach should be used.
Where one could specify the type of resource left in a field (Battery,
memory, disk usage, ...) and the absolute value in another field.
This other field might be different of type and length depending on the
type of resource.
The DLEP protocol could describe the most common types and their
corresponding types eg.

Memory (type = 0x01), value is unsigned 64 bit in bytes of memory left
Disk (type = 0x02), value is unsigned 64 bit in bytes of memory left
Battery Life Time (type = 0x03), value is unsigned 16 bit in minutes left
(at current usage rate) of battery life time.
Batter usage (type = 0x04), value is unsigned 8 bit in percent (0-100) of
battery left.

A method has to be invented to let implementers add their own
(experimental) types.

F) 9.13 Status

> Non Zero = Failure. Specific values of ...
>
Isn't it better to at least specify basic error case numbers? Also an
optional human readable error could be added so logs might clear up why
something happened.

G) 9.17 Credit grant request

> with the correct Status TLV.
>
What is the correct Status TLV (non zero?) Probably same issue as F)

H) 14. Peer Update Message

> Concerning Layer 3 addresses, if the modem is capable of
> understanding and forwarding this information (via proprietary
> mechanisms), the address update would prompt any remote DLEP modems
> (DLEP-enabled modems in a remote node) to issue a "Neighbor Update"
> message to their local routers with the new (or deleted) addresses.
> Modems that do not track Layer 3 addresses SHOULD silently parse and
> ignore the Peer Update Message. Modems that track Layer 3 addresses
> MUST acknowledge the Peer Update with a Peer Update ACK message.
> Routers receiving a Peer Update with metric changes MUST apply the
> new metric to all neighbors (remote nodes) accessible via the modem.
> Supporting implementations are free to employ heuristics to
> retransmit Peer Update messages. The sending of Peer Update Messages
> for Layer 3 address changes SHOULD cease when a either participant
> (router or modem) determines that the other implementation does NOT
> support Layer 3 address tracking.
>
This is rather a vague paragraph with many unspecified items.

Why is it important to detect remote DLEP modems? If a valid use case is
gven, might it not be a better idea to define a mechanism in DLEP instead
of specifying that a (proprietary) mechanism might be used.
The heuristics for resending peer updates are not defined. Why not define a
sensible set of heuristics in this document?
How can implementations detect that the other party doesn't support
tracking L3 changes?

4) Some items are optional. For most of those, I don't see a sensible
reasoning.
=================
A) Timers are an optional feature, although they seem to me that they are
very useful.
Is there any specific reason why are those optional?

B) DLEP Version TLV.
Why is this one optional? If one of the participants decides (because it
does not implement it), not to send the version TLV it might leave the
other side undecided if they can safely talk to each other.
Also no Version handshake scheme is described so that implementations can
choose to send only messages that are version compatible by the other side.

5) Various Comments
=================
A) 9.3 Peer Type Message
 * Length: 80 Octets maximum. Why is a maximum string length given?
* The type is defined as a string, but no encoding (ASCII, UTF-8) is given.
If allowing UTF-8 (as I think in the modern world we should do) the 80
octets might be quite low since might only allow for 40 visible characters
in Chinese for example (if I am not mistaken)

B) 9.5 IPv4 Address
* Add/Drop

> Value indicating whether this is a new or existing IPv4 address
>
Part of the sentence seems to be removed, since the description of this
field is correct for the IPv6 message.
* Really nitpick:

> A subnet mask (0-32) to be applied to the IPv4 address.
>
 (similar for IPv6)
It is not defined what the data type of this field is. Obviously a 8 bit
integer value, but signed vs unsigned is not defined. Obviously an unsigned
value does not make sense in this case (and is even impossible in the IPv6
case where 127 would be the maximum).

C) 9.8 Current Data Rate
* Contains a TLV Flags = 0X10 which is not defined, and is not used
anywhere else. I suspect this is a leftover of a previous version.

D) 9.11 Resources & 9.12 Relative link quality

If the values are not supported or can not be calculated their value is set
to 100, which makes it difficult (if not impossible) to differentiate
between the perfect case and the unknown case.

Since the used range is only 0-100 and we have 8 bits available we can also
use 255 as a unknown case.

E) 9.14 Heartbeat interval

> . If an activity timeout is supported, implementations
> MAY choose to implement heuristics such that signals sent/received
> reset the timer window.
>

What if the sender resets its windows, but the receiver does not imply such
heuristics? Then the receiver might time-out and send a peer terminate
request.

I think these heuristics must be required and clearly specified (since they
make sense to reduce the load on the network).

F) 9.18 Credit Request
Length = 0. Problem is that the length of the package is 1, with a reserved
field that must be set to 0.
I think this reserved field has to be removed (leftover of a previous
version?)

G) 22. Neighbour Update Message
The Neighbour Update doesn't have to seem an ACK message. Is this
intentional?

H) 25. Link Characteristics Request ACK Message.

> The Link Characteristics ACK message SHOULD contain a complete set
> of metric data item TLVs. It MUST contain the same TLV types as the
> request.
>
This seems to be a contradiction. Or it should contain a complete set, or
it should contain the same as the request.
Since the request may not contain any metrics  (as to request the current
values) it does make sense to specify
only the first part.

Cheers,
Nathan

[1] http://www.ietf.org/rfc/rfc3220.txt