Subject: [alto] Why should ordinal costs be integers?

From: Wendy Roome <[email-masked]>
Date: Tue, 27 Oct 2015 14:37:02 -0400

Here is a controversial question prompted by today's virtual meeting: Why
must ordinal costs be integers? Given that we do not require them to be
consecutive, and we do not require them to start with 1 (or 0), what is
the benefit to requiring them to be integers?

Note that JSON does not distinguish between integers and floating point,
and in the JSON libraries I've seen, numbers are always floating point.
When parsing JSON, libraries do not distinguish between 1 and 1.0. When
generating JSON, most libraries will generate 1, but a library could
generate 1.0.

I believe the difference between "numerical" and "ordinal" costs is in the
interpretation, not the format. Numerical costs have two properties
clients may find useful. First, numerical costs are scalable, while
ordinal costs are not. That is, suppose an ECS query returns the values
10, 11 and 100. If the costs are numerical, the client knows 10 is better
than 11 -- but not by much. And both are much better than 100. So the
client might randomly pick the cost 10 or cost 11 server. If the costs are
ordinal, the client knows 10 is better than 11, and 11 is better than 100.
But the client cannot tell whether 11 is close to 10, or close to 100, or
somewhere in the middle. So the client must select the cost 10 server.

The other property is that numerical costs are comparable between queries.
In our 10/11/100 example again, suppose that the client picked the server
with cost 11, and discovered that server was fast enough. Now suppose the
client sends another ECS query an hour later, for a different set of
servers. If the costs are numerical, the client can use its previous
experience to decide that any server with cost 11 or less is acceptable.
If costs are ordinal, the client cannot; the costs in the first query
cannot be compared to those in the second query.

RFC 7285 has oonly two references to ordinal costs as integers. The first
is {6.1.2.2}: "The values are non-negative integers". The second is
{11.3.2.4}: "... ordinal costs are not restricted to being sequential
integers". And that one is ambiguous: does that mean they must be
integers, just not sequential? Or does that mean ordinals are not required
to be integers?

	- Wendy Roome

---

From: Piotr Wydrych <[email-masked]>
Date: Tue, 27 Oct 2015 20:42:09 +0100

Hello Wendy,

> generating JSON, most libraries will generate 1, but a library could

Indeed, it may be an important issue in some specific use-cases. AFAIR 
if you have a Long field and (de)serialize it in Jackson (most popular 
Java JSON library), everything will work properly as data types are 
perfectly known. But if you switch to JavaScript, where all numbers are 
double-precision fp by definition, you won't be able to store an exact 
value lying outside the range [-(2^53)+1, (2^53)-1].

And as you've stated, a library may (non-intentionally) produce a map 
not conforming to JSON schema by generating `integers' like 1.0 or 1e2. 
(JSON schema differentiates "integer" and "number".) Such a map should 
be droppped by a client on validation or deserialization stages.

Best regards,
Piotr 'GhosT' Wydrych
-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 27 Oct 2015 15:55:45 -0400

Wendy, Piotr,

It makes sense to me for ranking to be integers. Using your example of
10,11,100, only comparisons make sense. Hence, if we want "minimal" field,
it will be non-negative integers. Although a dynamic typed language allow a
var to be int or float, a reasonable runtime will try to distinguish, as
floating point ops can be a lot more expensive than int ops.

I do agree that int or float is not essential. The key idea behind ordinal
is to allow networks a tool to reveal minimal information, as the good
example of 10,11, and 100 has shown.

Can you please take a look at the idea of allowing generic cost-mode. We
can have ordinal-float then :-)

Richard

On Tuesday, October 27, 2015, Piotr Wydrych <[email-masked]>
wrote:

> Indeed, it may be an important issue in some specific use-cases. AFAIR if
> you have a Long field and (de)serialize it in Jackson (most popular Java
> JSON library), everything will work properly as data types are perfectly
> known. But if you switch to JavaScript, where all numbers are
> And as you've stated, a library may (non-intentionally) produce a map not
> conforming to JSON schema by generating `integers' like 1.0 or 1e2. (JSON
> schema differentiates "integer" and "number".) Such a map should be
> droppped by a client on validation or deserialization stages.
>
> Best regards,
> Piotr 'GhosT' Wydrych
> --
> Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl ..
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wydrych.net_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DBw3LMYBZ3XvlHDexgPNVI93O2ALSfgTYNV1bOKFwv4&s=exzvHz7PjkJfxTQ0VeP5av8f4Vf9OMjuS-ySttvVIlQ&e=
> _______________________________________________
> alto mailing list
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DBw3LMYBZ3XvlHDexgPNVI93O2ALSfgTYNV1bOKFwv4&s=DDWVYo7-WDUHlD9JIdHzeymbcN7tNtVSBoSnInjXCLU&e=

-- 
Richard