Re: [alto] Graph representation format deliverable as WG item

["Randriamasy, Sabine (Nokia - FR)" <[e-mail]>]

Hi Dawn and Jensen, path-vector authors and all,

Thanks a lot for resuming the discussion on the “path-vector” mode. I also read your e-mails on the “Problems of encoding path-vector in multi-cost” discussions. Before answering, I needed to clarify on the proposed designs on path-vector.
So below I have some suggestions for the path-vector extensions design on which I would like your feedback.
I will feel more comfortable to resume the discussion on “Problems of encoding path-vector in multi-cost”, if I rely on the proposed design. I do not yet include the RSADE in this discussion.

Thanks,
Sabine


I rely on the presentation that was done at the IETF96 ALTO session in Berlin last July and exposes a different design for the , see https://www.ietf.org/proceedings/96/slides/slides-96-alto-6.pdf

Slides 16 and 17 expose responses with particular fields for the Filtered Cost Map service:
------------------------------------------------------------------
…
"cost-type" : {“cost-metric”: “ane”, "cost-mode" : ”path-vector” }
…
"cost-map" : {
"PID1": { "PID1":[], "PID2":["ne56", "ne67"], "PID3":[], "PID4":["ne57”]},
"PID2": { "PID1":["ne75"], "PID2":[], "PID3":["ne75"], "PID4":[]}, …
….
“nep-map”: (full nep values or reference to map in “meta”)
------------------------------------------------------------------

The design of the "cost-type" field looks more in line with the ALTO logics. A Cost Map exposing a sequence of “anes” hints that “the requested metric was “ane”. However, I understand that the motivation of the design proposed in https://tools.ietf.org/html/draft-yang-alto-path-vector-03 is to condense “bw” information with path vectors and avoid a separate query for “ane” properties.

So how about requesting sets of “ane” properties such as e.g. “bw” and “delay” by adding a filtering constraint in a Filtered Cost Map request? I think the same would hold for the Endpoint Cost Service.

The query for a FCM with the path-vector specific input could look as follows.
Forgive syntax errors and field names are examples.
------------------------------------------------------------------
POST /path-vector/costmap/filtered HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-costmap+json,application/alto-error+json
   Content-Type: application/alto-costmapfilter+json
   Content-Length: ###

   {
     "cost-type" :
       {"cost-mode": "path-vector", "cost-metric": "ane"},
     "ane-properties" : ["bw", "delay"],
     "pids" : {},
     "path-pids" : [
        {"srcs" : [ "PID1" ], "dsts" : [ "PID1", "PID2", "PID3", "PID4" ]},
        {"srcs" : [ "PID2" ], "dsts" : [ "PID1", "PID2", "PID3", "PID4" ]}
     ]
   }

------------------------------------------------------------------
The response would be as suggested by Richard’s presentation mentioned above.
With several (src, dsts) pairs in the input, we would not avoid introducing a new mime type, but the differences would be reasonable.

As for the option between including the “nep-map” and values or referencing it in the meta, it depends on the “nep-map” size. Specifying the input member names in accordance with the Unified Properties extensions proposed in https://tools.ietf.org/html/draft-roome-alto-unified-props-01 may allow a fast generation of request for “ane” properties values.


From: Jensen Zhang [mailto:[e-mail]]
Sent: mardi 28 février 2017 13:22
To: Randriamasy, Sabine (Nokia - FR) <[e-mail]>
Cc: Gurbani, Vijay (Nokia - US) <[e-mail]>; Y. Richard Yang <[e-mail]>; [e-mail]; [e-mail]; IETF ALTO <[e-mail]>
Subject: Re: [alto] Graph representation format deliverable as WG item

Hi Sabine,
I just noticed your were trying to resume this discussion. Thanks a lot for your effort! And I really would like to share my opinion about issue 2 since it is related to the flow-based design. See below:
On Sat, Nov 19, 2016 at 1:45 AM, Randriamasy, Sabine (Nokia - FR) <[e-mail]<mailto:[e-mail]>> wrote:
Hello authors of path vector and RSADE extensions and all,

Both drafts address several emerging use cases, in particular, the multi-path 1st hop, where each hop corresponds to a different choice of access technology.

I'd like to resume the discussion started in IETF96-Berlin upon Richard's presentation, see https://www.ietf.org/proceedings/96/slides/slides-96-alto-6.pdf

- issue 2 slide 12: multiple (S,D) pairs (with S and D = sets) in a query is more than useful.
Is there a way to allow this as well for "regular" ECS and F/CM ? Can we apply this to both "flows/endpoints" and "PID-paths" ?

- issue 2 design choices: a smooth transition would be using native cost maps with multiple input several (S,D) pairs.

If I get your point, you are suggesting to use the solution like this: (right?)
"cost-map": {
    "SPID1": {
        "DPID1": xxx
    },
    "SPID2": {
        "DPID2": yyy
    }
}
If so, it still cannot handle the fine-grained flow (such as L4 routing). Although Richard's presentation did not mention the fine-grained flow, it is the actual motivation of introducing flow-based design.
I think the most important use case of flow-based design is the central flow-level scheduling. It will often appear in the central controlled network like SDN. So the flow is usually fine-grained. I know introducing flow-based design is a big change for ALTO. But if it is really important, I think we need to try it out.

- Cost metric and mode for "ane-aware paths":
Slide 17 illustrates for a (S,D) pair: metric = "ane", mode = "path-vector" = array of N >= 1 "ane"
Other modes could be:
- mode = "path-graph", (multiple path-vectors - for RSADE or multi-choice paths)
- mode = "path-e2e" (single switch N=0 base ALTO mode usually not used),

You mean (mode = "path-graph") === (mode = "path-vector", metric = "ane")?


- conveying ane costs and properties (slides 15, 16, 17) on multi-hop maps:
In any case, ane property/cost services need to be specified and indicated in the IRD so that the client understands what "ne24" points to. So I suggest the anep-map to be systemetically referenced in the dependent-vtags. As for nep-map values:
- inline: information is self-contained and saves round trips but response may be heavy
- reference: ALTO Client gets anep map separately if needed.

If we don't use ane, "reference" can be accepted. Because every query can share the same network elements. But ane is computed from the query input of RSADE. e.g. Query1 may send request [(s1, d1), (s2, d2)] and get the response {f1: [ane1, ane2], f2: [ane2, ane3]}; Query2 may send request [(s1, d1), (s3, d3)] and get the response {f1: [ane1', ane2', ane3'], f3: [ane1', ane4']}. For f1, [ane1, ane2] and [ane1', ane2', ane3'] should be the same route, but the result computed by ALTO server may be different. So it is hard to be referenced in the "dependent-vtags".

How about letting a Server decide what option to propose?
A Server may even directly integrate the cost values in a multi-cost response, provided it has specified a anep-map and references it in its response.

I am thinking about this approach. But how can a client know which option the server are using? Maybe add this claim into the "capability" of the IRD entity?


If for instance a client requests  metric "BW" in "path-vector" mode, the protocol may request that it also requests metric "ane" in this mode (same for "path-graph" mode).

I think "ane" is not designed clearly. Let me resume the discussion about issue 1 here: how to encode the cost-type? Maybe we really need a unified cost schema.


Does this make sense ?

Thanks,
Sabine

Looking forward to receiving comments from authors. I think both drafts are still valuable. We need to update them.
Best,
Jensen