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 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
