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

[Young Lee <[e-mail]>]

Hi Richard,

You made the following point:

>>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).
With the graph representation of the approvimate topology, we can always
derive the path vector. Sending both the graph and the path vector makes
the requestor's job easy; on the other hand, if we have to send multiple
cost types (one for BW, one for latency, etc.), then the path
vector should also be multiple costs. Would this then incur too
much overhead?

Thanks.
Young



On Sun, Mar 25, 2012 at 9:38 PM, Y. Richard Yang <[e-mail]> 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<https://www.ietf.org/mailman/listinfo/altoext>
>>>>
>>> ______________________________**_________________
>>> altoext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/**listinfo/altoext<https://www.ietf.org/mailman/listinfo/altoext>
>>>
>>>
>>>
>>
>>
> ______________________________**_________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/altoext<https://www.ietf.org/mailman/listinfo/altoext>
>