Re: [manet] ETT metrics draft

[Ulrich Herberg <[e-mail]>]

Hi,

I have also reviewed the draft. Since it's an early draft, just some
high-level comments:
  - I like the idea of specifying the ETT metrics and I hope you will
issue a new revision.

  - The introduction is a bit confusing. It talks about the Funkfeuer
networks, and then suddenly jumps into details about ETT metric. I
would suggest to focus the document on the metric itself, and
mentioning the Funkfeuer networks only in the appendix. I also wonder
why the intended status is informational? Shouldn't it be Experimental
or Standards Track, since a protocol extension is specified?
  - section 3 (Applicability); again, I would defocus on the Funkfeuer
networks, just mention in general the use cases where the metric is
useful. You should focus more on OLSRv2 itself, IMO.
  - same section: "ETX metric that was used in the earlier [RFC3626]
implementation". Note that RFC3626 only uses hop-count, so technically
the olsr.org implementation was not RFC3626 compliant
  - section 7: Since the link tuples are extended, does that mean that
draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the
draft does not say that in the header, nor mention that in the
introduction and abstract. I assume that an informational document
could also not do that.
 - "L_ETT_last_pkt_seqno  is the last received packet sequence number
received from this link." Shouldn't there some section somewhere to
describe requirements, such as access to lower layers (e.g., packet
sequence numbers)?
 - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I
wonder if that could not be more separated.
 - some lower case "must" in section 9; should that be 2119 or not?
 - section 13: Shouldn't that be a new link metric type allocation?
How is the metric used in the OLSRv2 network?
 - why is OLSRv2 only an informative reference? Can there be normative
references in an Informational document?

- I agree with Chris' and Justin's reviews.

Best regards
Ulrich


On Tue, Jul 16, 2013 at 9:56 AM, Justin Dean <[e-mail]> wrote:
> I've also had a little bit of time to look over the draft. My comments at
> this point are more general than Chris' were. I found the draft overly
> confusing. The was an ok summary of what the metric is supposed to do, but
> the it jumps right into details. Without a good idea of how things are
> supposed to work the variable descriptions just add to the confusion.  I
> don't think it needs to be this complicated, in fact I find it worrisome
> that I wasn't able to more easily figure out how I would start implementing
> it. I'll provide more detailed feedback and possible text when I can find
> some cycles.
>
> Justin
>
> On Jul 15, 2013 6:15 AM, "Dearlove, Christopher (UK)"
> <[e-mail]> wrote:
>>
>> I have just managed to find time for a quick look over version -02 of the
>> ETT metric draft. A few comments (I omit editorial comments, such as
>> consistency of use of capitalisation of Link Tuple for a later draft).
>>
>> Section 1
>>
>> Would be useful context to note that adding metrics to OLSRv1 produced a
>> proprietary extension to RFC 3626.
>>
>> The Introduction should provide a bit more OLSrv2 context.
>>
>> Section 3
>>
>> Refers to [RFC3626] implementation. This is extended as noted above, which
>> I think is important to applicability.
>>
>> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue
>> that the control messages are sent broadcast, the data will be sent unicast.
>> There's the well-known "grey zone" problem here that is usually solved with
>> link quality (when using OLSRv1 with hop counts). It may well be that in
>> practice things work, but there is an issue here that I think needs
>> discussion.
>>
>> Section 5
>>
>> The use of packet sequence numbers relies on an erratum to RFC 5444. Do we
>> assume everyone reads errata, or should this be commented on?
>>
>> There's a metric normalisation issue for OLSRv2 (this divided by that -
>> scaled?).
>>
>> Section 6
>>
>> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used
>> something similar in link quality calculations) then it should be only
>> slightly larger than 1.0, which is worth saying.
>>
>> Section 7
>>
>> Here reading through I made a note thatr INTERVAL_TIME TLVs are optional.
>> This is discussed later. But I think a section earlier on this may be
>> appropriate. That section could also discuss entity relationships I'll get
>> to below.
>>
>> Section 9
>>
>> At the WG's requirement, we have been careful to divide up different
>> entities with different responsibilities, and controlled ways in which they
>> may interoperate. This has required some care at times. I don't think this
>> draft has put the same care in.
>>
>> There are three entities: The RFC 5444 packet multiplexer (and
>> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put in a
>> packet sequence number. OLSRv2 requests the 5444 multiplexer to add a packet
>> sequence number. Likewise how OLSRv2 interacts with HELLO messages needs
>> care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled.
>>
>> But this is more complicated than that. Because we are considering haps in
>> packet sequence numbers, that means all packets need to be considered. That
>> could include packets containing neither HELLO messages nor TC messages,
>> which normally neither NHDP nor OLSRv2 will see. (They get reported their
>> messages, and can access related packet information.) This is therefore in
>> part a function interacting directly with the 5444 multiplexer, which is
>> new, and we (WG, if this is adopted) should be clear on how to handle that -
>> or someone (in the IESG if not sooner) will ask many difficult questions.
>> Related to that is whether this extends NHDP, but is used by an extension to
>> OLSRv2, or extends just OLSRv2, and is solely defined in that context.
>>
>> Section 9.2
>>
>> When it says "packets without packet sequence number MUST NOT be
>> processed, that's not quite right  in terms of the 5444/NHDP/OLSRv2 model,
>> as discussed above. Also not clear from this wording that you just mean for
>> purpose of metric calculation.
>>
>> Section 9.2/9.3 (or other for resolution)
>>
>> Need a bit more clarity on what to do if you don't get helpful input
>> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the Link
>> Tuple is on an OLSRv2 interface, obviously maximum, but that's only said in
>> the processing, not in the can't process part.
>>
>> Section 11
>>
>> Looking at the L_in_metric calculation, is that calculation going to
>> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time right
>> now to check that). Even if it does, needs comment about rounding/truncating
>> to a representable value (note that L_in_metric must be representable, it's
>> in the OLSRv2 constraints this is bound by).
>>
>> Section 12
>>
>> These are possibly suitable values for Wi-Fi. That may be fine for
>> Funkfeuer, but if this is adapted as a WG document we need to be more
>> general that that., and to separate what's specific to that and what isn't.
>> We need to be able to understand that if, for example, I want to use this on
>> a system that varies between say 1 kbit/s and 256 kbit/s, what other
>> parameters change?
>>
>> Section 14
>>
>> Suggest referencing the NHDP/OLSRv2 integrity draft.
>>
>>
>> --
>> 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: [phone] |  Fax: [phone]
>> [e-mail] | 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
>>
>> ********************************************************************
>> 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.
>> ********************************************************************
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>