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

From: Rick Taylor <[email-masked]>
Date: Tue, 8 Mar 2016 17:28:34 +0000

Hi Chris, All,

I shall attempt to comment on Chris' comments (in each of his following 
emails).  My apologies for being so late in replying in full, I believe 
we have actually taken a lot of your points on board already but you 
deserve a full response.

Unfortunately DLEP has moved on 2 drafts since this review, and draft-20 
is in the pipe, so many comments no longer apply.

Responses inline...

On 02/12/15 10:43, Dearlove, Christopher (UK) wrote:
> 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.

We have added 'IEEE' but not referenced it.

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

Hmmm... we are still talking in very general terms at this point and 
have yet to introduce DLEP, so I beg to differ.

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

This is one for Stan really.  Is DAMA an actual standard that we can 
reference or just a general catch-all term?

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

We have tried to avoid DLEP specifics in the introduction, trying to 
describe the problem space and where DLEP can (or cannot) help, so I'm 
not sure.

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

We now explicitly use 'Type A' etc

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

Fixed in later drafts.  We now capitalize the following: Data Item, 
Message, Signal, where they have special meaning in DLEP.

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

Reworded

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

Deleted

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

The whole Logical/Physical Destination discussion has now been moved to 
later in the section where it hopefully reads better

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

We haven't explicitly suggested algorithms either here or elsewhere as 
we feel that is a can of worms too big to open.  But, we have (later) 
better defined the metrics.

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

Deleted

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

Security has been completely rewritten since draft-17.

>
> Section 3, first paragraph should “with” be ”by”, before “a ‘best effort’”?

Now 'by'

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

It is expected to be rare and is intentionally harsh to keep the 
protocol simple.  Anecdotally I have heard no grumbling from 
implementers on this restriction - most modems have a set of metrics 
they support that never changes.

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

The UDP messages are not required to be especially reliably delivered, 
hence the get-out of using a priori config if UDP packets are getting 
lost.  We didn't feel this need specific calling out.

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

This section has been reworked to add clarity.  The significant delays 
are not to state changing messages.

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

This has boiled off in the edits

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

This section has moved to the MAC Address data item.  The routers MAC is 
the Destination MAC other peers see, this is detailed in draft-20.

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

The rules have been edited and moved to add clarity.

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

Yes - see Destination Announce

>
> Section 4.1. I spot a military influence in “one (1)”. But here I don’t
> think needed.

I quite like it... anyone else have an opinion?

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

We have heavily reworked timeouts in draft-20.

On to the next mail!

Rick