With regard to e + m needs to add up to 12, the thing is that this is describing how the OLSRv2 draft came to be.
So (for our second attempt, but the first attempt is an ancient history red herring) we (actually, I, so I know exactly the thought processes that happened) went like this. We will use some form of modified mantissa/exponent. Not a pure one (that was attempt one) and not a crudely offset one (that some had suggested but was ugly). But the sequence of increments by 1, then by 2, then by 4 etc. seemed to have the right sort of properties, so I started there, and turned that into a formula. Now we had a request to make the metric a full 24 bits long (so that when aggregated over 255 hops it fitted 32 bits). And that lead to 2^e + m = 24. Now I looked at solutions (e,m) to that, and the ones that made any sort of sense were (3,16) and (4,8). Which led to 19 and 12 bit values. 19 is nasty (quite big) but 12 is OK. It's more than the 8 we previously had (but which didn't have a 24 bit range) but still allows us to do it in 2 octets (we have to have exact octets due to RFC 5444). And then something convenient clicked. We had 4 options, which can occur in combinations. Previously we were putting this information somewhere else (and ugly) compressed to 2 bits (as not all option combinations need be allowed for, but at an efficiency cost). But 12 is great, we can put all 4 in uncompressed in a 16 bit field. So that all fits together nicely, let's do that. But as you can see, 12 was not a precondition, but rather a result. It didn't seem necessary to spell all of that out even in a rationale draft. But to start with the a priori assumption of e+m = 12 would be both historically wrong, and a bad way to go. Because had the answer come to 13 we would probably have gone down a compressed 3 bit flags route (though with hindsight, I'm even more glad we didn't have to). -- 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: +44 1245 242194 | Fax: +44 1245 242124 [email protected] | 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 -----Original Message----- From: Suresh Krishnan [mailto:[email protected]] Sent: 25 April 2013 05:10 To: Dearlove, Christopher (UK) Cc: [email protected]; General Area Review Team Subject: Re: Gen-ART Telechat review of draft-ietf-manet-olsrv2-metrics-rationale-03.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Christopher, Thanks for your quick response. Trimming the stuff we agree on On 04/24/2013 05:18 AM, Dearlove, Christopher (UK) wrote: > Thank you for this, some comments below, marked CD> (Generally, where I > haven't commented, I think the point is good.) > >> -> Describe a short algorithm for converting a metric value into a >> compressed metric. i.e. Given a metric value x, how to obtain a and b >> from it. e.g. >> >> b=log2(x+256)-9 > CD> Such an algorithm is already in the OLSRv2 draft, it does not > seem necessary to repeat it. It could of course be referred to. Sounds good. Please add the reference to the OLSRv2 spec Section 6.2 for the conversion. >> * To achieve interoperability and to avoid loops, the values of e >> and m need to be the same across the network. The following sentence >> seems to allow for other values of e and m ("An appropriate >> pair..."). Suggest >> >> OLD: >> The required 24 bit limit can be achieved if 2^e+m = 24. An >> appropriate pair of values to achieve this is e = 4, m = 8. >> >> NEW: >> The required 24 bit limit can be achieved if 2^e+m = 24. Since >> e+m=12, solving for e and m will lead to e = 4, m = 8. > CD> The NEW text is incorrect, because it assumes e+m = 12 was an > input to the process. Rather those possible pairs that satisfied > 2^e+m = 24 were considered, and the preferred (e.m) pair selected, > which conveniently gave e+m=12. (I remember when first doing this, > and the satisfaction that it gave 12, which left the 4 bits we > wanted, but up to that point were doing differently, was great - > sometimes things do work out well.) So while the point that this is > fixed is good (but clearly in OLSv2 a single choice is used) > different alternative wording would be needed. Not sure what you mean here. The OLSRv2 link metric is 12 bits long according to the OLSRv2 draft. So e+m need to add up to 12, right?. In any case, go for any wording that works for you as long as it ensures that all the routers in the system will use the same value for e and m and the metric will fit in the OLSRv2 LINK_METRIC TLV. Thanks Suresh ******************************************************************** 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. ******************************************************************** _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
