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

["Y. Richard Yang" <[e-mail]>]

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