Re: [altoext] i2aex BOF - Large Bandwidth Use Case

[Greg Bernstein <[e-mail]>]

Hi Richard, great conversation. A couple general comments on  "large 
bandwidth" case.  I think we are seeing some good convergence for some 
of the data center and "large bandwidth" use cases.

Issues with "optical" bandwidth resources:
(a) Being well below IP this bandwidth is not visible to upper layers, 
i.e., packet probing won't detect it.
(b) Spare optical link capacity is not inherently usable unless 
specifically allocated. This is unlike packet technologies with 
statistical multiplexing. We need to set up "light paths", "OTUs", 
"STSs" (old fashioned circuits).

We would like to extend ALTO to help with (a).

To take advantage of the optical capacity we need high level guidance 
from the application layer as to which circuits to set up and their 
properties. This is what I've been calling a "reservation interface".  
Where this belongs (if at all) at the IETF is an open question. I'll try 
to describe it a bit more below.

It is great that we have GMPLS, MPLS and Open Flow technologies that can 
allow us to dynamically set up "express lanes". However, I would not 
want the application to have to know any details of either the optical 
network (WDM, OTN, SDH, Ethernet, etc...) or the "bypass technology" 
utilized to create the "express lanes" (AKA "traffic engineering") 
(MPLS, PBE, OpenFlow).  This stems from both security and information 
hiding principles.

A carrier doesn't want to necessarily reveal the details of the 
combination of optical and packet technologies it is currently using. In 
addition, those technologies can change overtime and the application 
layer folks would not want to deal with those changes. Hence I see the 
need for an interface that is not layer specific like the control planes 
for GMPLS, MPLS and PBE, or related UNIs.  These interfaces also assume 
more trust than I would want to extend outside the network.

With current trends in data center networking pushing performance and 
guarantees, I think such an interface could be useful within the data 
center.  When I look at the OpenStack project (open source IaaS cloud 
software) they have one incubator project (Quantum) with "connectivity 
as a service" maybe that would be a place for this. However, I would 
think a standard would be better. Even NIST has mentioned "Network as a 
Service" in some of there cloud computing documents...

Let me know if this makes the concept of "reservation interface" 
clearer. I'm not saying where it belongs organizationally only that it 
could be very useful.

Cheers

Greg


On 3/25/2012 7:38 PM, Y. Richard Yang wrote:
> On 3/25/12 2:48 PM, Greg Bernstein wrote:
>> Hi Richard good questions and comments see below for a few more 
>> comments.
>> Folks remember to talk clearly into the microphones at the meeting. A 
>> number of use will be "remote"!
>> Cheers
>> Greg
>> On 3/24/2012 4:27 PM, Y. R. Yang wrote:
>>> Hi Young,
>>>
>>> Very nice deck of slides with some very interesting use cases!
>>>
>>> A quick comment/question on using approximate graphs to address the 
>>> interesting issues of shared bottlenecks that may not be exposed by 
>>> e2e links. In a dynamic, interactive constraint solving/joint 
>>> optimization setting, such internal coupling will show up as "cost" 
>>> increase on one source-dest pair, when using another independent pair.
>> --> When Young and I have formulated multi-commodity flow problems 
>> for TDM and wavelength networks we usually start by keeping the 
>> constraint notions of bandwidth (timeslots, wavelength) separate from 
>> cost notions.  In some formulations we will allow for overcapacity 
>> (generally to see where to light up more fiber) by adding a severe 
>> cost penalty for over utilized links.
> Adding penalty for over-utilization (to solve the problem of internal 
> coupling) is a very good, and general idea!
>
>>>
>>> But your use case does show another way to expose infrastructure 
>>> info. We consider the use case that the path for a source, 
>>> destination pair is computed by the infrastructure, not by the app 
>>> (otherwise, it is a different story).
>> --> We consider the case where an app may have some 
>> control/preference over route choices. In GMPLS we have the notion of 
>> loose routes/paths. In the optical world, particularly high 
>> reliability, there may be more factors in the app wanting to have 
>> some say over the routes.
> I agree that there can be use cases where apps may have control over 
> route choices. The case of using loose routing is quite interesting 
> indeed. Regarding high reliability, SRLG immediately comes to mind.
>
>>> Then one issue of exposing only a graph is ambiguity for an app to 
>>> determine the path for a source, destination pair, unless the 
>>> underlying graph has no loop, since then the computed path then will 
>>> depend on the policy of the infrastructure.
>> --> The "tree" graph in the draft was easiest to draw but the slides 
>> show more realistic graphs with rings and meshes. If the app will not 
>> have a choice in path or has no way to tell the infrastructure the 
>> path, then I'm not sure of need of a graph over a cost map or a 
>> distance vector.
>>> For example, consider a graph, where each s1, s2, rs, r1, r2, rd, 
>>> d1, d2 is a pid, si is source ER, and di is destination ER in your 
>>> example:
>>>
>>> s1 ->  rs
>>> s2 ->  rs
>>> rs ->  r1
>>> rs ->  r2
>>> r1 ->  rd
>>> r2 ->  rd
>>> rd ->  d1
>>> rd ->  d2
>>>
>>> Then the app may not be able to figure out the path for s1 to d1, or 
>>> s2 to d2.
>> --> From the perspective of ambiguity since there are multiple paths 
>> that could be taken?
> s1 -> rs -> r1 -> rd -> d1, or
> s1 -> rs -> r2 -> rd -> d1
>>>
>>> One possibility is to expose the node path in a "cost" map, where 
>>> the value of each entry is a (bgp style) path vector, in addition to 
>>> a graph topology map. I get a feeling that others may have better, 
>>> more compact representation, but the preceding seems simple.  What 
>>> do you think?
>> --> Hmm, interesting. Are you suggesting to use both a graph to 
>> capture bottlenecks and a path vector to show costs and provider 
>> selected routes? Hmm, this sounds useful without the "reservation 
>> interface" that we would also like ;-) .
> A scenario is that an infrastructure exposes 3 data structures (maps):
>
> - a network (location) map to define PIDs;
> - a path-vector cost map to define (related) pair-wise (PID) path 
> vector (cost), for example, s1 -> d1: rs r1 rd to indicate that the 
> provider selects this path;
> - a topology map (graph) to allow indication of link properties (e.g., 
> abw, latency).
>
> "reservation interface"? not fully clear yet :-(
>
> I sure have learned much from the high bw use case.
>
> Thanks.
>
> Richard
>>>
>>> Thanks!
>>>
>>> Richard
>>>
>>> On Mar 23, 2012, at 1:40 PM, Leeyoung<[e-mail]>  wrote:
>>>
>>>> WARNING: contains banned part
>>>> This message cannot be displayed because of the way it is 
>>>> formatted. Ask the sender to send it again using a different format 
>>>> or email program. multipart/mixed
>>>> _______________________________________________
>>>> altoext mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/altoext
>>> _______________________________________________
>>> altoext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/altoext
>>>
>>>
>>
>>
>
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext
>


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