On Tue, Oct 29, 2013 at 1:03 PM, Reinaldo Penno (repenno) <[email protected] > wrote:
> > > On 10/29/13 9:01 AM, "Vijay K. Gurbani" <[email protected]> wrote: > > >On 10/28/2013 11:13 PM, Reinaldo Penno (repenno) wrote: > >> In the particular fcc MBA context, a concrete example is to change the > >> subscriber tier (end point property). But since you mentioned map, I > >> guess you are saying e2e (e.g., more narrowly bounded app flow). > >> > >> [RP] hummmŠNot necessarily e2e. If I write to a map and change the cost > >> of reaching the IP address associated with my application, I need to > >> be put in a different PID. I believe the same is true for endpoint > >> properties if you want to actually influence the cost map. > > > >Reinaldo: Interesting ... you are proposing an alto.put() mutator, > >whereas what we have now is mostly alto.get() accessors. > > > >Once we do this, we are perilously close to sdn/i2rs type of thinking > >(I think). > > Right > > I wonder how far we can get close to sdn/i2rs and still be safe. It is an issue that the WG may need to discuss. As someone who works in both ALTO but also in SDN (a bit self promotion: our Maple SDN controller is getting attention), I see ALTO as a good place to contribute to SDN, not the whole SDN space, but a good part of the North Bound API. > >However, if I understand you correctly, you are advocating > >a bounded alto.put() functionality ... perhaps an endpoint migrating to > >a different PID. I don't think you are advocating a wholesale > >application-specified state insertion into the network. > > Something like that: "Is there a PID with low latency? I want to be > there". The app itself does not need to know anything about the network > per se. > > This can be a base for an interesting API, and choosing-PID can be more general than writing to endpoint properties in settings. Here is a sketch of a use case, in the decision instead of search formulation (using NP terms) and what the API might look like: - We define two sets of PIDs, candidate assignment PIDs say cPIDs (implemented by priority, or rate limit, ... or whatever non-disclosed internal mechanism), and target PIDs (defining country blocks, ASes, bw tiers, well-known service blocks...) say tPIDs. - The ALTO Server announces the metrics, in particular, from cPIDs to tPIDs. - Client requests an assignment to its cPIDs. Hence, the preceding ties ALTO Cost Map to a menu based service selection API. This is quite interesting! Richard >The use of ALTO in scenarios that require changing the basic networking > >plumbing has been discussed in academic papers, at least (at the cost of > >a self reference, see [1]). There has been some discussion in the ALTO > >mailing list of such functionality as well, but to date my impression > >is that such discussion has been limited due to the overlap between > >sdn/i2rs type of work. > > > >[1] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V., > > "Abstracting network state in Software Defined Networks (SDN) for > > rendezvous services," accepted for publication. In Workshop on > > Software Defined Networks (SDN), held in conjunction with IEEE > > International Conference on Communications (ICC), pp. 6627-6632, June > > 2012. > > > Will read it sir. > > > > >Thanks, > > > >- vijay > >-- > >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > >Email: vkg@{bell-labs.com,acm.org} / [email protected] > >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | 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
