Subject: [alto] A unified approach to value schemas and ALTO maps

From: Wendy Roome <[email-masked]>
Date: Tue, 26 Jul 2016 13:38:06 -0400

Recently we talked about using "value schemas" so that we can add new
value types without defining new media types and message formats.

Here is another take on that approach. It unifies *everything* into one
common message format. Extensions simply require defining new entity
domains and (simple) value types.

So here's my idea. Every ALTO resource boils down to a mapping from 1-,
2-, 3- or 4-tuples to values. The tuple elements are names of entities in
a domain.

Examples:
   Cost Map: (pid, pid)  =>  value
   Endpoint Costs:  (addr, addr) =>  value
   Endpoint Props:  (addr, prop-name)  =>  value
   MultiCost Map:   (pid, pid, cost-type)  =>  value
   MultiCost Calendar Map: (pid, pid, date-range, cost-type)  =>  value
   Network Map:  (cidr)  =>  pid

Note that I flipped the network map around. I think cidr => pid is cleaner
than pid => cidr-array, and it enforces the rule that a cidr is in only
one pid.

With this approach, the meta section of a response would give the domain
for each tuple element, and the value type. For example, here is a
conventional cost map:

   meta:
      tuple-domains: [pid, pid]
      value-type:
         specification: rfc7285
         format: cost-type
         parameters:
             metric: routingcost, mode: numerical
   map:
      pid1:
         pid1: ###,  pid2: ###, ...

The value field gives document that specifies this value format (or a
registered name), a format name that is defined in that document, and any
additional parameters necessary to understand this value.

Here is a multi-cost map:
   meta:
      tuple-domains: [pid, pid, cost-type-name]
      value-types:
         3:
            cost:
               specification: rfc7285
               format: cost-type
               parameters:
                 metric: routingcost, mode: numerical
            delay:
               specification: rfc####
               format: duration
               parameters:
                  metric: propagation-time
   map:
      pid1:
         pid2:
            cost: 123, delay: 2ms

Here the different cost types have different value types. meta.value-types
means that the value depends on the 3d element of the tuple - the
cost-type-name - and gives the value format for each cost-type-name.

So are people interested in pursuing this approach? The good news is that
will unify everything. The bad news is it will replace everything in rfc
7285.

    - Wendy Roome

---

From: Jensen Zhang <[email-masked]>
Date: Wed, 27 Jul 2016 09:18:49 +0800

Hi Wendy,

I want to support this idea. Please see comments inline.

> than pid => cidr-array, and it enforces the rule that a cidr is in only

Agree. And maybe another benefit from cidr => pid is for incremental
update. Once a cidr changes its pid, pid => cidr-array will require an
update of the whole cidr-array. But cidr => pid only requires an update of
one pid item.

> additional parameters necessary to understand this value.

The specification metadata is very interesting and I like this design. But
I don't think RFC is the good solution for the specification citation. RFC
is human-readable, but it is hard for programs to parse RFC documents.
Maybe we find a schema language (or JSON schema) to specify the value
format.

>       tuple-domains: [pid, pid, cost-type-name]

Is this a typo? Or what's the mean of '3:' here?

> cost-type-name - and gives the value format for each cost-type-name.

It is also more flexible for incremental updates.

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

I find this approach is also compatible with FCS, since FCS returns a fid
=> value map currently. I'd like to push it forward.

One more question: I think (src, dst) => cost map and (dst, src) => cost
map will have the same "tuple-domains" value, but they are different for
clients. How to differentiate them?

Best,
Jensen

---

From: Wendy Roome <[email-masked]>
Date: Wed, 27 Jul 2016 09:38:38 -0400

Jensen,

Thanks for commenting!  My responses are in-line.

> From:  Jensen Zhang <[email-masked]>
> Date:  Tue, July 26, 2016 at 21:18
> Subject:  Re: [alto] A unified approach to value schemas and ALTO maps
> 
> Hi Wendy,
> 
> On Wed, Jul 27, 2016 at 1:38 AM, Wendy Roome <[email-masked]>
> wrote:
> Agree. And maybe another benefit from cidr => pid is for incremental update.
> Once a cidr changes its pid, pid => cidr-array will require an update of the
> whole cidr-array. But cidr => pid only requires an update of one pid item.

Exactly! 

> The specification metadata is very interesting and I like this design. But I
> don't think RFC is the good solution for the specification citation. RFC is
> human-readable, but it is hard for programs to parse RFC documents. Maybe we
> find a schema language (or JSON schema) to specify the value format.

Okay, here is where I respectfully disagree. I do not believe a
program-readable schema will help.

Why not? First, JSON is self-describing. An ALTO client does not need a
schema to parse JSON. JSON libraries do that on their own. The JSON
libraries I¹ve used build a DOM from the JSON and allow client programs to
explore that DOM.

IMHO, formal schemas have two uses. One is to allow a program to verify that
a given JSON tree matches the schema. However, if the server¹s response does
not match the schema, what can a client do about it, other than give up on
that ALTO server?

The other is to document the layout, and (maybe!) facilitate automatically
creating a program, or at least a skeleton of a program, to program with
that data. But no ALTO client is doing to do that on-the-fly. That happens
off-line, when the programmer decides how the client will use an ALTO
server.

I believe the important thing is to specify the semantics. E.g., what do
these values mean? For example, take ordinal vs numerical mode. You cannot
capture the difference in a schema.

As another example, consider duration values. Frequently durations have
suffix with the units: 10s, 1.23ms, 15us, etc. Or they have colons, as in
1:23.4. A grammar can define the legal values, but unless the programmer
knows "ms" means milliseconds, the grammar does not help.

So I believe values will have to be described by some document, which may
have a formal schema. The document will define some unique name to identify
values of this kind, and ALTO clients will switch on that name. The name
could be rfc####, or it could be yet another IANA registry, or whatever.
> Is this a typo? Or what's the mean of '3:' here?

The 3 means the value-type depends on the value of the third tuple element -
the cost-type. But now that I look at it again, that is overly general. It
is probably sufficient to say that either all values are the same type, or
else the value type depends on the value of the last element in the tuple.
E.g., cost-type, property-name, etc.
> I find this approach is also compatible with FCS, since FCS returns a fid =>
> value map currently. I'd like to push it forward.
> 
> One more question: I think (src, dst) => cost map and (dst, src) => cost map
> will have the same "tuple-domains" value, but they are different for clients.
> How to differentiate them?

Because the domains in the tuples are ordered. E.g., in a cost map, the
first domain is always the source and the second is the destination.
> Jensen

Thanks! Let's keep the discussion going. Anyone else like to comment?
Richard??

- Wendy Roome

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Jul 2016 08:44:01 -0500

[As individual]

> will unify everything. The bad news is it will replace everything in rfc

Wendy: "Replace" how?  By making rfc7285 obsolete?  If the approach
outlined will not be backwardly compatible to rfc7285 then I think we
should tread with caution.  I don't think it will be in our interest to
obsolete rfc7285 at a time when there appears to be arising interest in
it.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: [email-masked] / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Wendy Roome <[email-masked]>
Date: Wed, 27 Jul 2016 10:10:46 -0400

Vijay,

It would not obsolete rfc7285, but it would deprecate much of it. An ALTO
server would continue to provide network maps, cost maps, ECS, EPS, etc,
as in 7285.

But new work & extensions would use the new presentation scheme.

The new format resources can co-exist in the IRD with the rfc7285
resources. Ideally, an ALTO server would provide cost map resources in
both old & new formats, via different resource entries in the IRD.

I see it as replacing rfc7285 in the same way the ipv6 "replaces" ipv4. :-)

	- Wendy Roome

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Jul 2016 09:58:05 -0500

[As an individual, of course]

On 07/27/2016 09:10 AM, Wendy Roome wrote:
> Vijay,
>
> It would not obsolete rfc7285, but it would deprecate much of it. An
> ALTO server would continue to provide network maps, cost maps, ECS,
> EPS, etc, as in 7285.

Deprecating rfc7285 is not a viable option at this point, at least in my
opinion.  I think this will add a level of uncertainty to pending work
that may be detrimental and slow down the progress that we witnessed at
the Berlin IETF.

I am not being obtuse, of course, just pragmatic.

> resources. Ideally, an ALTO server would provide cost map resources
> in both old & new formats, via different resource entries in the
> IRD.

Ultimately whether to go this route is something that the WG will have
to decide collectively, but my personal opinion is that "here there be
dragons" :-)

Cheers,

- vijay

---

From: Wendy Roome <[email-masked]>
Date: Thu, 28 Jul 2016 08:49:55 -0400

Vijay,

Yes, I realized that "here be dragons." :-)

So how about recasting this discussion as format for *new* ALTO services,
like FCS & topology, but leave the existing cost & network maps as they
are?

Of course, if this new approach becomes popular, we might just happen to
notice that it would simplify the existing cost and net maps as well.

	- Wendy Roome

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Jul 2016 13:24:33 -0500

[As individual]

On 07/28/2016 07:49 AM, Wendy Roome wrote:
> So how about recasting this discussion as format for *new* ALTO
> services, like FCS & topology, but leave the existing cost & network
> maps as they are?

Wendy: That would be the gentler alternative.  However, so far it's
been a closed conversation between the both of us.  It'll be nice to
hear views from other denizens of the WG.

> Of course, if this new approach becomes popular, we might just happen
> to notice that it would simplify the existing cost and net maps as
> well.

Success does have its own problems :-)

Cheers,

- vijay