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

From: Jensen Zhang <[email-masked]>
Date: Tue, 28 Feb 2017 20:22:14 +0800

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) <
[email-masked]> 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