Re: [manet] ETT metrics draft

[Christopher Dearlove <[e-mail]>]

Our experience with link quality differs. It's not the loss rate, it's that maximum broadcast range is greater than unicast range (lower data rate). So need to exclude links whose SNR suggests too long or poor. And this improved performance (provided sufficiently dense network).

--  
Christopher Dearlove
[e-mail] (iPhone)
[e-mail] (home)

On 22 Jul 2013, at 10:07, Henning Rogge <[e-mail]> wrote:

> Hi,
> 
> I finally had the time to work through the set of reviews from last week.
> 
> My comments are inline below.
> 
> Comments inline
> 
> On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) 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.
> 
> I think we will have to work more on Section 1/3, maybe pushing the whole "OLSr.org history" part to a section of its own so we can focus more on OLSRv2 section 1/3?
> 
>> 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.
> 
> Normally the IP packet loss of the broadcast messages seems to be higher than the IP packet loss of unicasts because of the retransmissions.
> 
> OLSR.org had a "link quality" implementation (as defined in RFC 3626) even before the ETX code, but the link quality didn't helped to stabilize the network.
> 
>> 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?
> 
> That was the reason why I explicitly stated what kind of packet sequence number this draft needs. Maybe we could mention that this requirement was also added in the errata.
> 
>> There's a metric normalisation issue for OLSRv2 (this divided by that
>> - scaled?).
> 
> The "scaling" of this ETT metric has been chosen to be useful with WIFI (802.11) speed.
> 
>> 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.
> 
> But not too small, otherwise a message aggregation timer might become a problem.
> 
>> 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.
> 
> The order of "things to consider" is a bit off...
> 
>> 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.
> 
> (I have implemented this similarly in my OLSRv2 code)
> 
>> But this is more complicated than that. Because we are considering
>> haps in packet sequence numbers, that means all packets need to be
>> considered.
> 
> Yes.
> 
> > 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,
> 
> Yes.
> 
> > 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.
> 
> I think we should handle this in a similar way than any extension that adds/reads packet level TLVs.
> 
> > 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.
> 
> Thats a bit tricky... metrics are defined in OLSRv2 but are an extension for NHDP... and metrics can be useful in NHDP even without using OLSRv2.
> 
>> 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.
> 
> "MUST NOT be process for metric calculation as described below" ?
> 
>> 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.
> 
> Easiest way would be to ignore the whole Hello timer. The problem is that the metric would not increase if contact to the neighbor is suddenly lost.
> 
>> 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).
> 
> At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 Mbit/s, ETX 16).
> 
> > 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).
> 
> I do this already in code, but maybe its worth adding to the draft that the metric should be set to the nearest metric value that can be represented in the compressed format defined in OLSRv2.
> 
>> 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?
> 
> If we change the parameters to extend the metric range to MINIMUM_METRIC to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit/s.
> 
>> Section 14
>> 
>> Suggest referencing the NHDP/OLSRv2 integrity draft.
> 
> I will do so.
> 
> Henning Rogge
> 
> -- 
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Straße 20, 53343 Wachtberg, Germany
> Telefon [phone],   Fax [phone]
> mailto:[e-mail] http://www.fkie.fraunhofer.de
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet