Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric

From: "roll issue tracker" <[email-masked]>
Date: Fri, 05 Mar 2010 10:36:25 -0000

#18: Numeric Ranges in Routing Metric
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  mjkim@…     
     Type:  defect              |       Status:  closed      
 Priority:  minor               |    Milestone:              
Component:  routing-metrics     |      Version:              
 Severity:  Active WG Document  |   Resolution:  fixed       
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Here is the resolution after discussion on the mailing list:

 It's time to close on the #18. I think that throughput and latency can
 be better presented by unsigned integers as the below justification
 wrote.
 Latency can be expressed in units of milliseconds and throughput can
 be expressed in bytes per second.

 Mijeom.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/18#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Mar 2010 11:39:41 +0100

Le 05/03/2010 11:36, roll issue tracker a écrit :
>   Latency can be expressed in units of milliseconds

But we just seemed to agree on micro-seconds instead, haven't we?

Alex

  and throughput can

---

From: MiJeom Kim <[email-masked]>
Date: Mon, 8 Mar 2010 10:24:06 +0900

Hi,

Actually, we were in the middle of discussion.
Let me resummerize the final options we have until now.

1. 16 bit unsigned integer --> it's not enough to express all cases
since 65535 micro seconds (65 milliseconds)
2. 24 bit unsigned integer
3. 1 bit indication bit (to indicate millisecond or mirocsecond) + 15
bit insigned integer --> the range can be from 0 microseconds to 32767
milliseconds.

Thanks,
Mijeom.

On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu
<[email-masked]> wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Mar 2010 11:45:50 +0100

Le 08/03/2010 02:24, MiJeom Kim a écrit :
> Hi,
>
> Actually, we were in the middle of discussion. Let me resummerize the
> final options we have until now.
>

Ok I guess we need to discard this.

> 2. 24 bit unsigned integer

This could represent

0..16777216   microseconds i.e.
0..16777,216  milliseconds i.e.
0.. 16,777216 seconds delay.

> 3. 1 bit indication bit (to indicate millisecond or mirocsecond) +
> 15 bit insigned integer -->  the range can be from 0 microseconds to
>  32767 milliseconds.

Right, the range of representation could be wider than with the 24bit
integer(?)

But there a same value could be represented by two different encodings.
  This makes comparisons for equality longer to write in C, requires
normalization before each comparison.

I.e. 1 millisecond could be represented by somebody as
1000micro-seconds, and when comparing the two values it's not sufficient
to simply compare the 16bit values received in messages, one has to
normalize first (similar to when one has to apply ntohs before every
comparison of shorts received from the wire).

Tradeoffs tradeoffs...

Alex

> Thanks, Mijeom.
>>> Type:  defect              |       Status:  closed Priority:
>>> minor               |    Milestone: Component:  routing-metrics
>>> | Version: Severity:  Active WG Document  |   Resolution: fixed
>>> Keywords:                      |
>>>
Changes (by jpv@…):
>>>
>>> * status:  new =>    closed * resolution:  =>    fixed
>>>
>>>
>>> Comment:
>>>
>>> It's time to close on the #18. I think that throughput and
>>> latency can be better presented by unsigned integers as the below
>>> justification wrote. Latency can be expressed in units of
>>> milliseconds
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>

---

From: MiJeom Kim <[email-masked]>
Date: Wed, 10 Mar 2010 10:57:14 +0900

Hi, Alex,

The problem you mentioned regarding option 3 can be easily solved. We
can just set the rule that whenever possible, using microsecond
instead of millisecond to give more information (precision). So upto
32767 miroseconds, uses microsecond and if latency becomes greater
than that, uses millisecond.
I had considered that removing the overlapping part, but that makes
the format more complicated.

Mijeom.

---

From: <[email-masked]>
Date: Wed, 10 Mar 2010 09:07:14 +0100

Hi all,

I disagree with option 3. This is just another "floating point" format, with a one-bit exponent and a 15-bit mantissa. If IEEE 16-bit FP was rejected, this one should be rejected for the same reasons.

Again, I favor option 2, but instead of microsecond increments, which is a resolution we don't need, I suggest using 10 us increments, which pushes the full range to about 168 seconds. Again, you can't measure the link latency with a resolution smaller than 10us, if only because of random back-off delays or mere electrical symbol duration.

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de MiJeom Kim
Envoyé : mercredi 10 mars 2010 02:57
À : Alexandru Petrescu
Cc : [email-masked]
Objet : Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric

Hi, Alex,

The problem you mentioned regarding option 3 can be easily solved. We can just set the rule that whenever possible, using microsecond instead of millisecond to give more information (precision). So upto
32767 miroseconds, uses microsecond and if latency becomes greater than that, uses millisecond.
I had considered that removing the overlapping part, but that makes the format more complicated.

Mijeom.

On Mon, Mar 8, 2010 at 7:45 PM, Alexandru Petrescu <[email-masked]> wrote:
> 1000micro-seconds, and when comparing the two values it's not 
> sufficient to simply compare the 16bit values received in messages, 
> one has to normalize first (similar to when one has to apply ntohs 
> before every comparison of shorts received from the wire).
>
> Tradeoffs tradeoffs...
>
> Alex
>
>>
>> Thanks, Mijeom.
>>
>>
>>>> --------------------------------+----------------------------------
>>>> --------------------------------+---------
>>>>
>>>>
>>>>
>>>>
> Reporter:  jpv@...               |        Owner:  mjkim@...
>>>>
>>>> --------------------------------+----------------------------------
>>>> --------------------------------+---------
>>>>
>>>>
>>>>
>>>>
> Changes (by jpv@...):
>>>>
>>>> It's time to close on the #18. I think that throughput and latency 
>>>> can be better presented by unsigned integers as the below

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Mar 2010 18:24:39 +0100

Le 10/03/2010 09:07, [email-masked] a écrit :
> Hi all,
>
> I disagree with option 3. This is just another "floating point"
> format, with a one-bit exponent and a 15-bit mantissa. If IEEE 16-bit
> FP was rejected, this one should be rejected for the same reasons.
>
> Again, I favor option 2, but instead of microsecond increments, which
> is a resolution we don't need, I suggest using 10 us increments,
> which pushes the full range to about 168 seconds.

That is a smart way of increasing the overall range, I think.

> Again, you can't measure the link latency with a resolution smaller
> than 10us, if only because of random back-off delays or mere
> electrical symbol duration.

Not sure about the impossibility of measuring a less-than-10us precision
of less-than 10us.  The linux kernel time struct (and tv in userspace)
is expressed in 1us precision range.

An off-the-shelf "ping" on linux on wired Ethernet 100Mbps reports RTTs
like "0.384 ms" which makes it for precision of units of micro-second.
The situation with a wireless 802.11g is similar.

YEs precise measuring should account for backoff delays and
electrical symbol representations too, with average and statistical
tools.

Alex

>
>
> Dominique
>
>
> -----Message d'origine----- De : [email-masked]
> [mailto:[email-masked]] De la part de MiJeom Kim Envoyé :
> mercredi 10 mars 2010 02:57 À : Alexandru Petrescu Cc :
> [email-masked] Objet : Re: [Roll] [roll] #18: Numeric Ranges in
> Routing Metric
>
> Hi, Alex,
>
> than that, uses millisecond. I had considered that removing the
> overlapping part, but that makes the format more complicated.
>
> Mijeom.
>
>
> On Mon, Mar 8, 2010 at 7:45 PM, Alexandru
> Petrescu<[email-masked]>  wrote:
>>> Actually, we were in the middle of discussion. Let me resummerize
>>> the final options we have until now.
>>>
>>> 1. 16 bit unsigned integer -->    it's not enough to express all
>>>  cases since 65535 micro seconds (65 milliseconds)
>>
>> 0..16777216   microseconds i.e. 0..16777,216  milliseconds i.e. 0..
>> 16,777216 seconds delay.
>>
>>> 3. 1 bit indication bit (to indicate millisecond or mirocsecond)
>>>  + 15 bit insigned integer -->    the range can be from 0
>>> microseconds to 32767 milliseconds.
>>
>> Right, the range of representation could be wider than with the
>> 24bit integer(?)
>>
>> But there a same value could be represented by two different
>> encodings. This makes comparisons for equality longer to write in
>> C, requires normalization before each comparison.
>>
>> sufficient to simply compare the 16bit values received in
>> messages, one has to normalize first (similar to when one has to
>> apply ntohs before every comparison of shorts received from the
>> wire).
>>
>> Tradeoffs tradeoffs...
>>
>> Alex
>>
>>>
>>> Thanks, Mijeom.
>>>
>>>
>>>>> minor               |    Milestone: Component:
>>>>> routing-metrics | Version: Severity:  Active WG Document  |
>>>>> Resolution: fixed Keywords:                      |
>>>>>
>>>>>
>>>>> latency can be better presented by unsigned integers as the
>>>>> below justification wrote. Latency can be expressed in units
>>>>>  of milliseconds
>>>>
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>>
>>>
>>
>>
>>

---

From: MiJeom Kim <[email-masked]>
Date: Wed, 17 Mar 2010 10:30:35 +0900

Hi,

Let's try to close on this ticket.
So, let's express latency metric with 24 unsigned integer in unit of
microsecond.
We don't need to restrict the increasing unit to 10 microsecond.
And throughput metric uses 32 unsigned integer to present bytes per second.

Thank you.
Mijeom.

---

From: Philip Levis <[email-masked]>
Date: Tue, 16 Mar 2010 22:44:37 -0700

> And throughput metric uses 32 unsigned integer to present bytes per  

Shouldn't latency be 32 bits as well? 24 bits means up to 2^4  
seconds. With low power link layers, that seems like close enough to  
be comfortable for now, but doesn't have a lot of space to grow.

Phil

---

From: MiJeom Kim <[email-masked]>
Date: Fri, 19 Mar 2010 13:06:17 +0900

How about we just leave it with 24 unsigned integer at least for now
since it's the result of the long discussion.
And 1 byte is pretty valuable here.

Mijeom.

On Wed, Mar 17, 2010 at 2:44 PM, Philip Levis <[email-masked]> wrote:
> Shouldn't latency be 32 bits as well? 24 bits means up to 2^4 seconds. With
> low power link layers, that seems like close enough to be comfortable for
> now, but doesn't have a lot of space to grow.
>
> Phil
>