Re: [alto] Some considerations about path vector design

[Dawn Chan <[e-mail]>]

Hi Jensen and all,
Sorry for the late reply. Please see my comments inline.
On 7 Jun 2017, at 4:52 PM, Jensen Zhang <[e-mail]<mailto:[e-mail]>> 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:
- 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))
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?

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

Looking forward to any feedback.

Best regards,
Jensen