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

From: "Duke, Martin" <[email-masked]>
Date: Fri, 28 Sep 2012 09:45:15 -0700

A few comments about the DLEP draft, which I like a lot and hope moves forward:

I'd like to second Henning's comment that unknown link characteristics (e.g. latency, link quality) should not be reported as the optimum value for that characteristic. I think routers should be able to distinguish between links that have the ideal link quality and links where the radio has no idea. My suggestion is that we reserve a code (presumably 0xffff or 0xffffffff) to mean "unknown". Radios with known values MUST report known values greater than 0xfffe or 0xfffffffe (!) as 0xfffe/0xfffffffe.

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

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.

Thanks to the authors for their work on this draft.

Martin

---

From: "Duke, Martin" <[email-masked]>
Date: Fri, 28 Sep 2012 09:59:48 -0700

Also,

If I might suggest the following be added to Section 24 as another optional data item TLV:

Relative Link Quality: If present, this value represents the desired minimum link quality.

(The idea here is that radios can reduce their data rate or increase their SNR to meet the goal.)

And to the end of Section 25:

Relative Link Quality - If present, this value represents the NEW relative link quality (or unchanged, if the request is denied)

If the implemented change of one Link Characteristics Request affects the values of other link metrics not mentioned in the request, the implementation SHOULD include data item TLVs representing those secondary changes in the Link Characteristics ACK message.

The point of the last paragraph is that if I add a TDMA time slot to reduce latency, that will also have impact on data rate. If I reduce modulation to improve link quality, the same is true. Explicitly suggesting the non-obvious decision to report all of these in the ACK allows the router to infer the tradeoffs that are going on.

Thanks.
Martin