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

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Mar 2010 17:25:32 +0100

Le 26/02/2010 09:32, MiJeom Kim a écrit :
> Hi,
>
> To summarize up to now, for latency metric,
>
> 1. Better to express both in millisecond and microsecond

Well I'd say better to express in micro-second and not in millisecond.
I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and
prefer an encoding saying "3002 milli-seconds", for the same value.

> 2. 2 bytes may be enough

Probably.

Do we have an idea of bounds?  What's the fastest link out there?
(6Gbps? OC optical)?  What's the slowest link?  (150baud?)

(yes people mentioned about devices with links with latency in the
  order of seconds, which I have yet to see.  But is that the link
  latency?  Or does it include the computer latency?  What's 'link
  latency anyways and at which layer is it measured (PHY, MAC, IP,
  app?)  These questions are commonly raised when measuring links.)

> 3. Floating point needs to be avoided

Somehow yes, I guess floating point is not necessary for encoding
bandwidth if we go with micro-second precision.

> So how about using 2 bytes with the first bit to express the unit
> (millisecond or microsecond) and the rest 15 bits for the value
> (unsigned integer)?

I don't understand why 15bits - what's one bit left for (the one up to
16)?  If we say "unsigned" then no need for sign bit.  I am not sure
what you mean by 15bits and not 16.
'
> And for throughput, for simplicity, how about using bytes per second
> presented by unsigned integer using 32 bits? That is my first
> suggestion.

I think that's ok for bandwidth.

> Regarding baud, I meant that given the same bandwidth, changing
> modulation methods (e.g. BPSK or QPSK) changes baud rate, but not
> bytes per second.

So we may need to encode a 1bit value saying BPSK or QPSK?

The baud suggestion (in addition to bandwidth of faster links) is that
because baud is typically used on slow links.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Mar 2010 18:43:22 +0100

> prefer an encoding saying "3002 milli-seconds", for the same value.
                                   ^^^^^
Sorry, I obviously meant 3002 micro-seconds.

Alex

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 22:09:23 +0100

Hi all,

Since you are calling for other's opinions, let me chime in here with my 2 cents.

I believe Floating Point, or any variation thereof (exponential representation, etc), is a pain for addition and for non-strict monotonicity reasons, as was already mentioned by Phil ( A + B = A when B > 0 ).

I believe we shouldn't worry about latencies less than about 10 us, because
- whatever the radio throughput (even megabits per second), the Rx-Tx turnaround time is still a few microseconds, the Carrier Sensing is many microseconds, and you usually need these to randomly send packets to your neighbors
- even at megabits/s speed, transmitting one useful data bit still requires several hundreds of framing/synch/control/correction bits, which translates to a latency of many microseconds
- many other, unpredictable, events cause latencies of that magnitude : medium access contention, microcontroller interrupt processing time

Sleeping MACs I've been exposed to commonly have wake-up periods of up to a few seconds. Ten seconds seems to be an extreme case. This means random pathes across the network would take n times a few seconds for n hops, given a reasonable ETX. If 10 hops is a reasonably long path, then about one minute of latency would cover all interesting cases.

>From one full minute downto a quantum of 10 microseconds, this means we need 22 bits with an uniform integer representation.
How about a 3-byte unsigned integer, expressing latency in units of 10us?
3 bytes seems like an odd size, but we already have a 3 byte routing object header (Object Type | Flags | Length), so it actually improves alignement ;-)

Regarding baud rates, I suggest to leave this to the Electrical Engineers. IETF shouldn't even know about modulation, electrical symbols and baud rates.
For large packets, bit rate and/or MAC wake-up period will determine latency. Modulation and spectral bandwith will only impact some delays (turn-around time, carrier sensing) that are marginal and better described with a constant than explicited in an IETF RFC.

Dominique

<historical note> The reason why old link technologies (100, 150, 300) are still refered to by their baud rates is because they placed one bit per symbol, ie bit rates were equal to baud rates, hence users would say "baud" as a fancy term for "bits per second". As PSTN modem technology evolved, bit rates grew (4800, 9600) while maintaining baud rates low (1200, 2400), because baud rate translates to spectral (audio) bandwith which was contrained by the telephone line technology. </historical note>

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alexandru Petrescu
Envoyé : lundi 1 mars 2010 17:26
À : MiJeom Kim
Cc : Yoav Ben-Yehezkel; [email-masked]
Objet : Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric

Well I'd say better to express in micro-second and not in millisecond.
I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and prefer an encoding saying "3002 milli-seconds", for the same value.

Probably.

> 3. Floating point needs to be avoided

Somehow yes, I guess floating point is not necessary for encoding bandwidth if we go with micro-second precision.

> (millisecond or microsecond) and the rest 15 bits for the value 

I don't understand why 15bits - what's one bit left for (the one up to 16)?  If we say "unsigned" then no need for sign bit.  I am not sure what you mean by 15bits and not 16.
'

The baud suggestion (in addition to bandwidth of faster links) is that because baud is typically used on slow links.

Alex

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: MiJeom Kim <[email-masked]>
Date: Tue, 2 Mar 2010 16:49:22 +0900

Hi, Alex,

I didn't mean to encode like "3milli-seconds and 2micro-seconds".
I suggested using 16 bits with 1 bit to indicate millisecond or
microsecond. Thus, using 15 bits for actual value. For example, if the
indication bit is 1, the rest 15 bits is used for the value of
millisecond. Otherwise, if the indication bit is 0, the 15 bits is for
the value of microsecond. This is pretty reasonable when the spectrum
of the metric value is way to wide as already mentioned several times.

Mijeom.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Mar 2010 18:04:14 +0100

:-)

Le 01/03/2010 22:09, [email-masked] a écrit :
[...]
> Regarding baud rates, I suggest to leave this to the Electrical
> Engineers. IETF shouldn't even know about modulation, electrical
> symbols and baud rates. For large packets, bit rate and/or MAC
> wake-up period will determine latency. Modulation and spectral
> bandwith will only impact some delays (turn-around time, carrier
> sensing) that are marginal and better described with a constant than
> explicited in an IETF RFC.

WEll, yes, it's good to leave these specs to specialized Electrical
Engineers; and a constant would be good too.  Baud rates I've seen are
expressed as doubling the pervious value: 150baud, 300baud, 600baud,
etc.  There's no intermediary value like 351baud.  I guess we could
encode them all as: 1 (for 75), 2 (for 150), 3 (for 300), and so on.

As a side note - I think baudrates are very fashionable :-)

I just stumbled on a recent small device guaranteed to run up to
10years autonomously on one AA-sized battery (thyonil is that?); it can
be queried by a laptop-USB and to which I must set the baudrate.

Also I have seen a device for which I had 4800baud over bluetooth and
another real recent - 38400baud.

That's what these thre user manuals asked me to do: set the baud rate.

The COM port specifications on Vista(!) are baud rate, stop bits,...

Alex

>
>
> Dominique
>
> <historical note>  The reason why old link technologies (100, 150,
> 300) are still refered to by their baud rates is because they placed
> one bit per symbol, ie bit rates were equal to baud rates, hence
> users would say "baud" as a fancy term for "bits per second". As
> PSTN modem technology evolved, bit rates grew (4800, 9600) while
> maintaining baud rates low (1200, 2400), because baud rate
> translates to spectral (audio) bandwith which was contrained by the
> telephone line technology.</historical note>
>
> -----Message d'origine----- De : [email-masked]
> [mailto:[email-masked]] De la part de Alexandru Petrescu
> Envoyé : lundi 1 mars 2010 17:26 À : MiJeom Kim Cc : Yoav
> Ben-Yehezkel; [email-masked] Objet : Re: [Roll] [roll] #18: Numeric
> Ranges in Routing Metric
>
> Well I'd say better to express in micro-second and not in
> millisecond. I'd avoid an encoding like "3milli-seconds and
> 2micro-seconds" and prefer an encoding saying "3002 milli-seconds",
> for the same value.
>
>> 2. 2 bytes may be enough
>
> Probably.
>
> I don't understand why 15bits - what's one bit left for (the one up
> to 16)?  If we say "unsigned" then no need for sign bit.  I am not
> sure what you mean by 15bits and not 16. '
>> And for throughput, for simplicity, how about using bytes per
>> second presented by unsigned integer using 32 bits? That is my
>> first suggestion.
>
> The baud suggestion (in addition to bandwidth of faster links) is
> that because baud is typically used on slow links.
>
> Alex
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
> ********************************* This message and any attachments
> (the "message") are confidential and intended solely for the
> addressees. Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. France Telecom Group shall
> not be liable for the message if altered, changed or falsified. If
> you are not the intended addressee of this message, please cancel it
> immediately and inform the sender. ********************************
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Mar 2010 18:05:52 +0100

Le 02/03/2010 08:49, MiJeom Kim a écrit :
> Hi, Alex,
>
> I didn't mean to encode like "3milli-seconds and 2micro-seconds". I
> suggested using 16 bits with 1 bit to indicate millisecond or
> microsecond. Thus, using 15 bits for actual value. For example, if
> the indication bit is 1, the rest 15 bits is used for the value of
> millisecond. Otherwise, if the indication bit is 0, the 15 bits is
> for the value of microsecond. This is pretty reasonable when the
> spectrum of the metric value is way to wide as already mentioned
> several times.

Ah, in this sense I understand that 1/0 bit.

The only thing left is to ensure this encoding does cover appropriately
the range of values we know we need.

Alex

>>> So how about using 2 bytes with the first bit to express the
>>> unit (millisecond or microsecond) and the rest 15 bits for the
>>> value (unsigned integer)?
>>
>>> modulation methods (e.g. BPSK or QPSK) changes baud rate, but
>>> not bytes per second.
>>