Subject: [alto] Defining classes for ALTO cost types

From: Wendy Roome <[email-masked]>
Date: Fri, 29 Jul 2016 12:33:13 -0400

Here's another approach to value schemas for ALTO. Suppose we define value
classes. A value class specifies the JSON representation of those values.
Examples include

duration: Numbers, in seconds, or numeric strings such as 10ms, 12.5us,
1:23, etc.

bandwidth: Numbers, in bytes/sec, or numeric strings with unit suffixes.

date-range: Strings with Start & End dates in (say) ISO 8601 format.

numerical: Numbers whose values are scalable & proportional. If a map has
the values 1, 2 & 10, the client knows that 2 is much closer to 1 than 10.

ordinal: Numbers that are not scalable. If a map has the values 1, 2 & 10,
2 may be close to 1, or it may be close 10, or it may be in the middle.

utilization: A number between 0 and 1. Or alternatively, a numeric string
with a % suffix.

Each value class can have a corresponding OO class. The constructor takes
a JSON value and parses it. The class provides the appropriate getter
methods.

This class mechanism could also handle per-value attributes like
confidence (see FCS) or tolerance (+/-).

The classes are defined by RFC extensions and are grouped into class sets.
Each set has a unique name. Set names are registered (new IANA registry).
Class names within a set are *not* registered (no need). Let's say the
initial set is named alto-core-classes, and includes the above classes.

Note that value classes are orthogonal to cost metrics. Consider the
metrics in draft-wu-alto-te-metrics-08. delay and jitterdelay are the
duration class. maxbw, availbw, etc, are bandwidths. pktloss is a
utilization.

The class defines the format of the value. The metric defines the
semantics of the value.

Incidentally, the same classes could be applied to property values.

The meta section of a cost map response has the value class and class set
as well as the cost-metric name. E.g.:

meta:
  cost-type:
    cost-metric: delay
    value-class-aet: alto-core-classes
    value-class-name: bandwidth
    cost-mode: numerical  ## redundant; value-class implies mode
cost-map:
  pid1:
    pid1: 0, pid2: 10ms, ...

Key point to future-proof this: if the client does not recognize the class
set and class name, the client MUST ignore the response. This allows us to
define new classes without breaking legacy clients.

Is this worth pursuing? This would make it much easier to introduce cost
metrics that are not simple numbers

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 29 Jul 2016 21:49:53 +0000 (UTC)

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; }  Wendy,
Very interesting proposal.

So my understanding is that the scheme replaces cost-mode with a new attribute named value-class. A value-class has two members: set (aka package to me) and name. Is this a way to understand the scheme? If so, how about use cost-mode as value-class, since it already exists? Or I do not fully understand the design yet?
Thanks!
Richard 
On Saturday, July 30, 2016, 12:33 AM, Wendy Roome <[email-masked]> wrote:

meta:
  cost-type:
    cost-metric: delay

    - Wendy Roome

_______________________________________________
alto mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=Kx4S2C6KpukNjE_ZBMDDkDv_xW8OaCExfxQdWNK0AXI&s=THXA4VsCkt015sIKH9htcoP_G0bw1IyBE8KPR77L65A&e=

---

From: Wendy Roome <[email-masked]>
Date: Fri, 29 Jul 2016 20:09:01 -0400

Richard,

That's the basic idea, modulo field names. Think of my proposal as extending cost-mode to be an extensible specification of the value format. The numerical and ordinal classes I described correspond to the current numerical and ordinal modes.

And a key point is that clients MUST ignore a cost type unless they recognize the cost-mode name.

However, there are three reasons not to use the field name cost-mode. One is that 7285 says cost-mode is numerical or ordinal. Period. No extensibility. So legacy clients will get confused by new modes.

The other is this is really a general value type, where values can be things other than costs. Including property values.

And finally, "mode" is misleading. It's more a class or a format.

This would require new media types for cost maps, end costs and end properties. But I am afraid we need those anyway for costs that are not simple numbers. The good news is this would allow us to define new value types for maps without creating any more media-types and without jumping thru hoops to hide them from legacy clients.

      - Wendy Roome

> On Jul 29, 2016, at 17:49, Y. Richard Yang <[email-masked]> wrote:
> 
> Wendy,
> 
> https://www.ietf.org/mailman/listinfo/alto