Re: [alto] Opsdir last call review of draft-ietf-alto-cost-calendar-16

["Y. Richard Yang" <[e-mail]>]

Thank you so much, Jürgen!

The WG decision is to use a single unit and hence to allow scaling below
the chosen unit, we have to deal with float. As much as we thought 1 second
is typically the smallest, from my understanding, some use cases from a
major app developer is already below this. We will revise the sentences to
be reasonable and check with you to finalize say by Wednesday the latest.

Thanks again,
Richard

On Mon, Feb 24, 2020 at 4:55 AM Schönwälder, Jürgen <
[e-mail]> wrote:

> I will remove all closed issues and comment further inline.
>
> On Fri, Feb 21, 2020 at 03:54:30PM -0500, Y. Richard Yang wrote:
>
> > > > > - Since you write "SHOULD at least IEEE 754 double-precision
> floating
> > > > >   point", does this not make the IEEE 754 reference a normative
> > > > >   reference?
> > > >
> > > >
> > > > ----- [[SR]] The text follows RFC7285, section 11.3.2.3,  in which
> IEEE
> > > 754
> > > > is an informative reference and cited with a SHOULD.
> > > > ----
> > >
> > > On second thought, I wonder whether you really want to mandate how a
> > > value is 'stored'. Perhaps you wanted to require 'SHOULD use at least
> > > support IEEE 754 double-precision floating point [IEEE.754.2008]
> > > precision'.
> > >
> > > Note that several lines up you suggested to change to integer, but I
> > > am not sure you wanted that - please double check that you get this
> > > right. Anyway, since you refer to properties of a concrete formats
> > > defined in another document, it seems to me the reference is actually
> > > normative.
> > >
> > > <soap>
> > > In general, I find the double precision requirement a bit irritating
> > > given the large range of numbers doubles can represent (roughly from
> > > 2.2x10^-308 to 1.8x10^308). And yet, many practically useful numbers
> > > such as 0.1 can't be represented exactly as floating point numbers,
> > > i.e., there is always rounding involved, making comparisons rather
> > > complicated.
> > >
> > > Often people want to have doubles in the hope that this maximizes the
> > > chances of not getting hit by rounding issues but the sad truth is that
> > > floating point numbers remain dangerous.
> > > </soap>
> > >
> > >
> > Totally agree. It is interesting that you use the 0.1 second example. I
> > assume that you have the classical Patriot 0.1 second rounding bug in
> mind (
> > https://www.viva64.com/en/b/0445/), which is quite close to our setting,
> > where 0.1 is their interval size, although I do not foresee that ALTO
> cost
> > calendar will be used in such a setting :-)
> >
> > I believe that the initial design used only integers, with a unit (s, ms,
> > ns, ...) to avoid the floating-point issue (instead of 0.1 sec, it is 100
> > ms), and then the feedback and WG decision is to use generic floating
> > points to have a more uniform, single unit (second) design. One proposal,
> > which I am not sure others like, is to use a smaller unit, say ms, and
> then
> > most likely we will deal with only integers (in the range of [-(2**53)+1,
> > (2**53)-1]) and can still handle smaller units should the setting arise.
> > The downside is that there might be more zeros if the interval is longer
> > (60 sec -> 60000 ms). What do you think?
> >
> > Another possibility is to keep the current design but add some text to
> > discuss the precision issue. A Proposal is the following:
> >
> > "time-interval-size":
> >
> >       *  is the duration of an ALTO Calendar time interval in seconds.
> >          A "time-interval-size" value contains a JSONNumber.  ALTO
> >          Servers SHOULD use at least IEEE 754 double-precision floating
> >          point [IEEE.754.2008] to store this value.  Example values are:
> >          300 , 7200, meaning that each Calendar value applies on a time
> >          interval that lasts 5 minutes and 2 hours, respectively.
> >
> > =>
> >
> > "time-interval-size":
> >
> >       *  is the duration of an ALTO Calendar time interval in seconds.
> >          A "time-interval-size" value contains a JSONNumber.  Example
> > values
> >         are: 300 , 7200, meaning that each Calendar value applies on a
> time
> >          interval that lasts 5 minutes and 2 hours, respectively. Since
> the
> >         interval size can be smaller than 1 second (e.g., 100 ms), the
> > value
> >         specified can also be a floating point (e.g., 0.1). Both ALTO
> > clients and
> >         servers should be aware of potential issues caused by the
> precision
> >          issues caused by using floating point numbers. For example,
> >          the server may have an internal, integer representation in ms,
> and
> > store
> >         100 as an int (0.1 sec) in the local storage; the sever sends
> "0.1"
> > as
> >         the interval size to the client; the client may use a
> float/double
> > to store
> >         the JSON number, which may not represent 0.1 precisely. To
> improve
> >         interoperability, the server and the client SHOULD use IEEE 754
> >         double-precision floating point [IEEE.754.2008] to store this
> > value, in unit
> >        of seconds.
> >
> > I am a bit ambivalent of the last sentence though.
>
> This is something the WG has to discuss and decide. If the WG can find
> agreement that there is a smallest sensible unit (e.g., milliseconds
> or microseconds), then I personally would find it reasonable to
> implement this specification by storing values in an integral type of
> this smallest sensible unit internally (if the WG does not want to use
> integral numbers of that type). Hence, for me personally, a statement
> how implementations SHOULD store values goes too far as this is an
> implementation concern.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
-- 
Richard