Subject: [alto] Text proposal for charter update

From: Enrico Marocco <[email-masked]>
Date: Wed, 19 Feb 2014 17:03:53 +0100

Hi all,

the text below tries to reflect the many discussions about rechartering
the ALTO WG. We believe that it includes the most relevant work items
people have shown interest for, yet it is something that can be
completed in a resonable timeframe (some may find it ambitious, esp.
according to the WG history, but the level of energy the WG has shown
recently in the finishing of our main deliverables provides good reason
for being optimistic).

Any kind of comment (including nits, +/-1...) are at this point
extremely important.

Enrico & Vijay

Application-Layer Traffic Optimization Working Group Charter

The ALTO working group was established in 2008 to devise a request/
response protocol for allowing a host to benefit from a server that is
more cognizant of the network infrastructure than the host would be.
The working group has developed an HTTP-based protocol (RFC-to-be) to
allow hosts to benefit from the network infrastructure by having
access to a pair of maps: a topology map and a cost map.

The origins of the ALTO protocol lay in peer-to-peer (P2P)
applications, where the host was a peer in a P2P network and desired
to be rendezvoused with other peers for file sharing, real-time
communications, etc.  It is a testament to the flexibility of the ALTO
protocol that it is now being considered as a solution for problems
outside the P2P domain, such as in datacenter networks and in content
distribution networks (CDN) where exposing abstract topologies helps
applications.

To support the emerging new uses of ALTO, certain extensions are being
sought.  These extensions can be classified as follows:

 o (Standards Track) Protocol extensions for reducing the volume of
   on-the-wire data exchange required to align the ALTO server and
   clients.  Extensions under consideration are mechanisms for
   delivering server-initiated notifications and partial updates of
   maps.  Efforts developed in other working groups such as Websockets
   and JSON-path will be considered, as well as bespoke mechanisms
   specific to the ALTO protocol.

 o (Standards Track) Extensions to the base ALTO server discovery
   mechanism (RFC-to-be) for deployment in heterogeneous network
   environments.  Mechanisms under consideration are extensions for
   third-party and anycast-based server discovery.

 o (Standards Track) Protocol extensions to convey a richer set of
   attributes to allow applications to determine not only "where" to
   connect but also "when" to connect.  Such additional information
   will be related both to endpoints (e.g. conveying server load and
   cache geo-location information for CDN use cases) and to
   endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent
   time-averaged cost values in datacenter networks).

   The working group will specify such extension in coordination with
   other working groups that are also working on the related use cases
   (e.g. cdni, i2rs, lmap).

 o (Informational) A survey of techniques to formalize the structure
   of a network graph (that can derived from a set of related ALTO
   network and cost maps) in a format that would facilitate advanced
   graph computation.  Such survey will cover both models used in
   popular open-source software (e.g. NetworkX, Blueprints) and models
   being considered in other working groups (e.g. netmod, i2rs).

 o (Informational) An document on deployment-related issues and
   lessons learned from early implementation experiences.

When the WG considers standardizing information that the ALTO server
could provide, the following criteria are important to ensure real
feasibility:

 - Can the ALTO service realistically discover that information?

 - Is the distribution of that information allowed by the operators of
   that service?

 - Can a client get that information without excessive privacy
   concerns?  Extensions defining new endpoint properties should focus
   on exposing attributes of endpoints that are related to the goals
   of ALTO -- optimization of application-layer traffic -- as opposed
   to more general properties of endpoints.  Privacy aspects of new
   endpoint properties will in any case be evaluated to the guidelines
   provided in the IANA considerations and Security Considerations of
   the ALTO protocol specification (RFC-to-be, sections 14.3 and 15.4
   at IESG review time).

 - Is it information that a client cannot find easily some other way?

After these criteria are met, the importance of the data will be
considered for prioritizing standardization work, for example the
number of operators and clients that are likely to be able to provide
or use that particular data.  In any case, this WG will not propose
standards on how congestion is signaled, remediated, or avoided, and
will not deal with information representing instantaneous network
state.

Issues related to the specific content exchanged in systems that make
use of ALTO are also excluded from the WG's scope, as is the issue
dealing with enforcing the legality of the content.

Milestones

Jul 2014 Working Group Last Call for third-party server discovery
         document

Jul 2014 Working Group Last Call for anycast-based server discovery
         document

Jul 2014 Working Group Last Call for partial updates document

Sep 2014 Submit third-party server discovery document

Sep 2014 Submit anycast-based server discovery document

Sep 2014 Submit partial updates document

Sep 2014 Working Group Last Call for deployment considerations
         document

Sep 2014 Working Group Last Call for network graph format survey
         document

Nov 2014 Submit deployment considerations document

Nov 2014 Submit network graph format survey document

Nov 2014 Working Group Last Call for server-initiated notifications
         document

Jan 2015 Submit server-initiated notifications document

Jan 2015 Working Group Last Call for endpoint property extension
         document

Jan 2015 Working Group Last Call for cost property extension document

Mar 2015 Submit endpoint property extension document

Mar 2015 Submit cost property extension document

---

From: Jan Seedorf <[email-masked]>
Date: Fri, 21 Feb 2014 14:09:45 +0000

Hi all,

The text looks good to me and in my view reflects the agreement on re-chartering in the ALTO WG.

Just two small comments:
-- "where the host was a peer in a P2P network and desired to be rendezvoused with other peers for file sharing" --> When talking about the P2P use case I would not use past tense but present tense. P2P is still out there and in principle the use case is technically still a valid one. The text in past tense reads to me like ALTO has extensively been used for this use case in the past (not really true), and should not been used for P2P anymore (also not really true)
-- "JSON-path" --> "JSON-patch"

-  Jan

> -----Original Message-----
> From: alto [mailto:[email-masked]] On Behalf Of Enrico Marocco
> Sent: Wednesday, February 19, 2014 5:04 PM
> To: [email-masked]
> Subject: [alto] Text proposal for charter update
> 
> Hi all,
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Feb 2014 15:42:47 -0600

On 02/21/2014 08:09 AM, Jan Seedorf wrote:
> -- "where the host was a peer in a P2P network and desired to be
> rendezvoused with other peers for file sharing" --> When talking
> about the P2P use case I would not use past tense but present tense.
> P2P is still out there and in principle the use case is technically
> still a valid one. The text in past tense reads to me like ALTO has
> extensively been used for this use case in the past (not really
> true), and should not been used for P2P anymore (also not really
> true)

Jan: Good catch.  Fixed both of these.  The charter draft is available
at the ALTO Wiki http://tools.ietf.org/wg/alto/trac/wiki

Cheers,

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 24 Feb 2014 15:41:25 +0000

Hi all,

In general, I support fully this. I have some minor suggestions/questions.

>    other working groups that are also working on the related use cases

While I fully agree that the "when" to connect is a very important use case, I would prefer a definition that does not imply that "when" is the only novelty. Also, I think it would be better to start with examples that are related to (abstract) topology.

For instance, what about:

 o (Standards Track) Protocol extensions to convey a richer set of
   attributes to allow applications an endpoint selection not only based on 
   current network routing cost. This includes guidance not only "where" to
   connect but also "when" to connect. Such additional information
   will be related both to endpoints (e.g. conveying cache geo-location
   or server load information for CDN use cases) and to
   endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent
   time-averaged cost values in datacenter networks).
 
>    being considered in other working groups (e.g. netmod, i2rs).

Maybe s/Blueprints/tinkerpop blueprints/ ?

"Blueprints" is not a very specific term.

But perhaps we could just remove the examples - I think we already agree that neither NetworkX nor tinkerpop blueprints will completely address our needs.

> will not deal with information representing instantaneous network

This sentence is already in the original charter. I am not a native speaker, and as a result I wonder about the semantics of "instantaneous", in particular regarding the up-to-dateness of the information.

Example: If the ALTO server polls the routing topology routing rather frequently (e.g., via BGP-LS), the ALTO maps and guidance can be entirely up-to-date, in particular if routing changes only sporadically in a network. To me, at least in such a rather static cases, the ALTO maps would then represent the "instantaneous" routing state, because the ALTO maps are fully up-to-date. Obviously, since ALTO abstracts the maps, it doesn't represent the exact routing data - "up-to-date" here implies that the input data used to calculate the map has not changed, i.e., any new update and data retrieval would result in the same abstracted map.

Wouldn't the phrasing "... and will not deal with information representing transient network state" be more appropriate? (Rapid changes are clearly a challenge for ALTO and out-of-scope.)

Or, for instance, "... and clients must not assume that the information represents instantaneous network state"? (A client cannot know whether the ALTO information is really up-to-date.) 

> Milestones

Do we really need separate deadlines for the WGLC? The current ALTO charter lists WGLCs as well, so this continues the current way of dealing with WGLC, but to me two milestones per planned document seem partly redundant. In TCPM we usually only have one milestone for a documents, unless special handling is needed. Just as a thought...

Thanks

Michael

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Mon, 24 Feb 2014 17:47:10 +0000

Hi all,

The text and proposed extension topics cover well the proposals and related concerns that have been discussed in the WG.

I would suggest two minor text additions, (referring at the version on http://trac.tools.ietf.org/wg/alto/trac/wiki/v0.1-recharter)

Suggestion 1 - in paragraph 1: to reflect the will of ALTO to preserve network information confidentiality while expressing network provider preferences, I propose to insert text as follows:   

Current: "having access to a pair of maps: a topology map and a cost map."
Proposed: "having access to a pair of maps +++ providing an abstracted view of the network infrastructure as seen by its operator +++ : a topology map and a cost map." 

Suggestion 2 - in extension item class "(Informational) A survey of techniques": to take into account the growing complexity of considered networks with the wireless use cases brought to the group, I propose to insert text (of item N° 2) as follows:

Current: " ... that would facilitate advanced graph computation. ... "
Proposed: " ... that would facilitate advanced graph computation +++ in (complex/)heterogeneous network environments +++. ... " 

Best regards,
Sabine

-----Message d'origine-----
De : alto [mailto:[email-masked]] De la part de Vijay K. Gurbani
Envoyé : vendredi 21 février 2014 22:43
À : [email-masked]
Objet : Re: [alto] Text proposal for charter update

On 02/21/2014 08:09 AM, Jan Seedorf wrote:
> rendezvoused with other peers for file sharing" --> When talking about 
> the P2P use case I would not use past tense but present tense.
> extensively been used for this use case in the past (not really true), 
> and should not been used for P2P anymore (also not really
> true)

Jan: Good catch.  Fixed both of these.  The charter draft is available at the ALTO Wiki http://tools.ietf.org/wg/alto/trac/wiki

Cheers,

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

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 25 Feb 2014 09:26:59 +0000

Hi, Enrico:
Comments inline below.

Regards!
-Qin

-----Original Message-----
From: alto [mailto:[email-masked]] On Behalf Of Enrico Marocco
Sent: Thursday, February 20, 2014 12:04 AM
To: [email-masked]
Subject: [alto] Text proposal for charter update

Hi all,

the text below tries to reflect the many discussions about rechartering the ALTO WG. We believe that it includes the most relevant work items people have shown interest for, yet it is something that can be completed in a resonable timeframe (some may find it ambitious, esp.
according to the WG history, but the level of energy the WG has shown recently in the finishing of our main deliverables provides good reason for being optimistic).

Any kind of comment (including nits, +/-1...) are at this point extremely important.

Enrico & Vijay

The ALTO working group was established in 2008 to devise a request/ response protocol for allowing a host to benefit from a server that is more cognizant of the network infrastructure than the host would be.
The working group has developed an HTTP-based protocol (RFC-to-be) to allow hosts to benefit from the network infrastructure by having access to a pair of maps: a topology map and a cost map.

The origins of the ALTO protocol lay in peer-to-peer (P2P) applications, where the host was a peer in a P2P network and desired to be rendezvoused with other peers for file sharing, real-time communications, etc.  It is a testament to the flexibility of the ALTO protocol that it is now being considered as a solution for problems outside the P2P domain, such as in datacenter networks and in content distribution networks (CDN) where exposing abstract topologies helps applications.

To support the emerging new uses of ALTO, certain extensions are being sought.  These extensions can be classified as follows:

[Qin]:I think conveying server load and geo-location information is used to
Allow application to choose better connection, so it would be good to 
have the following change:
OLD TEXT:
"
o (Standards Track) Protocol extensions to convey a richer set of
   attributes to allow applications to determine not only "where" to
   connect but also "when" to connect.  
"
NEW TEXT:
"
  o (Standards Track) Protocol extensions to convey a richer set of
    attributes to allow applications to choose better connection and 
    determine not only "where" to connect but also "when" to connect.  
"

[Qin]: I think this paragraph is also applied to the 1st bullet.

[Qin]: Can the structure of a network graph be used to discover
SF node in the service function chain?

[Qin]: is this existing work item we have not completed? Or you intend to
Expand deployment document to support more CDN network and data center network use cases?

When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real
feasibility:

After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data.  In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state.

Issues related to the specific content exchanged in systems that make use of ALTO are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content.

Milestones

[Qin]: I think the last two milestones timeframe should be corrected as "Sep 2014" or 
Endpoint property extension document may be changed into "July 2014". I am not sure
We should wait for quite a long time to get these work done.