From: "Y. Yang" <[email protected]<mailto:[email protected]>> Date: Tuesday, October 29, 2013 5:53 PM To: Cisco Employee <[email protected]<mailto:[email protected]>> Cc: Vijay Gurbani <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [alto] extension questions and comments
>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. [RP] right, I believe we discussed this in the beginning but there is just too much opportunity for ratholing. My guess is the the majority of app developer will not care about end property fine grained control. App would basically say "I want to be on the high bandwidth PID". 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! [RP] Exactly! Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
