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] > <javascript:_e(%7B%7D,'cvml','[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=> >>> 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/%7Eyry/>http://www.cs.yale.edu/~yry/ | >> ===================================== >> >> >> > > -- > Richard > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
