Subject: Re: [alto] IETF 96 agenda requests

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 5 Jul 2016 12:04:07 -0500

On Monday, Jul 4, 2016 "Y. Richard Yang" <[email-masked]> wrote:

> Vijay, Jan, all,
>
> I am replying this email publicly so that all of us can engage more
> in shaping the agenda in about three weeks.
>
> A key item that the WG needs to discuss, in the potentially more
> productive f2f-meeting setting in Berlin, is how the WG should move
> forward. Can we allocate a slot, say at least 20 min, for this
> discussion?

Richard: ACK.  More inline.

> Besides the general discussions, here are some comments on specific
> agenda items and the mission of the WG:
>
> - Despite the substantial change of the networking landscape, I still
> believe that the foundational services of ALTO are sound: providing
> abstract network information to applications. I believe that this is
> also what many others see ALTO; for example see [1]. The key is what
> we do to go beyond the initial network abstractions.
 >
> - The first I see is Endpoint Cost Service (ECS), which is the
> foundation. It provides an interface to allow applications to know
> the routing costs. However, current ALTO is defined pre-SDN, and the
> emerging trend of SDN is going beyond simple destination routing, to
> be more application dependent. Hence, I see that we need to go beyond
> Endpoint Cost Service, to say Flow Cost Service. There is an
> extension draft [2], and I suggest that the WG finishes this to make
> the ALTO protocol complete. Make sense?

The ecs-flow draft has been around for a couple of months.  I don't
think it has attracted WG attention, despite being headed in the right
direction with respect to the abstraction that involves application-
constraints during routing decisions.

> -  The next I see is network graph (path vector) abstraction. The
> more I think about it, the more I am convinced that this is the way
> we go. I am an author of the draft and multiple versions are evolving
> [3, 4, 5], but we are relatively slow in convergence. I suggest that
> the WG gets a set of active participants to finish this draft, so
> that we have a relatively complete set of ALTO services.

The above will be imperative, I believe.  I may well be wrong and it may
just be me, but I still sense a bit of bewilderment as the convergence
occurs.  Most of the time, these drafts gets discussed around a pending
meeting.  I think it is necessary to crisply define and finish this
work as soon as possible.

> [1] https://www.opendaylight.org/file/odl-beryllium-diagram02
> [2] https://datatracker.ietf.org/doc/draft-wang-alto-ecs-flows/
> [3] https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/
> [4] https://tools.ietf.org/html/draft-yang-alto-topology-06
> [5] https://tools.ietf.org/html/draft-scharf-alto-topology-00

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: [email-masked] / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 5 Jul 2016 13:25:08 -0400

Vijay,

Please see inline.

> work as soon as possible.
OK. We should target posting a spec by this Friday so that we can discuss
the spec
before the meeting, to remove any confusion/bewilderment. Since the key
piece is
encoding specification of (1) graph; and (2) path vector associated w/ a
graph. We will target posting those spec, precisely first.

Thanks,
Richard

> [1]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opendaylight.org_file_odl-2Dberyllium-2Ddiagram02&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=ECAY29NKpa-pzUFGnbFKc14RscT_yWXOudwbFTF_JOA&e=
>> [2]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwang-2Dalto-2Decs-2Dflows_&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=KoT7ZAqiWhT9v8F789UjuxAXfsWYGhVHJ8ky_4a1iYA&e=
>> [3]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dgao-2Dalto-2Drouting-2Dstate-2Dabstraction_&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=SQw1tvpbmAAef8M7j2zUxUpRDNjT962ij0EwRRAwTe8&e=
>> [4]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dyang-2Dalto-2Dtopology-2D06&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=iHLFCmBP0BOPkNSlv7GTtgbIKJOsJC3QVv5vYEGDp1s&e=
>> [5]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dscharf-2Dalto-2Dtopology-2D00&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=I7IDwEnKJY80JCz52SuKsoi4Fj6eedjJuwWkNGYsFOM&e=
>>
>
> Thanks,
>
> - vijay
> --
> Web:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=CVBjaDcXsvH5d3XzEDkwYshYN1iFjR4RHwwPFmxfPIY&e=
>  | Calendar:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=CwICaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=adhagbZSLa5CB30jrM471w53fmh23nxWmJzt3jJW07c&s=enw4lznI8SylO_dz-KCbJLBPlXhKyWdRXHMGDAg--Zw&e=

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 5 Jul 2016 12:27:09 -0500

On 07/05/2016 12:25 PM, Y. Richard Yang wrote:
> Vijay,
>
> Please see inline. [...] OK. We should target posting a spec by this
> Friday so that we can discuss the spec before the meeting, to remove
> any confusion/bewilderment. Since the key piece is encoding
> specification of (1) graph; and (2) path vector associated w/ a

Richard: Awesome!  Thanks.

- vijay

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 5 Jul 2016 10:55:21 -0700

Hi all since some of our original Internet Drafts association with ALTO 
"topology extensions" our well out of date, those that are interested 
may want to look at a technical paper that Young and I put together back 
in 2012 
(http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf). 
This has motivations, concepts, alternative representations and color 
highlighted figures to aid in comprehension.  We also have the short (11 
slide) presentation that we gave at the Vancouver 2012 IETF for those 
that never saw it or need to job their memory.

Cheers

Greg B.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 6 Jul 2016 12:52:45 -0400

Greg, all,

I read the paper and found it highly relevant, for the convergence of our
network graph/path vector design. Here, let us start with the initial
design, before getting into the details of json encoding. Any feedback will
be greatly appreciated.

- Path-vector request:
  src/dest pairs; and optionally, for each pair, additional hint
information such as demand, requirement metrics
  Requested properties of network elements

- Path-vector response:
  Path vector for each src/dst pair, where each element in a path vector is
an abstract network element
  A description of the properties of each network element.

Example:
  Req:
    src/dst pairs: {s1 -> d1, demand = 10, latency < 20 ms}, {s2 -> d2, ...}
    properties: available-bw, cost

  Response:
    s1 -> d1: "e1", "e2", ...
    ...
    "e1" properties: available-bw = 10, cost = 3,

...

The preceding does not handle the case of query topology, but I feel that
path vector, which essentially assumes that routing is given and no need to
worry about path compressions, is a good, clean start.

Does the preceding missing anything?

Richard

On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein <[email-masked]>
wrote:

> "topology extensions" our well out of date, those that are interested may
> want to look at a technical paper that Young and I put together back in
> 2012 (
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e=
> ). This has motivations, concepts, alternative representations and color
> slide) presentation that we gave at the Vancouver 2012 IETF for those that
> never saw it or need to job their memory.
>
> Cheers
>
> Greg B.
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=-othJunl7gz_02BM9c1kqLPhFmI2iJr3vD6gu41kd_w&e=

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 6 Jul 2016 11:46:28 -0700

Hi Richard, your coding of the initial design looks fine. However we 
did  a lot of work in the past and the effort within the ALTO WG 
stalled. This did not seem to be due to technical disagreements by 
various draft authors (folks seemed fairly flexible and in rough 
consensus), but rather to the WG not wanting to move in this direction 
at the time.

I'm not sure what is the best way forward with topology extensions. 
Various working group participants have  produced drafts over the years 
that clarified the problem statement, looked at and justified two major 
"architectural alternatives", worked on some encoding details, and wrote 
up some advanced work (the "A Routing State Abstraction Service Using 
Declarative Equivalence" draft) based on the potential topology extensions.

Before putting in a bunch more time and effort it would be good to know 
where the WG wants to go with these extensions. As we've discussed such 
extensions are very valuable in the SDN realm for network virtualization 
(with flexible network information disclosure). Either adopting a draft 
on topology extensions as a WG document or chartering a design team to 
write a series of documents would get my renewed participation.

Cheers

Greg B.

On 7/6/2016 9:52 AM, Y. Richard Yang wrote:
> Greg, all,
>
> I read the paper and found it highly relevant, for the convergence of 
> our network graph/path vector design. Here, let us start with the 
> initial design, before getting into the details of json encoding. Any 
> feedback will be greatly appreciated.
>
> - Path-vector request:
>   Path vector for each src/dst pair, where each element in a path 
> vector is an abstract network element
> The preceding does not handle the case of query topology, but I feel 
> that path vector, which essentially assumes that routing is given and 
> no need to worry about path compressions, is a good, clean start.
>
> On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all since some of our original Internet Drafts association with
>     ALTO "topology extensions" our well out of date, those that are
>     interested may want to look at a technical paper that Young and I
>     put together back in 2012
>     (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e=
>     ). This has motivations, concepts, alternative representations and
>     color highlighted figures to aid in comprehension.  We also have
>     the short (11 slide) presentation that we gave at the Vancouver
>     2012 IETF for those that never saw it or need to job their memory.
>
>     Cheers
>
>     Greg B.
>
>
>     [email-masked] <mailto:[email-masked]>
> | Y. Richard Yang <[email-masked] <mailto:[email-masked]>>   |
> | http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 6 Jul 2016 20:45:02 -0400

Greg,

Nice discussion!

On Wednesday, July 6, 2016, Greg Bernstein <[email-masked]>
wrote:

> Hi Richard, your coding of the initial design looks fine. However we did
> a lot of work in the past and the effort within the ALTO WG stalled. This
> did not seem to be due to technical disagreements by various draft authors
> (folks seemed fairly flexible and in rough consensus), but rather to the WG
> not wanting to move in this direction at the time.
>

My understanding is that other extensions may need to be handled first. The
timing on topology can be right.

> "architectural alternatives", worked on some encoding details, and wrote up
> some advanced work (the "A Routing State Abstraction Service Using
> (with flexible network information disclosure). Either adopting a draft on
> topology extensions as a WG document or chartering a design team to write a
> series of documents would get my renewed participation.
>

Network graph is a chartered WG item, and hence is becoming a higher
priority, as other items move forward.

Here is my current thinking/reasoning on topology/routing state abstraction
for application traffic optimization:

1. alto is somehow not allowed to change network state, which somehow (not
fully but quite likely) imply that routing is given;

2. Given that routing is given, what application can do is its traffic
scheduling. Assume that the application has a set of flows F = {f1, f2,
..., f_|F|}. If routing is given, many properties (e.g., propagation
delay) of flow i are given. What application is given to control is x1, x2,
..., x_|F|, where xi is the amount of traffic for flow i. Let x = [x1, ...,
x_|F|] be the vector. Then what application can do is to select the value
of x. Curren ALTO (rfc7285) already can provide the properties of the
routing path of each flow i. The main missing is the **capacibity region**
of x due to correlation among flows. The motivating example we presented is
always this case. For example, the dumbbell example is this case: flow 1
can get 10, flow 2 can get 10, but what if the two flows together? In other
words, the capacity region can be a complex polytope. What we mean routing
path abstraction is mostly to provide this info, which is a
highly important network info for application optimization.

If we agree with the preceding essence, we can have a pretty precise,
concise spec. Make sense?

Richard

>   Path vector for each src/dst pair, where each element in a path vector
> is an abstract network element
> On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e=>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
> | Y. Richard Yang <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>   |
> | <http://www.cs.yale.edu/%7Eyry/>http://www.cs.yale.edu/~yry/        |

-- 
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 6 Jul 2016 21:52:20 -0400

Let me add one note. Please see below.

On Wednesday, July 6, 2016, Y. Richard Yang <[email-masked]> wrote:

> Greg,
>
> Nice discussion!
>
> On Wednesday, July 6, 2016, Greg Bernstein <[email-masked]
> My understanding is that other extensions may need to be handled first.
> The timing on topology can be right.
>
> Here is my current thinking/reasoning on topology/routing state
> abstraction for application traffic optimization:
>

The only other case beyond capacibity region is shared risk link group. But
this may not need to reveal topology---each flow reveals the set of risk
labels can do. Make sense?

Richard

>> [email-masked]> wrote:
>>

-- 
Richard

---

From: Gao Kai <[email-masked]>
Date: Thu, 7 Jul 2016 16:56:20 +0800

Hi Richard, Greg and all,

I think in some way, ALTO already has a graph representation.  Consider
the cost mapand the endpoint cost map provided by ECS, they are
basically fullmesh graphs in the matrix representation, where the paths
between certain endpoint groups or hosts can be seen as virtual links. 
If we look at the use casessuch as peer/replica selection, they can be
seen as making "routing" decisions in those overlay graphs.So from my
perspective, the "topology extensions" are more like the efforts to
generalize the ALTO protocol.

As Greg has mentioned, there are quite a few works on the
"topologyextension"and many of us are still looking forward to pushing
it forwards.  I'd very much like to contribute if the WG decides to go
down the path.

A major concern might be how ALTO can distinguish itself from the
others.  I think the value of ALTO is that it comes with
application-layer semantics.  Right now we have endpoints and endpoint
groups, identified by IP addresses and prefixes,  maybe later we can
have rendez-vous points (capacity regions, shared risk links, etc.),
relaypoints(caches, NAT, VPN gateways, etc.) and even some NFV nodes.

Regards,
Kai

On 07/07/16 09:52, Y. Richard Yang wrote:
> On Wednesday, July 6, 2016, Y. Richard Yang <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Greg,
>
>     Nice discussion!
>
>         Hi Richard, your coding of the initial design looks fine.
>         However we did  a lot of work in the past and the effort
>         within the ALTO WG stalled. This did not seem to be due to
>         technical disagreements by various draft authors (folks seemed
>         fairly flexible and in rough consensus), but rather to the WG
>     My understanding is that other extensions may need to be handled
>     first. The timing on topology can be right. 
>
>         I'm not sure what is the best way forward with topology
>         extensions. Various working group participants have  produced
>         drafts over the years that clarified the problem statement,
>         looked at and justified two major "architectural
>         alternatives", worked on some encoding details, and wrote up
>         some advanced work (the "A Routing State Abstraction Service
>         Using Declarative Equivalence" draft) based on the potential
>         topology extensions.
>
>         Before putting in a bunch more time and effort it would be
>         good to know where the WG wants to go with these extensions.
>         As we've discussed such extensions are very valuable in the
>         SDN realm for network virtualization (with flexible network
>         information disclosure). Either adopting a draft on topology
>         extensions as a WG document or chartering a design team to
>     Network graph is a chartered WG item, and hence is becoming a
>     higher priority, as other items move forward.
>
>     1. alto is somehow not allowed to change network state, which
>     somehow (not fully but quite likely) imply that routing is given;
>
>     2. Given that routing is given, what application can do is its
>     traffic scheduling. Assume that the application has a set of flows
>     F = {f1, f2, ..., f_|F|}. If routing is given, many properties
>     (e.g., propagation delay) of flow i are given. What application is
>     given to control is x1, x2, ..., x_|F|, where xi is the amount of
>     traffic for flow i. Let x = [x1, ..., x_|F|] be the vector. Then
>     what application can do is to select the value of x. Curren ALTO
>     (rfc7285) already can provide the properties of the routing path
>     of each flow i. The main missing is the **capacibity region** of x
>     due to correlation among flows. The motivating example we
>     presented is always this case. For example, the dumbbell example
>     is this case: flow 1 can get 10, flow 2 can get 10, but what if
>     the two flows together? In other words, the capacity region can be
>     a complex polytope. What we mean routing path abstraction is
>     mostly to provide this info, which is a highly important network
>     info for application optimization. 
>
>
> The only other case beyond capacibity region is shared risk link
> group. But this may not need to reveal topology---each flow reveals
> the set of risk labels can do. Make sense?
>
> Richard
>
>
>     If we agree with the preceding essence, we can have a pretty
>     precise, concise spec. Make sense?
>
>     Richard
>
>         Cheers
>
>         Greg B.
>
>
>>         I read the paper and found it highly relevant, for the
>>         convergence of our network graph/path vector design. Here,
>>         let us start with the initial design, before getting into the
>>         details of json encoding. Any feedback will be greatly
>>         appreciated.
>>
>>         - Path-vector request:
>>           src/dest pairs; and optionally, for each pair, additional
>>         hint information such as demand, requirement metrics
>>           Path vector for each src/dst pair, where each element in a
>>         path vector is an abstract network element
>>         The preceding does not handle the case of query topology, but
>>         I feel that path vector, which essentially assumes that
>>         routing is given and no need to worry about path
>>         compressions, is a good, clean start. 
>>
>>         <[email-masked]> wrote:
>>
>>             Hi all since some of our original Internet Drafts
>>             association with ALTO "topology extensions" our well out
>>             of date, those that are interested may want to look at a
>>             technical paper that Young and I put together back in
>>             2012
>>             ). This has motivations, concepts, alternative
>>             representations and color highlighted figures to aid in
>>             comprehension.  We also have the short (11 slide)
>>             presentation that we gave at the Vancouver 2012 IETF for
>>             those that never saw it or need to job their memory.
>>
>>             Cheers
>>
>>             Greg B.
>>
>>
> https://www.ietf.org/mailman/listinfo/alto

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 7 Jul 2016 09:50:49 -0700

Hi Kai I think you make a very important point:

> application-layer semantics.
ALTO has already come out with the first standards to bridge the 
application-network divide. It's a good time to enhance it for 
usefulness with a good set of topology (and in my interest bandwidth 
aware) extensions. If we wait too long then ALTO will miss the window to 
provide guidance to an important emerging segment of the networking 
community. Qiao et. al. will be publishing a draft on a protype system 
for big science (LHC) data transfers that makes use of such information 
and their example easily generalizes to other distributed "big data" 
applications. In addition we have applicability within the data center 
and as a key bandwidth/resource aware abstraction mechanism for SDN 
virtual networking services.

Cheers

Greg B.

On 7/7/2016 1:56 AM, Gao Kai wrote:
> I think in some way, ALTO already has a graph representation.  
> Consider the cost mapand the endpoint cost map provided by ECS, they 
> are basically fullmesh graphs in the matrix representation, where the 
> paths between certain endpoint groups or hosts can be seen as virtual 
> links.If we look at the use casessuch as peer/replica selection, they 
> can be seen as making "routing" decisions in those overlay graphs.So 
> from my perspective, the "topology extensions" are more like the 
> efforts to generalize the ALTO protocol.
>
> it forwards.I'd very much like to contribute if the WG decides to go 
> down the path.
>
>>     On Wednesday, July 6, 2016, Greg Bernstein
>>         technical disagreements by various draft authors (folks
>>         seemed fairly flexible and in rough consensus), but rather to
>>         the WG not wanting to move in this direction at the time.
>>
>>
>>     traffic scheduling. Assume that the application has a set of
>>     flows F = {f1, f2, ..., f_|F|}. If routing is given, many
>>     properties (e.g., propagation delay) of flow i are given. What
>>     application is given to control is x1, x2, ..., x_|F|, where xi
>>     is the amount of traffic for flow i. Let x = [x1, ..., x_|F|] be
>>     the vector. Then what application can do is to select the value
>>     of x. Curren ALTO (rfc7285) already can provide the properties of
>>     the routing path of each flow i. The main missing is the
>>     **capacibity region** of x due to correlation among flows. The
>>     motivating example we presented is always this case. For example,
>>     the dumbbell example is this case: flow 1 can get 10, flow 2 can
>>     get 10, but what if the two flows together? In other words, the
>>     capacity region can be a complex polytope. What we mean routing
>>>         let us start with the initial design, before getting into
>>>         the details of json encoding. Any feedback will be greatly
>>>         appreciated.
>>>
>>>         - Path-vector request:
>>>         The preceding does not handle the case of query topology,
>>>         but I feel that path vector, which essentially assumes that

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 7 Jul 2016 16:44:51 -0400

Great discussion! I agree that the key value of ALTO services is that they
are from the perspective of the application layer, hiding complexities due
to those of the underlining network layer technologies, through ALTO
abstractions.

I will post the new capacity region design schema shortly, as capacity
region can be an important concepts for applications.

Richard

On Thu, Jul 7, 2016 at 12:50 PM, Greg Bernstein <[email-masked]

> application-network divide. It's a good time to enhance it for usefulness
> with a good set of topology (and in my interest bandwidth aware)
> extensions. If we wait too long then ALTO will miss the window to provide
> guidance to an important emerging segment of the networking community. Qiao
> et. al. will be publishing a draft on a protype system for big science
> (LHC) data transfers that makes use of such information and their example
> easily generalizes to other distributed "big data" applications.  In
> addition we have applicability within the data center and as a key
> bandwidth/resource aware abstraction mechanism for SDN virtual networking
> services.
>
> Cheers
>
> Greg B.
>
> the cost map and the endpoint cost map provided by ECS, they are
> basically full mesh graphs in the matrix representation, where the paths
> between certain endpoint groups or hosts can be seen as virtual links.  If
> we look at the use cases such as peer/replica selection, they can be seen
> as making "routing" decisions in those overlay graphs. So from my perspective,
> the "topology extensions" are more like the efforts to generalize the ALTO
> protocol.
>
> As Greg has mentioned, there are quite a few works on the "topology
> extension" and many of us are still looking forward to pushing it
> forwards.  I'd very much like to contribute if the WG decides to go down
> the path.
>
> groups, identified by IP addresses and prefixes,  maybe later we can have rendez-vous
> points (capacity regions, shared risk links, etc.), relay points (caches, NAT,
> VPN gateways, etc.) and even some NFV nodes.
>
> Regards,
> Kai
>
>>> did  a lot of work in the past and the effort within the ALTO WG stalled.
>>> This did not seem to be due to technical disagreements by various draft
>>> authors (folks seemed fairly flexible and in rough consensus), but rather
>>> to the WG not wanting to move in this direction at the time.
>>>
>>
>> 1. alto is somehow not allowed to change network state, which somehow
>> (not fully but quite likely) imply that routing is given;
>>
> The only other case beyond capacibity region is shared risk link group.
> But this may not need to reveal topology---each flow reveals the set
> of risk labels can do. Make sense?
>
> Richard
>
>
>>> our network graph/path vector design. Here, let us start with the initial
>>> that path vector, which essentially assumes that routing is given and no
>>> need to worry about path compressions, is a good, clean start.
>>>
> alto mailing [email-masked]://www.ietf.org/mailman/listinfo/alto <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IlT_QTRUGRKzqZpezQQb0pfc1PfxQJjy5QNFX6SLsmU&s=se_PGzs-uyKxvjREWSQuPINwWxOFDAEusRRB23h_pIM&e=>
>
>
>
>