Let me add one note. Please see below.
On Wednesday, July 6, 2016, Y. Richard Yang <[email protected]> wrote:
Greg,
Nice discussion!
On Wednesday, July 6, 2016, Greg Bernstein
<[email protected]> wrote:
Hi Richard, your coding of the initial design looks fine.
However we did a lot of work in the past and the effort
within the ALTO WG stalled. This did not seem to be due to
technical disagreements by various draft authors (folks
seemed fairly flexible and in rough consensus), but rather to
the WG not wanting to move in this direction at the time.
My understanding is that other extensions may need to be handled
first. The timing on topology can be right.
I'm not sure what is the best way forward with topology
extensions. Various working group participants have produced
drafts over the years that clarified the problem statement,
looked at and justified two major "architectural
alternatives", worked on some encoding details, and wrote up
some advanced work (the "A Routing State Abstraction Service
Using Declarative Equivalence" draft) based on the potential
topology extensions.
Before putting in a bunch more time and effort it would be
good to know where the WG wants to go with these extensions.
As we've discussed such extensions are very valuable in the
SDN realm for network virtualization (with flexible network
information disclosure). Either adopting a draft on topology
extensions as a WG document or chartering a design team to
write a series of documents would get my renewed participation.
Network graph is a chartered WG item, and hence is becoming a
higher priority, as other items move forward.
Here is my current thinking/reasoning on topology/routing state
abstraction for application traffic optimization:
1. alto is somehow not allowed to change network state, which
somehow (not fully but quite likely) imply that routing is given;
2. Given that routing is given, what application can do is its
traffic scheduling. Assume that the application has a set of
flows F = {f1, f2, ..., f_|F|}. If routing is given, many
properties (e.g., propagation delay) of flow i are given. What
application is given to control is x1, x2, ..., x_|F|, where xi
is the amount of traffic for flow i. Let x = [x1, ..., x_|F|] be
the vector. Then what application can do is to select the value
of x. Curren ALTO (rfc7285) already can provide the properties of
the routing path of each flow i. The main missing is the
**capacibity region** of x due to correlation among flows. The
motivating example we presented is always this case. For example,
the dumbbell example is this case: flow 1 can get 10, flow 2 can
get 10, but what if the two flows together? In other words, the
capacity region can be a complex polytope. What we mean routing
path abstraction is mostly to provide this info, which is a
highly important network info for application optimization.
The only other case beyond capacibity region is shared risk link
group. But this may not need to reveal topology---each flow reveals
the set of risk labels can do. Make sense?
Richard
If we agree with the preceding essence, we can have a pretty
precise, concise spec. Make sense?
Richard
Cheers
Greg B.
On 7/6/2016 9:52 AM, Y. Richard Yang wrote:
Greg, all,
I read the paper and found it highly relevant, for the
convergence of our network graph/path vector design. Here,
let us start with the initial design, before getting into
the details of json encoding. Any feedback will be greatly
appreciated.
- Path-vector request:
src/dest pairs; and optionally, for each pair, additional
hint information such as demand, requirement metrics
Requested properties of network elements
- Path-vector response:
Path vector for each src/dst pair, where each element in a
path vector is an abstract network element
A description of the properties of each network element.
Example:
Req:
src/dst pairs: {s1 -> d1, demand = 10, latency < 20 ms},
{s2 -> d2, ...}
properties: available-bw, cost
Response:
s1 -> d1: "e1", "e2", ...
...
"e1" properties: available-bw = 10, cost = 3,
...
The preceding does not handle the case of query topology,
but I feel that path vector, which essentially assumes that
routing is given and no need to worry about path
compressions, is a good, clean start.
Does the preceding missing anything?
Richard
On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein
<[email protected]> wrote:
Hi all since some of our original Internet Drafts
association with ALTO "topology extensions" our well out
of date, those that are interested may want to look at a
technical paper that Young and I put together back in
2012
(https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e=
). This has motivations, concepts, alternative
representations and color highlighted figures to aid in
comprehension. We also have the short (11 slide)
presentation that we gave at the Vancouver 2012 IETF for
those that never saw it or need to job their memory.
Cheers
Greg B.
On 7/5/2016 10:27 AM, Vijay K. Gurbani wrote:
On 07/05/2016 12:25 PM, Y. Richard Yang wrote:
Vijay,
Please see inline. [...] OK. We should target
posting a spec by this
Friday so that we can discuss the spec before
the meeting, to remove
any confusion/bewilderment. Since the key piece
is encoding
specification of (1) graph; and (2) path vector
associated w/ a
graph. We will target posting those spec,
precisely first.
Richard: Awesome! Thanks.
- vijay
_______________________________________________
alto mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=-othJunl7gz_02BM9c1kqLPhFmI2iJr3vD6gu41kd_w&e=
--
--
=====================================
| Y. Richard Yang <[email protected]> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
--
Richard
--
Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
