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

[Greg Bernstein <[e-mail]>]

Hi Ben, good points. I think we have a fair amount in common. See 
comments and questions below.
Cheers
Greg
On 4/16/2012 1:44 PM, Ben Niven-Jenkins wrote:
> 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?
--> Sounds reasonable. I haven't evaluated all the options. First I'm 
trying to see how wide the applicability is for some type of graph 
representation. I think at the IP layer an abstract graph (tree 
structure) could show bottlenecks and help with multiple source and 
multiple destination ALTO, i.e., the "server selection problem".  No 
reservations (MPLS-TE, GMPLS, or OpenFlow) required.  Below IP 
particularly at the "optical" layer one cannot even probe for 
bandwidth... So an abstract graph can be very handy.
>
> 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.
--> In the "high bandwidth" case. We also want to provide an abstract 
view. Though some carriers due display their fiber and other layer maps 
online, e.g., 
http://www.centurylink-business.com/demos/network-maps.html 
orhttp://maps.level3.com/default/#.T47ePdUcsTl, these are in abstract 
form. They are not showing individual routers, Ethernet switches, SONET 
or OTN switches, ROADMS, or OXCs. Network details are sensitive, in 
addition there is a question of how much does the application layer want 
to try and optimize the network.  Hence, we've been thinking of 
abstracting away all the messy multi-layer networking stuff into a 
single abstract network representation that the application layer can 
then use.
>
> 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.
---> Abstraction is crucial to the high bandwidth case too! We must hide 
the complexity of multi-layer networks to help applications to make 
effective use of underlying network resources.

>
> 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".
--> The PID concept is crucial for abstraction in the "high bandwidth 
case" too. We'd probably clump together users attached to OXC or ROADMs, 
or other types of switching gear abstract bandwidth capabilities, use 
endpoint properties/costs to represent last link, etc...

>
> 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
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]