Great discussion! I agree that the key value of ALTO services is that they are from the perspective of the application layer, hiding complexities due to those of the underlining network layer technologies, through ALTO abstractions.
I will post the new capacity region design schema shortly, as capacity region can be an important concepts for applications. Richard On Thu, Jul 7, 2016 at 12:50 PM, Greg Bernstein <[email protected] > wrote: > Hi Kai I think you make a very important point: > > A major concern might be how ALTO can distinguish itself from the > others. I think the value of ALTO is that it comes with > application-layer semantics. > > ALTO has already come out with the first standards to bridge the > application-network divide. It's a good time to enhance it for usefulness > with a good set of topology (and in my interest bandwidth aware) > extensions. If we wait too long then ALTO will miss the window to provide > guidance to an important emerging segment of the networking community. Qiao > et. al. will be publishing a draft on a protype system for big science > (LHC) data transfers that makes use of such information and their example > easily generalizes to other distributed "big data" applications. In > addition we have applicability within the data center and as a key > bandwidth/resource aware abstraction mechanism for SDN virtual networking > services. > > Cheers > > Greg B. > > On 7/7/2016 1:56 AM, Gao Kai wrote: > > Hi Richard, Greg and all, > > I think in some way, ALTO already has a graph representation. Consider > the cost map and the endpoint cost map provided by ECS, they are > basically full mesh graphs in the matrix representation, where the paths > between certain endpoint groups or hosts can be seen as virtual links. If > we look at the use cases such as peer/replica selection, they can be seen > as making "routing" decisions in those overlay graphs. So from my perspective, > the "topology extensions" are more like the efforts to generalize the ALTO > protocol. > > As Greg has mentioned, there are quite a few works on the "topology > extension" and many of us are still looking forward to pushing it > forwards. I'd very much like to contribute if the WG decides to go down > the path. > > A major concern might be how ALTO can distinguish itself from the > others. I think the value of ALTO is that it comes with > application-layer semantics. Right now we have endpoints and endpoint > groups, identified by IP addresses and prefixes, maybe later we can have > rendez-vous > points (capacity regions, shared risk links, etc.), relay points (caches, NAT, > VPN gateways, etc.) and even some NFV nodes. > > Regards, > Kai > > On 07/07/16 09:52, Y. Richard Yang wrote: > > 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 [email protected]https://www.ietf.org/mailman/listinfo/alto > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IlT_QTRUGRKzqZpezQQb0pfc1PfxQJjy5QNFX6SLsmU&s=se_PGzs-uyKxvjREWSQuPINwWxOFDAEusRRB23h_pIM&e=> > > > > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
