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