Subject: [manet] DLEP-17 review, part 1

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Dec 2015 10:42:48 +0000

I'm calling this part 1, as I hope to get time to review the rest. But as I'm not sure when, I'll give you what I've got up to and including Section 4. Of course I might want to revisit after reading rest of draft.

Section 1. I think 802.11 should at the least be qualified with IEEE on first use. On balance I think not referencing it is OK, but I did think about that.

Section 1, paragraph 2. The issue with an event driven paradigm is message loss. Here of course you plan no message loss by having a reliable modem-router link. But that (a) isn't indicated here, and (b) this appears to be discussing what happens within the network, where message loss is a real issue. So I think this wording could be improved.

Section 1, reference to DAMA. This I think needs a reference at least. It sort of jars a bit, but may be important (not clear).

Section 1, top of page 6, I think it would be appropriate to indicate that DLEP is designed to handle ranges of values that cover all realistic cases. (At least somewhere in the introductory part, not necessarily here.)

I found Figure 2 and text around it confusing. I think what we have is two modems of type A - just saying modem A usually means the modem named A, and two of them? But insert type (assuming that's what's meant) in appropriate places and it gets clearer.

Section 1.1, first paragraph. I think data item is usually Data Item. (I haven't gone through and checked consistency in general - not even where I'm up to - this just stood out.)

Section 1.1, second paragraph, "based on a heartbeat". Strictly it doesn't time out based on a heartbeat, it times out unless maintained by a message, possibly a heartbeat, i.e. may time out based on absence of a heartbeat (or other message).

Section 1.1. paragraph 3 "a specific, addressable location (e.g. an address)". What other possibilities are there other than an address? This also equates an addressable location and an address, which is confusing. Probably just delete the parenthesis.

Section 1.1 says a destination may be physical or logical. I think this should start a paragraph, or here be a paragraph on its own. Then the next paragraph says what a physical destination is, good. But the next paragraph starts with multicast, and only some way into the paragraph do we discover we're now talking about logical destinations. That should be how the paragraph starts.

Section 1.1 says that algorithms used in multicast are up to the implementation. But I think (and maybe this is done later when specific metrics are introduced) the implementer needs to know what a metric is meant to mean, in particular in the multicast case. For example is latency related to worst case or average group member?

Section 1.1 final paragraph, "(e.g. multicast)". Are there any other logical examples?

Section 2, security is said to be handled by transport. I know there's been some discussion of this, but for these comments I'll take the draft as written. The example is TLS, which is applicable to TCP. But some DLEP messages are UDP, what's the security mechanism there? (I've yet to understand how critical the UDP messages are.)

Section 3, first paragraph should "with" be "by", before "a 'best effort'"?

Section 3, penultimate paragraph, from the outside the need to tear down a session and re-establish it in order to add new information seems wasteful. Though a simpler protocol of course. Is this expected to be rare?

Section 4. A key issue throughout this, but not clearly indicated up front, is that DLEP is designed for a reliable link between modem and router. (I'm not yet sure how reliable the UDP messages need to be.)

Section 4, paragraph 1. This discusses DLEP states in terms that cover both modem and radio. In practice each must run its own state machine. With reliable messages with short responses, those states should be corresponding, except short transients. But it's also said later that there can be significant delays (but do those apply to state-changing messages?) At the least I think this should be indicated.

Section 4, paragraph 2, "as well as" should this be e.g. "instead of"?

Section 4, paragraph 3. Why should the EUI format match that between the modem and the radio. Why should DLEP - which should be running over a layer 4 connection between the two - know, even less care, what layer 2 addressing is being used on that modem-router link?

Section 4 paragraphs 4 and 6, I think could be clearer that the pair of messages is one each.

Section 4, paragraph 5 (this may be answered later). Can  the receiver of a Destination Up message (modem or router?) become re-interested after becoming uninterested?

Section 4.1. I spot a military influence in "one (1)". But here I don't think needed.

Section 4.1 raised questions in my mind about timeouts and lack thereof - especially as there's an earlier reference (about heartbeats) to timeouts. This is just to say note that the reader may have questions here. Is it worth avoiding them?

********************************************************************
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: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 2 Dec 2015 14:13:11 +0000

Chris,

Thanks for the review input.

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Wednesday, December 02, 2015 5:43 AM
To: [email-masked]
Subject: [manet] DLEP-17 review, part 1

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________