Re: [altoext] General Applicability of a Cost Graph?

[Ben Niven-Jenkins <[e-mail]>]

Greg,

I wonder if splitting the topology from the costs (like it is in ALTO today) would be beneficial - i.e having a Network Graph & associated Cost Graph(s). Maybe because some clients might be interested in the network topology but be happy with E2E costs they don't need to compute?

I haven't really followed the large bandwidth use cases but one thing that strikes me between my CDN use cases and the large bandwidth use cases (and maybe also the DC ones) is the level of granularity of information required.

In the CDN use cases I have I need finer granularity of network topology than a peer to peer client[1] but I still only require an abstract view of the topology - i.e. I don't need to know about individual links/routers or about the topology between CDN locations etc. 

So a good part of the value of an ALTO server/solution is that it performs that abstraction for me. For the large bandwidth use cases I get the impression that knowing detailed topology is important and so ALTO is not really performing the role of an abstraction layer and is just performing the role of an API to obtain topology information.

Ben

[1] I have to model a PID per "clump" of end users and a PID per network location containing a CDN device rather than peer to peer that probably models something more akin to "my local peers", "peers on my ISPs network", "preferred transit peers", "everyone else".

On 16 Apr 2012, at 19:13, Greg Bernstein wrote:

> Hi all, I wanted to see what the intersection between the "high bandwidth use cases", "Data Center", and "CDN uses" might be.
> In particular we (high bandwidth folks) are interested in "Cost Graph" type of information and given a bit more formally at the end of this e-mail. Starting from the ALTO protocol document and looking at extensions we have:
> 	• ALTO provides for "path cost", endpoint properties, and endpoint costs. Registry allows for new costs types in addition to 'exp:' and 'priv:' prefixed cost identifiers.  
> 	• In draft-randriamasy-alto-multi-cost-06, Multi-Cost ALTO, bandwidth was brought up as a possible cost type. This seems to have wide applicability in the controlled and partially controlled cases. They call this "path bandwidth". --> We'd like standard latency and bandwidth cost types if possible.
> 	• However "path bandwidth" would typically be used with some type of "routing cost", and perhaps a "latency cost". This leads to a "multi-cost" scenario. --> We'd like multiple costs at once (e.g., bandwidth, routing, latency)
> 	• Bandwidth is much different from a hop count or distance based "routing cost". We have illustrated in our high bandwidth use case draft how "bottleneck" links can lead to erroneous assumptions on network capacity and we introduced a "cost graph" representation to more accurately model the network. --> We really need graph representation for high bandwidth situation. We gave examples in our high bandwidth draft and BoF presentation.
> A graph based model seems generally useful.  For example, it seems to me that this could be applicable to Data Center and possibly CDN situations. For example in the Data Center presentation (http://www.ietf.org/proceedings/83/slides/slides-83-i2aex-2.pdf) there was a use case on "Network Rack/Location Awareness" (slide 8). There seem to be a variety of data center network architectures (top of rack, end of row, fabric extenders, etc). It seems that that bandwidth constraints of such different designs could be well modeled via a cost graph, i.e., use a cost graph for VM placement and such... Similar comments apply to the "Use Case: Hybrid Cloud Bandwidth On Demand" on slide 9.  Data center and CDN folks any opinions on your needs/desires for potential extensions mention in items 2-4 above?
> 
> Cheers
> 
> Greg B.
> 
> A cost graph can be represented as a set of links with properties (costs). Possible cost graph JSON encoding:
> // Simple Link object
> object {
>       NIDName aend;     // Node ids (NIDs) are similar to PIDs but
>       NIDName zend;     // may not have endpoints, i.e., just a node for modeling.
>       JSONNumber wt;    //A numerical routing cost
>       JSONNumber delay; //A numerical latency cost, optional
>       JSONNumber bw;    //A numerical bandwidth "cost",       optional
>       // Other costs private or experimental could be added
>       // for example stuff related to reliability or economic cost.
>       // Only one cost of each type would be permitted.
>       // Note a multi-cost like mechanism could be used.
> } LinkData  
>  
> // Collection of links each identified by link id (LID) name (LIDName).
> object {
>      LinkData [lidname]<0..*>;    // Link id (LID) would be an identifier similar to
>      ...                          // a PID or NID an identifies the link
>    } NetworkLinkData;
> 
> // The graph
> object {
>      VersionTag     map-vtag;
>      NetworkLinkData graph;
>    } InfoResourceNetworkGraph;
> 
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]
> 
> 
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext