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 protected]> wrote:
>
> 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 protected]> wrote:
>
> 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
>
>
>
> _______________________________________________
> alto mailing list
> [email protected]
> 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=
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
