Subject: [Roll] Metrics draft, latency

From: <[email-masked]>
Date: Wed, 23 Jun 2010 14:49:17 +0200

Hello all,

The metrics draft currently specifies that latency shall be encoded as a
24 bit integer, expressing microsecond units.
This means that the maximum latency across a path is less than 17 s.

I think this is a problem. That's why I had proposed, in the thread
entitled "#18: Numeric Ranges in Routing Metric", to use units of 10
microseconds. This extends the maximum value to about 170 seconds.

I believe we don't need a resolution finer that 10 us. Even with links
of data speed in the hundreds of megabits per second, the first data bit
is not made available to the layer 3 until physical header and mac
headers are transmitted and decoded. Most often, with framing radio
chips, the first data bit is only made available to the microcontroller
when the full frame is succesfully error-checked or error-corrected and
interrupt code taken by the microcontroller. Most often, the MAC
protocol prevents from transmitting immediately because of access
contention (carrier-sense and turn-around time). All these real-life
constraint add to several microseconds, at best, with high speed radios.

If my arguments didn't convince you, then I'd rather we play it safe and
default to 32 bits, although I hate to see all those bytes wasted.

Dominique

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Wed, 23 Jun 2010 16:08:49 +0300

Metrics draft, latency

+1

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *
[email-masked]
*Sent:* Wednesday, June 23, 2010 3:49 PM
*To:* [email-masked]
*Subject:* [Roll] Metrics draft, latency

Hello all,

The metrics draft currently specifies that latency shall be encoded as a 24
bit integer, expressing microsecond units.
This means that the maximum latency across a path is less than 17 s.

I think this is a problem. That's why I had proposed, in the thread entitled
"#18: Numeric Ranges in Routing Metric", to use units of 10 microseconds.
This extends the maximum value to about 170 seconds.

I believe we don't need a resolution finer that 10 us. Even with links of
data speed in the hundreds of megabits per second, the first data bit is not
made available to the layer 3 until physical header and mac headers are
transmitted and decoded. Most often, with framing radio chips, the first
data bit is only made available to the microcontroller when the full frame
is succesfully error-checked or error-corrected and interrupt code taken by
the microcontroller. Most often, the MAC protocol prevents from transmitting
immediately because of access contention (carrier-sense and turn-around
time). All these real-life constraint add to several microseconds, at best,
with high speed radios.

Dominique

---

From: Nicolas DEJEAN <[email-masked]>
Date: Wed, 23 Jun 2010 15:18:05 +0200

+1

Nicolas.

---

From: "Cedric Chauvenet" <[email-masked]>
Date: Wed, 23 Jun 2010 15:41:32 +0200

Metrics draft, latency+1
  ----- Original Message ----- 
  From: Yoav Ben-Yehezkel 
  To: [email-masked] ; [email-masked] 
  Sent: Wednesday, June 23, 2010 3:08 PM
  Subject: Re: [Roll] Metrics draft, latency

  +1

  From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
  Sent: Wednesday, June 23, 2010 3:49 PM
  To: [email-masked]
  Subject: [Roll] Metrics draft, latency

  Hello all, 

  The metrics draft currently specifies that latency shall be encoded as a 24 bit integer, expressing microsecond units. 
  This means that the maximum latency across a path is less than 17 s. 

  I think this is a problem. That's why I had proposed, in the thread entitled "#18: Numeric Ranges in Routing Metric", to use units of 10 microseconds. This extends the maximum value to about 170 seconds.

  I believe we don't need a resolution finer that 10 us. Even with links of data speed in the hundreds of megabits per second, the first data bit is not made available to the layer 3 until physical header and mac headers are transmitted and decoded. Most often, with framing radio chips, the first data bit is only made available to the microcontroller when the full frame is succesfully error-checked or error-corrected and interrupt code taken by the microcontroller. Most often, the MAC protocol prevents from transmitting immediately because of access contention (carrier-sense and turn-around time). All these real-life constraint add to several microseconds, at best, with high speed radios.

  If my arguments didn't convince you, then I'd rather we play it safe and default to 32 bits, although I hate to see all those bytes wasted.

  Dominique 

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

  _______________________________________________
  Roll mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Jun 2010 15:46:17 +0200

Le 23/06/2010 14:49, [email-masked] a écrit :
> Hello all,
>
> The metrics draft currently specifies that latency shall be encoded
> as a 24 bit integer, expressing microsecond units. This means that
> the maximum latency across a path is less than 17 s.
>
> I believe we don't need a resolution finer that 10 us. Even with
> links of data speed in the hundreds of megabits per second, the
> first data bit is not made available to the layer 3 until physical
> header and mac headers are transmitted and decoded.

I don't understand the reasoning of local PHY and MAC delayed delivery.

ping runs very high above MAC and reports less than 10us RTT on a
certain wireless link; making it desirable to encode in a resolution
finer than 10us.

> Most often, with framing radio chips, the first data bit is only made
> available to the microcontroller when the full frame is succesfully
> error-checked or error-corrected and interrupt code taken by the
> microcontroller. Most often, the MAC protocol prevents from
> transmitting immediately because of access contention (carrier-sense
>  and turn-around time). All these real-life constraint add to several
>  microseconds, at best, with high speed radios.

You're kind of saying constrained devices will impose longer
communication latencies, which sounds logic... but would one contrain
this IP protocol to run only on constrained devices.

> If my arguments didn't convince you, then I'd rather we play it safe
> and default to 32 bits, although I hate to see all those bytes
> wasted.

Sidenote: compared to 24bit, 32bit encoding is fine for C too, because
it eases packet parsing to an "int", hton () exists for 32bit not 24bit,
etc.

One would consider an additional alternative of 32bit encoding and still
finer less-than-10us precision of encoding.

Alex

>
> Dominique
>
>
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 16:03:27 +0200

+1

De : Yoav Ben-Yehezkel [mailto:[email-masked]] 
Envoyé : mercredi 23 juin 2010 15:09
À : BARTHEL Dominique RD-TECH-GRE; [email-masked]
Objet : Re: [Roll] Metrics draft, latency

+1

Hello all, 

Dominique

---

From: Philip Levis <[email-masked]>
Date: Wed, 23 Jun 2010 08:23:32 -0700

+1

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 19:45:26 +0200

Makes a lot of sense, 10 microsecond resolution is in my opinion  
sufficient.

On Jun 23, 2010, at 3:08 PM, Yoav Ben-Yehezkel wrote:

> as a 24 bit integer, expressing microsecond units.
> header and mac headers are transmitted and decoded. Most often, with  
> framing radio chips, the first data bit is only made available to  
> the microcontroller when the full frame is succesfully error-checked  
> or error-corrected and interrupt code taken by the microcontroller.  
> Most often, the MAC protocol prevents from transmitting immediately  
> because of access contention (carrier-sense and turn-around time).  
> All these real-life constraint add to several microseconds, at best,  
> with high speed radios.
>
> and default to 32 bits, although I hate to see all those bytes wasted.
>
> Dominique
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Jun 2010 22:42:49 +0200

> Makes a lot of sense, 10 microsecond resolution is in my opinion

Would one be interested to hear that the link Bluetooth 3 HS targets
24Mbit/s data rate, dangerously approaching the max 10microsecond RTT
(i.e. half 'latency')... this could quickly obsolete the latency metric.

Bluetooth? because tightly related to 802.15.4, essential in 6lowpan, 
related to RPL.

Alex

>> *From:* [email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked] <mailto:[email-masked]>] *On
>> Behalf Of [email-masked]
>> <mailto:[email-masked]> *Sent:* Wednesday,
>> June 23, 2010 3:49 PM *To:* [email-masked] <mailto:[email-masked]>
>> entitled "#18: Numeric Ranges in Routing Metric", to use units of
>> 10 microseconds. This extends the maximum value to about 170
>> seconds.
>>
>>  header and mac headers are transmitted and decoded. Most often,
>> with framing radio chips, the first data bit is only made available
>> to the microcontroller when the full frame is succesfully
>> transmitting immediately because of access contention
>> (carrier-sense and turn-around time). All these real-life
>> If my arguments didn't convince you, then I'd rather we play it
>> safe and default to 32 bits, although I hate to see all those bytes
>> wasted.
>>
>> Dominique