Subject: [alto] Some considerations about path vector design

From: Jensen Zhang <[email-masked]>
Date: Wed, 07 Jun 2017 08:52:42 +0000

Hi all,

I am going to resume the discussion about graph representation and path
vector. After some attempts to adopt the path-vector extension, I have the
following considerations:

1. The current design is inefficient. Since IETF 98, we have agreed on the
design of a two-stage protocol extension (path-vector cost map + unified
property map) for graph representation. It is extensible enough because we
can customize the element (ane) properties. But the two-stage protocol will
conduct the long delay and increase the complexity of state maintenance.

2. The resource dependencies are not clear. The "Dependent Resources"
attribute in ALTO protocol is defined to claim the one-way resource
dependencies. But many resource dependencies should be bidirectional. e.g.
In path vector design, the cost map and the corresponding property map are
bound to the same query.

For 1, my personal idea is to deliver a service to accept a sequence of
queries. In this way, the client can query both cost map and property map
in a single request. And the server will handle the two-stage protocol
efficiently.

Here is a rough example:

request:
- resource: /alto/pv-costmap
  pids:
  - srcs: [xxx]
  - dsts: [yyy]
- resource: /alto/ane-prop-map
  query-id: $resource[0].$response.meta.queryId
  entities: $resource[0].$response.costmap.values.reduce(
            (x,y) => x.values.concat(y.values))

For 2, I have not found a good solution to handle the generic case.

Looking forward to any feedback.

Best regards,
Jensen

---

From: Dawn Chan <[email-masked]>
Date: Mon, 26 Jun 2017 09:08:22 +0000

Hi Jensen and all,
Sorry for the late reply. Please see my comments inline.
On 7 Jun 2017, at 4:52 PM, Jensen Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

I am going to resume the discussion about graph representation and path vector. After some attempts to adopt the path-vector extension, I have the following considerations:

1. The current design is inefficient. Since IETF 98, we have agreed on the design of a two-stage protocol extension (path-vector cost map + unified property map) for graph representation. It is extensible enough because we can customize the element (ane) properties. But the two-stage protocol will conduct the long delay and increase the complexity of state maintenance.

2. The resource dependencies are not clear. The "Dependent Resources" attribute in ALTO protocol is defined to claim the one-way resource dependencies. But many resource dependencies should be bidirectional. e.g. In path vector design, the cost map and the corresponding property map are bound to the same query.

For 1, my personal idea is to deliver a service to accept a sequence of queries. In this way, the client can query both cost map and property map in a single request. And the server will handle the two-stage protocol efficiently.

Here is a rough example:

request:
This design idea is a one-step service to get the cost map response and the property map response together in one request, which means it will return all the abstract network elements generated by one query. The effect of this design is probably same as the inline-mode that will directly return the properties of anes in the cost map, right?

Best regards,
Jensen

---

From: Jensen Zhang <[email-masked]>
Date: Mon, 26 Jun 2017 14:05:00 +0000

Hi Dawn,

Thanks for your reply. Comment inline.

Thanks,
Jensen

On Mon, Jun 26, 2017 at 5:08 PM Dawn Chan <[email-masked]> wrote:

> On 7 Jun 2017, at 4:52 PM, Jensen Zhang <[email-masked]>
> wrote:
>
> Hi all,
>
> This design idea is a one-step service to get the cost map response and
> the property map response together in one request, which means it will
> return all the abstract network elements generated by one query. The effect
> of this design is probably same as the inline-mode that will directly
> return the properties of anes in the cost map, right?
>
>
Not exact. The inline-mode pv design just provides one resource. This idea
proposes a complete grammar of a query language. The response contains
multiple resources. The PV query is just a special example. The design can
also be used in other query combinition, e.g. Network Map + Cost Map. And
the client can offload some computation on the server part.

---

From: Jensen Zhang <[email-masked]>
Date: Tue, 27 Jun 2017 09:10:46 +0000

I just realized that the example I took to explain how to
query pv-cost-map + ane-prop-map may make people confused.

Ideally, I hope to provide a general query service to handle some batch
query or some resource combination query. I want to know how many people
are interested in this idea or think it is useful. To make the discussion
more efficiently, I will post an initial draft to define the formal grammar
asap.

Best,
Jensen

On Mon, Jun 26, 2017 at 10:04 PM Jensen Zhang <[email-masked]>
wrote:

>> 1. The current design is inefficient. Since IETF 98, we have agreed on
>> the design of a two-stage protocol extension (path-vector cost map +
>> unified property map) for graph representation. It is extensible enough
>> because we can customize the element (ane) properties. But the two-stage
>> protocol will conduct the long delay and increase the complexity of state
>> maintenance.
>>