Subject: [altoext] altoext: Call for participation

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Feb 2012 10:58:52 -0600

Folks: Enrico and I have put together a short draft that explores the
evolution and extension of ALTO as a protocol [1].  At the Taipei
IETF, there was a discussion on the ALTO evolution towards the tail end
of the session.

There are new directions that are being explored for ALTO --- its use
in CDNs and data centers comes to mind.  This may be a good time to
reflect on how we envision the protocol to be extended in order to
support these new services.

It will be great if we can foster discussions towards extending
ALTO in new domains culminating in a BoF in Paris.  Your views
on [1] are solicited as part of a larger discussions on extending
ALTO.  We need to form a "community of interest" to identify a
possible problem statement and the work to be done.  Folks who would
like to produce drafts on their positions are encouraged to do so as
part identifying the problem statement and outlining the work to be
done.

Thanks,

[1] http://tools.ietf.org/html/draft-marocco-alto-next-00

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 7 Feb 2012 19:42:37 +0000

Hi Vijay,

> IETF, there was a discussion on the ALTO evolution towards the tail end

<snip>

> possible problem statement and the work to be done.

Firstly I have to say I'm a little confused as to what is driving this level of "formal" structure as I think many of the items listed in your draft could be considered as relatively incremental changes that could be handled in the normal way within the ALTO WG today by folks writing drafts etc.

However there is at least one thing your draft touches on that I think is more architectural in nature which is extending ALTO to carry large amounts of application data, e.g. what content is on a cache, what applications are installed in a server etc. and I think we need to consider whether ALTO is really the best mechanism for conveying that information and if it's decided that ALTO is a good fit then whether the use cases are best served by overloading existing ALTO semantics (e.g. end point properties) or by extending ALTO with additional information services to deliver that data.

>  Folks who would

I have a couple of use cases I'm thinking about that aren't very well baked yet and I won't have time to write any drafts before Paris but in brief are:

- The ability to "name" cost maps so that a single Information Resource Directory can link multiple cost maps with the same cost type & cost mode to a single network map.

- The ability to have a static PID identifier/property as today an ALTO server can change PID names at will and if an ALTO client needs to tie PIDs to something else it can't rely on the PID name to maintain the mapping it requires. 

Ben

> _______________________________________________
> altoext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/altoext

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Feb 2012 14:34:53 -0600

On 02/07/2012 01:42 PM, Ben Niven-Jenkins wrote:
> Firstly I have to say I'm a little confused as to what is driving
> this level of "formal" structure as I think many of the items listed
> in your draft could be considered as relatively incremental changes
> that could be handled in the normal way within the ALTO WG today by
> folks writing drafts etc.

Ben: Good question.  It is quite true that some of the considerations
in the draft can be viewed as incremental changes.  However, there
are other considerations that are, well, rather perpendicular to
the reasons that ALTO was established, and if adopted would need
(a) either re-chartering ALTO, or (b) forming a new working group.
The BoF can at least help us figure what to do with respect to the
choices (a) and (b) above.

So, what are these structural changes?  One, ALTO was designed as
a "pull-only" model where the ALTO clients actively poll and pull the
resources of interest.  There has been some talk about introducing a
subs/not type of mechanism in ALTO.  Is this worth doing?  What
will this buy us?  How to go about doing this?

Two, ALTO was predicated on using information that did not change
too rapidly.  Thus, the low-frequency changes in the cost map
to account for diurnal cost structure was expected, as was the
rather static network map.  However, what was explicitly ruled out of
scope was information that changes rapidly --- link usage, congestion
notification, and other instantaneous network state.  As we are now
observing, use of ALTO in data centers, for instance, posits the
need for information that changes rapidly, e.g., data center
load, application usage load on a host in the data center, etc.

Finally, the driving use case for ALTO back in 2009-2010 timeframe
was, obviously, p2p.  The dynamics of p2p are a bit different than
the tasks that ALTO is being viewed for today.  For one, in a p2p
model, reducing transit costs was an important reason for choosing
local peers.  Second, there were far more peers to choose from
(assuming a healthy swarm) so that a wrong decision in the choice
of a peer was tolerated only for a matter of seconds.  Today's
use of ALTO in rendezvousing users with resources is not characterized
by as much multiplicity of resources.  Which means that choosing
the right resource requires more than simply a cost map.

I hope that helps in separating out the new work to be done from
extensions to the protocol that can be done in the ALTO WG itself
(just to be pedantic, even to do the extension work will require
re-chartering ALTO).

> However there is at least one thing your draft touches on that I
> think is more architectural in nature which is extending ALTO to
> carry large amounts of application data, e.g. what content is on a
> cache, what applications are installed in a server etc. and I think
> we need to consider whether ALTO is really the best mechanism for
> conveying that information and if it's decided that ALTO is a good
> fit then whether the use cases are best served by overloading
> existing ALTO semantics (e.g. end point properties) or by extending
> ALTO with additional information services to deliver that data.

An excellent observation.

> I have a couple of use cases I'm thinking about that aren't very well
> baked yet and I won't have time to write any drafts before Paris but
> in brief are:
>
> - The ability to "name" cost maps so that a single Information
> Resource Directory can link multiple cost maps with the same cost
> type&  cost mode to a single network map.
>
> - The ability to have a static PID identifier/property as today an
> ALTO server can change PID names at will and if an ALTO client needs
> to tie PIDs to something else it can't rely on the PID name to
> maintain the mapping it requires.

I suspect that the naming and having an invariant PID identifier
*could* be handled as extensions, but I will confess that this is
only a personal observation put forth without too much insight.
So please take this as an opinion that may change.

Thanks, Ben!

- vijay

---

From: Tina TSOU <[email-masked]>
Date: Wed, 08 Feb 2012 23:41:18 +0000

I tend to agree with Ben that the proposed list of extensions is very incremental.

An ALTO server should collect and distribute information that is handled by ALTO.

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vijay K. Gurbani
> Sent: Tuesday, February 07, 2012 12:35 PM
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> Subject: Re: [altoext] altoext: Call for participation
>