Nicholas Weaver | 1 Oct 17:38 2010
Picon

Re: P2P CDN integrated in Wikipedia


A fair number of online games that are big use P2P, notably the Blizzard games (Warcraft, Starcraft) to push
out large updates.

This is mostly done not for performance reasons but for economic reasons: shifting the cost for delivering
large (often VERY large) patches or even entire games (eg, Starcraft is several GB) from the content
provider to the recipient's ISP.

And economic constraints are what makes P2P interesting.

Localization helps in such a framework, by deloading the access link network both up and down, but does
nothing to deload the last mile network which for some networks (eg, DOCSIS) can be the big
bottleneck/problem on P2P traffic, which means that although localization would improve the P2P
traffic, the cost to the ISP might still be much greater than non-P2P if the local-access uplink costs more
than the general access downlink.  

In fact, some ISPs would benefit from configuring the local Alto service to AVOID local seeds to save money,
if Cost(local uplink) > (Cost(access uplink) + Cost(access downlink)).

On Sep 30, 2010, at 8:02 AM, Rimac, Ivica (Ivica) wrote:

> I agree with the huge number of Wikipedia users, but Victor’s point makes sense. The demand for a service
like alto depends on the pain the generated traffic causes to the ISPs—why bother if you can squeeze out
an improvement of lower digit percent (the voice of devil’s advocate in me ;) )?
>  
> A related question, does anybody know of Akamai’s position for alto-like services for their
NetSession solution? I am not aware of how prominent this is anyway though I read somewhere that it is being
used for distribution of games.
Y.J. GU | 9 Oct 09:18 2010

How Data Center Virtualization influence ALTO mechanism.

Hi all, 
I was thinking about how Data Center Virtualization and Virtual Machine(VM) Migration will influence
ALTO mechanism.

Current ALTO Protocol defines clustering of peers according to their IP Addresses. E.g. peers in same
subnet will be classified into same PID, and path cost will indicate the cost within and between PIDs,
which is also actually based on IP Addresses.

In the current world, peers are partitioned by IP subnet. While considering virtual machines migration,
there might be more interesting things to think of.

In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the
IP Addresses will not change, so that the existing service connection will not be broken'.  VMs can migrate
to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data Center A(IP
subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0). IP-based, Vms are closer to DC-A.
Physically, these VMs are much closer to hosts in DC-B. However things are not so easy, especially
considering how these VMs are routed. Current ALTO may give wrong cost ranking.

VMs may migrate under, but not limited to, these situations: 1) to save electricity power, 2) disaster
recovery, 3) customer prefer another Data Center, 4) company extension, etc. In the end, the internet
will not be a regular world partitioned by IP Addresses.

Does anyone think this is an interesting aspect to study?

Tao Ma | 12 Oct 04:44 2010
Picon

Re: How Data Center Virtualization influence ALTO mechanism.

Hi,
    I think it is an interesting aspect for ALTO protocol to be considered. The current ALTO uses IP address as the endpoint adress for grouping and locating. For the VM migration, this would fail, especailly without the contol of the ISP or ALTO service provider. Can ALTO mechanism make some changes to reflect this migration in some way? By using other alternatives such as geolocations or PoP to group, can we avoid this and how?
PS: I have a question personally. How the routing would succeed after VM are migrated without changing IP adress? Can you tell me some current mechanism? Thanks:)
Tao Ma
Beijing University of Posts and Telecommunications
 

From: Y.J. GU <guyingjie <at> huawei.com>
Date: Sat, Oct 9, 2010 at 3:18 AM
Subject: [alto] How Data Center Virtualization influence ALTO mechanism.
To: alto <at> ietf.org


Hi all,
I was thinking about how Data Center Virtualization and Virtual Machine(VM) Migration will influence ALTO mechanism.

Current ALTO Protocol defines clustering of peers according to their IP Addresses. E.g. peers in same subnet will be classified into same PID, and path cost will indicate the cost within and between PIDs, which is also actually based on IP Addresses.

In the current world, peers are partitioned by IP subnet. While considering virtual machines migration, there might be more interesting things to think of.

In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the IP Addresses will not change, so that the existing service connection will not be broken'.  VMs can migrate to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data Center A(IP subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0). IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to hosts in DC-B. However things are not so easy, especially considering how these VMs are routed. Current ALTO may give wrong cost ranking.

VMs may migrate under, but not limited to, these situations: 1) to save electricity power, 2) disaster recovery, 3) customer prefer another Data Center, 4) company extension, etc. In the end, the internet will not be a regular world partitioned by IP Addresses.

Does anyone think this is an interesting aspect to study?



_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto


<div>
<p>Hi,<br>&nbsp;&nbsp;&nbsp; I think it is an interesting aspect for ALTO protocol to be considered. The current ALTO uses IP address as the endpoint adress for grouping and locating. For the VM migration, this would fail, especailly without the contol of the ISP or ALTO service provider. Can ALTO mechanism make some changes to reflect this migration in some way? By using other alternatives such as geolocations or PoP to group, can we avoid this and how?<br>
PS: I have a question personally. How the routing would succeed after VM are migrated without changing IP adress? Can you tell me some current mechanism? Thanks:)<br>Tao Ma<br>Beijing University of Posts and Telecommunications <br>
&nbsp;<br><br></p>
<div class="gmail_quote"><blockquote class="gmail_quote">
<div class="gmail_quote">From: Y.J. GU <span dir="ltr">&lt;<a href="mailto:guyingjie <at> huawei.com" target="_blank">guyingjie <at> huawei.com</a>&gt;</span><br>

Date: Sat, Oct 9, 2010 at 3:18 AM<br>Subject: [alto] How Data Center Virtualization influence ALTO mechanism.<br>To: <a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br><br><br>Hi all,<br>
I was thinking about how Data Center Virtualization and Virtual Machine(VM) Migration will influence ALTO mechanism.<br><br>
Current ALTO Protocol defines clustering of peers according to their IP Addresses. E.g. peers in same subnet will be classified into same PID, and path cost will indicate the cost within and between PIDs, which is also actually based on IP Addresses.<br><br>
In the current world, peers are partitioned by IP subnet. While considering virtual machines migration, there might be more interesting things to think of.<br><br>
In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the IP Addresses will not change, so that the existing service connection will not be broken'. &nbsp;VMs can migrate to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data Center A(IP subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0). IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to hosts in DC-B. However things are not so easy, especially considering how these VMs are routed. Current ALTO may give wrong cost ranking.<br><br>
VMs may migrate under, but not limited to, these situations: 1) to save electricity power, 2) disaster recovery, 3) customer prefer another Data Center, 4) company extension, etc. In the end, the internet will not be a regular world partitioned by IP Addresses.<br><br>
Does anyone think this is an interesting aspect to study?<br><br><br><br>
_______________________________________________<br>
alto mailing list<br><a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a><br>
</div>
<br>
</blockquote></div>
<br>
</div>
Lars Eggert | 12 Oct 09:17 2010
Picon

Re: How Data Center Virtualization influence ALTO mechanism.

Hi,

On 2010-10-9, at 10:18, Y.J. GU wrote:
> In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the
IP Addresses will not change, so that the existing service connection will not be broken'.

inside one data center, sure. Maybe even across data centers, with PI space and a coordinated route update.
But I don't think that'd common practice.

>  VMs can migrate to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data
Center A(IP subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0).

Huh? Didn't you just say above that the IP addresses wouldn't change?

> IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to hosts in DC-B. However things
are not so easy, especially considering how these VMs are routed. Current ALTO may give wrong cost ranking.

If you're moving VMs around in the topology, you'll have to update the announced ALTO information as you do
that. 

But since ALTO merely "provide(s) applications with information to perform better-than-random initial
peer selection" - a direct quote from the charter - inaccurate or incorrect ALTO information is not
catastrophic anyway.

Lars
Attachment (smime.p7s): application/pkcs7-signature, 5155 bytes
Hi,

On 2010-10-9, at 10:18, Y.J. GU wrote:
> In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the
IP Addresses will not change, so that the existing service connection will not be broken'.

inside one data center, sure. Maybe even across data centers, with PI space and a coordinated route update.
But I don't think that'd common practice.

>  VMs can migrate to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data
Center A(IP subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0).

Huh? Didn't you just say above that the IP addresses wouldn't change?

> IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to hosts in DC-B. However things
are not so easy, especially considering how these VMs are routed. Current ALTO may give wrong cost ranking.

If you're moving VMs around in the topology, you'll have to update the announced ALTO information as you do
that. 

But since ALTO merely "provide(s) applications with information to perform better-than-random initial
peer selection" - a direct quote from the charter - inaccurate or incorrect ALTO information is not
catastrophic anyway.

Lars
Enrico Marocco | 12 Oct 10:26 2010
Picon

Re: How Data Center Virtualization influence ALTO mechanism.

On 10/12/10 9:17 AM, Lars Eggert wrote:
>> IP-based, Vms are closer to DC-A. Physically, these VMs are much
>> closer to hosts in DC-B. However things are not so easy, especially
>> considering how these VMs are routed. Current ALTO may give wrong
>> cost ranking.
> 
> If you're moving VMs around in the topology, you'll have to update
> the announced ALTO information as you do that.

According to a presentation I saw last year, this is actually what
happens in Facebook's server farms, where BitTorrent and a customized
locality-aware tracker are used to distribute software updates
minimizing inter-rack traffic. Whenever the topology changes -- and I
guess that happens quite often -- the updated information is directly
loaded into the tracker. I don't remember how the update mechanism works
in that specific case, but I guess that could be quite effectively
automated with some kind of integration between the ALTO-like service
and some IGP database.

I can't find a pointer to that presentation, but an article and a video
explaining how software update works in Facebook is available on
TorrentFreak:
http://torrentfreak.com/facebook-uses-bittorrent-and-they-love-it-100625/

-- 
Ciao,
Enrico

Attachment (smime.p7s): application/pkcs7-signature, 8 KiB
On 10/12/10 9:17 AM, Lars Eggert wrote:
>> IP-based, Vms are closer to DC-A. Physically, these VMs are much
>> closer to hosts in DC-B. However things are not so easy, especially
>> considering how these VMs are routed. Current ALTO may give wrong
>> cost ranking.
> 
> If you're moving VMs around in the topology, you'll have to update
> the announced ALTO information as you do that.

According to a presentation I saw last year, this is actually what
happens in Facebook's server farms, where BitTorrent and a customized
locality-aware tracker are used to distribute software updates
minimizing inter-rack traffic. Whenever the topology changes -- and I
guess that happens quite often -- the updated information is directly
loaded into the tracker. I don't remember how the update mechanism works
in that specific case, but I guess that could be quite effectively
automated with some kind of integration between the ALTO-like service
and some IGP database.

I can't find a pointer to that presentation, but an article and a video
explaining how software update works in Facebook is available on
TorrentFreak:
http://torrentfreak.com/facebook-uses-bittorrent-and-they-love-it-100625/

--

-- 
Ciao,
Enrico

IESG Secretary | 12 Oct 19:39 2010
Picon

WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

The Application-Layer Traffic Optimization (alto) working group in the
Applications Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Application-Layer Traffic Optimization (alto)
---------------------------------------------
Current Status: Active Working Group

 Chairs:
     Jon Peterson <jon.peterson <at> neustar.biz>
     Vijay Gurbani <vkg <at> bell-labs.com>
     Enrico Marocco <enrico.marocco <at> telecomitalia.it>

 Applications Area Directors:
     Alexey Melnikov <alexey.melnikov <at> isode.com>
     Peter Saint-Andre <stpeter <at> stpeter.im>

 Applications Area Advisor:
     Peter Saint-Andre <stpeter <at> stpeter.im>

 Mailing Lists:
     General Discussion: alto <at> ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/alto
     Archive:           
http://www.ietf.org/mail-archive/web/alto/current/maillist.html

Description of Working Group:

  A significant part of the Internet traffic today is generated by
  peer-to-peer (P2P) applications used for file sharing, real-time
  communications, and live media streaming.  P2P applications exchange
  large amounts of data, often uploading as much as downloading.  In
  contrast to client/server architectures, P2P applications often must
  choose one or more suitable candidates from a selection of peers
  offering the same resource or service.

  One of the advantages of P2P systems comes from redundancy in resource
  availability.  This requires choosing among a list of peers, yet
  applications have at best incomplete information to help the
  selection, e.g., topology of the network.

  Applications can sometimes obtain network information dynamically or
  measure link performance with respect to particular peers, but even
  when this is an option it takes time.  The application cannot always
  start out with an optimal arrangement of peers, thus risking at least
  temporary poor performance and excessive cross-domain traffic.  
  Providing more information for use in peer selection can
  improve P2P performance and lower ISP costs.

  The Working Group will design and specify an Application-Layer Traffic
  Optimization (ALTO) service that will provide applications with
  information to perform better-than-random initial peer selection.
  ALTO services may take different approaches at balancing factors such
  as maximum bandwidth, minimum cross-domain traffic, lowest cost to the
  user, etc.  The WG will consider the needs of BitTorrent, tracker-less
  P2P, and other applications, such as content delivery networks (CDN)
  and mirror selection.

  The WG will focus on the following items:

  - A "problem statement" document providing a description of the
  problem and a common terminology.

  - A requirements document.  This document will list requirements for
  the ALTO service, identifying, for example, types of information P2P
  applications may need for optimizing their choices.

  - A request/response protocol for querying the ALTO service to obtain
  information useful for peer selection, and a format for requests and
  responses.  If the requirements analysis identifies the need to allow
  clients to delegate third-parties to query the ALTO service on their
  behalf, the WG will ensure that the protocol provides a mechanism to
  assert the consent of the delegating client.

  - A specification of core request and response formats and semantics
  to communicate network preferences to applications.  Since ALTO
  services may be run by entities with different levels of knowledge
  about the underlying network, such preferences may have different
  representations.  Initially the WG will consider: IP ranges to prefer
  and to avoid, ranked lists of the peers requested by the client,
  information about topological proximity and approximate geographic
  locations.  Other usages will be considered as charter additions once
  the work for the initial services has been completed.

  - In order to query the ALTO server, clients must first know one or
  more ALTO servers that might provide useful information.  The WG will
  look at service discovery mechanisms that are in use, or defined
  elsewhere (e.g. based on DNS SRV records or DHCP options).  If such
  discovery mechanisms can be reused, the WG will produce a document to
  specify how they may be adopted for locating such servers.  However, a
  new, general-purpose service discovery mechanism is not in scope.

  - An informational document discussing deployment related issues and
  documenting 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?

  - Is it information that a client will find useful?

  - Can a client get that information without excessive privacy concerns
  (e.g. by sending large lists of peers)?

  - 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.  Such issues belong to other IETF areas and will be treated
  accordingly by the specific area.

  This WG will focus solely on the communication protocol between
  applications and ALTO servers.  Note that ALTO services may be useful
  in client-server environments as well as P2P environments, although
  P2P environments are the first focus.  If, in the future, the IETF
  considers changes to other protocols for actually implementing ALTO
  services (e.g. application-layer protocols for Internet coordinate
  systems, routing protocol extensions for ISP-based solutions), such
  work will be done in strict coordination with the appropriate WGs.

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

Goals and Milestones:

  Done     - Working Group Last Call for problem statement
  Done     - Submit problem statement to IESG as Informational
  Jan 2011 - Working Group Last Call for requirements document
  Jan 2011 - Working Group Last Call for request/response protocol
  Mar 2011 - Submit request/response protocol to IESG as Proposed
             Standard
  Mar 2011 - Submit requirements document to IESG as Informational
  May 2011 - Working Group Last Call of deployment considerations
             document
  Aug 2011 - Submit deployment considerations document to IESG as
             Informational
  Nov 2011 - Working Group Last Call of discovery mechanism
  Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard
  Mar 2012 - Dissolve or re-charter

朱潇 | 13 Oct 04:26 2010
Picon

Re: WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

hi, all


has the new version of alto charter been synchronized to the ietf alo index?
can anyone be kind to give the last version of the alto charter so that we can know what has been updated?

On Wed, Oct 13, 2010 at 1:39 AM, IESG Secretary <iesg-secretary <at> ietf.org> wrote:
The Application-Layer Traffic Optimization (alto) working group in the
Applications Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Application-Layer Traffic Optimization (alto)
---------------------------------------------
Current Status: Active Working Group

 Chairs:
    Jon Peterson <jon.peterson <at> neustar.biz>
    Vijay Gurbani <vkg <at> bell-labs.com>
    Enrico Marocco <enrico.marocco <at> telecomitalia.it>

 Applications Area Directors:
    Alexey Melnikov <alexey.melnikov <at> isode.com>
    Peter Saint-Andre <stpeter <at> stpeter.im>

 Applications Area Advisor:
    Peter Saint-Andre <stpeter <at> stpeter.im>

 Mailing Lists:
    General Discussion: alto <at> ietf.org
    To Subscribe:       https://www.ietf.org/mailman/listinfo/alto
    Archive:
http://www.ietf.org/mail-archive/web/alto/current/maillist.html

Description of Working Group:

 A significant part of the Internet traffic today is generated by
 peer-to-peer (P2P) applications used for file sharing, real-time
 communications, and live media streaming.  P2P applications exchange
 large amounts of data, often uploading as much as downloading.  In
 contrast to client/server architectures, P2P applications often must
 choose one or more suitable candidates from a selection of peers
 offering the same resource or service.

 One of the advantages of P2P systems comes from redundancy in resource
 availability.  This requires choosing among a list of peers, yet
 applications have at best incomplete information to help the
 selection, e.g., topology of the network.

 Applications can sometimes obtain network information dynamically or
 measure link performance with respect to particular peers, but even
 when this is an option it takes time.  The application cannot always
 start out with an optimal arrangement of peers, thus risking at least
 temporary poor performance and excessive cross-domain traffic.
 Providing more information for use in peer selection can
 improve P2P performance and lower ISP costs.

 The Working Group will design and specify an Application-Layer Traffic
 Optimization (ALTO) service that will provide applications with
 information to perform better-than-random initial peer selection.
 ALTO services may take different approaches at balancing factors such
 as maximum bandwidth, minimum cross-domain traffic, lowest cost to the
 user, etc.  The WG will consider the needs of BitTorrent, tracker-less
 P2P, and other applications, such as content delivery networks (CDN)
 and mirror selection.

 The WG will focus on the following items:

 - A "problem statement" document providing a description of the
 problem and a common terminology.

 - A requirements document.  This document will list requirements for
 the ALTO service, identifying, for example, types of information P2P
 applications may need for optimizing their choices.

 - A request/response protocol for querying the ALTO service to obtain
 information useful for peer selection, and a format for requests and
 responses.  If the requirements analysis identifies the need to allow
 clients to delegate third-parties to query the ALTO service on their
 behalf, the WG will ensure that the protocol provides a mechanism to
 assert the consent of the delegating client.

 - A specification of core request and response formats and semantics
 to communicate network preferences to applications.  Since ALTO
 services may be run by entities with different levels of knowledge
 about the underlying network, such preferences may have different
 representations.  Initially the WG will consider: IP ranges to prefer
 and to avoid, ranked lists of the peers requested by the client,
 information about topological proximity and approximate geographic
 locations.  Other usages will be considered as charter additions once
 the work for the initial services has been completed.

 - In order to query the ALTO server, clients must first know one or
 more ALTO servers that might provide useful information.  The WG will
 look at service discovery mechanisms that are in use, or defined
 elsewhere (e.g. based on DNS SRV records or DHCP options).  If such
 discovery mechanisms can be reused, the WG will produce a document to
 specify how they may be adopted for locating such servers.  However, a
 new, general-purpose service discovery mechanism is not in scope.

 - An informational document discussing deployment related issues and
 documenting 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?

 - Is it information that a client will find useful?

 - Can a client get that information without excessive privacy concerns
 (e.g. by sending large lists of peers)?

 - 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.  Such issues belong to other IETF areas and will be treated
 accordingly by the specific area.

 This WG will focus solely on the communication protocol between
 applications and ALTO servers.  Note that ALTO services may be useful
 in client-server environments as well as P2P environments, although
 P2P environments are the first focus.  If, in the future, the IETF
 considers changes to other protocols for actually implementing ALTO
 services (e.g. application-layer protocols for Internet coordinate
 systems, routing protocol extensions for ISP-based solutions), such
 work will be done in strict coordination with the appropriate WGs.

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

Goals and Milestones:

 Done     - Working Group Last Call for problem statement
 Done     - Submit problem statement to IESG as Informational
 Jan 2011 - Working Group Last Call for requirements document
 Jan 2011 - Working Group Last Call for request/response protocol
 Mar 2011 - Submit request/response protocol to IESG as Proposed
            Standard
 Mar 2011 - Submit requirements document to IESG as Informational
 May 2011 - Working Group Last Call of deployment considerations
            document
 Aug 2011 - Submit deployment considerations document to IESG as
            Informational
 Nov 2011 - Working Group Last Call of discovery mechanism
 Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard
 Mar 2012 - Dissolve or re-charter

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto



--
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( 朱潇 )
E-mail: buptxiaozhu <at> gmail.com
mobile:+86 134-8881-9004
<div>
<p>hi, all</p>
<div><br></div>
<div>has the new version of alto charter been synchronized to the ietf alo index?</div>
<div>can anyone be kind to give the last version of the alto charter so that we can know what has been updated?<br><br><div class="gmail_quote">On Wed, Oct 13, 2010 at 1:39 AM, IESG Secretary <span dir="ltr">&lt;<a href="mailto:iesg-secretary <at> ietf.org" target="_blank">iesg-secretary <at> ietf.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">The Application-Layer Traffic Optimization (alto) working group in the<br>
Applications Area of the IETF has been rechartered. &nbsp;For additional<br>
information, please contact the Area Directors or the working group<br>
Chairs.<br><br>
Application-Layer Traffic Optimization (alto)<br>
---------------------------------------------<br>
Current Status: Active Working Group<br><br>
&nbsp;Chairs:<br>
 &nbsp; &nbsp; Jon Peterson &lt;<a href="mailto:jon.peterson <at> neustar.biz" target="_blank">jon.peterson <at> neustar.biz</a>&gt;<br>
 &nbsp; &nbsp; Vijay Gurbani &lt;<a href="mailto:vkg <at> bell-labs.com" target="_blank">vkg <at> bell-labs.com</a>&gt;<br>
 &nbsp; &nbsp; Enrico Marocco &lt;<a href="mailto:enrico.marocco <at> telecomitalia.it" target="_blank">enrico.marocco <at> telecomitalia.it</a>&gt;<br><br>
&nbsp;Applications Area Directors:<br>
 &nbsp; &nbsp; Alexey Melnikov &lt;<a href="mailto:alexey.melnikov <at> isode.com" target="_blank">alexey.melnikov <at> isode.com</a>&gt;<br>
 &nbsp; &nbsp; Peter Saint-Andre &lt;<a href="mailto:stpeter <at> stpeter.im" target="_blank">stpeter <at> stpeter.im</a>&gt;<br><br>
&nbsp;Applications Area Advisor:<br>
 &nbsp; &nbsp; Peter Saint-Andre &lt;<a href="mailto:stpeter <at> stpeter.im" target="_blank">stpeter <at> stpeter.im</a>&gt;<br><br>
&nbsp;Mailing Lists:<br>
 &nbsp; &nbsp; General Discussion: <a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br>
 &nbsp; &nbsp; To Subscribe: &nbsp; &nbsp; &nbsp; <a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a><br>
 &nbsp; &nbsp; Archive:<br><a href="http://www.ietf.org/mail-archive/web/alto/current/maillist.html" target="_blank">http://www.ietf.org/mail-archive/web/alto/current/maillist.html</a><br><br>
Description of Working Group:<br><br>
 &nbsp;A significant part of the Internet traffic today is generated by<br>
 &nbsp;peer-to-peer (P2P) applications used for file sharing, real-time<br>
 &nbsp;communications, and live media streaming. &nbsp;P2P applications exchange<br>
 &nbsp;large amounts of data, often uploading as much as downloading. &nbsp;In<br>
 &nbsp;contrast to client/server architectures, P2P applications often must<br>
 &nbsp;choose one or more suitable candidates from a selection of peers<br>
 &nbsp;offering the same resource or service.<br><br>
 &nbsp;One of the advantages of P2P systems comes from redundancy in resource<br>
 &nbsp;availability. &nbsp;This requires choosing among a list of peers, yet<br>
 &nbsp;applications have at best incomplete information to help the<br>
 &nbsp;selection, e.g., topology of the network.<br><br>
 &nbsp;Applications can sometimes obtain network information dynamically or<br>
 &nbsp;measure link performance with respect to particular peers, but even<br>
 &nbsp;when this is an option it takes time. &nbsp;The application cannot always<br>
 &nbsp;start out with an optimal arrangement of peers, thus risking at least<br>
 &nbsp;temporary poor performance and excessive cross-domain traffic.<br>
 &nbsp;Providing more information for use in peer selection can<br>
 &nbsp;improve P2P performance and lower ISP costs.<br><br>
 &nbsp;The Working Group will design and specify an Application-Layer Traffic<br>
 &nbsp;Optimization (ALTO) service that will provide applications with<br>
 &nbsp;information to perform better-than-random initial peer selection.<br>
 &nbsp;ALTO services may take different approaches at balancing factors such<br>
 &nbsp;as maximum bandwidth, minimum cross-domain traffic, lowest cost to the<br>
 &nbsp;user, etc. &nbsp;The WG will consider the needs of BitTorrent, tracker-less<br>
 &nbsp;P2P, and other applications, such as content delivery networks (CDN)<br>
 &nbsp;and mirror selection.<br><br>
 &nbsp;The WG will focus on the following items:<br><br>
 &nbsp;- A "problem statement" document providing a description of the<br>
 &nbsp;problem and a common terminology.<br><br>
 &nbsp;- A requirements document. &nbsp;This document will list requirements for<br>
 &nbsp;the ALTO service, identifying, for example, types of information P2P<br>
 &nbsp;applications may need for optimizing their choices.<br><br>
 &nbsp;- A request/response protocol for querying the ALTO service to obtain<br>
 &nbsp;information useful for peer selection, and a format for requests and<br>
 &nbsp;responses. &nbsp;If the requirements analysis identifies the need to allow<br>
 &nbsp;clients to delegate third-parties to query the ALTO service on their<br>
 &nbsp;behalf, the WG will ensure that the protocol provides a mechanism to<br>
 &nbsp;assert the consent of the delegating client.<br><br>
 &nbsp;- A specification of core request and response formats and semantics<br>
 &nbsp;to communicate network preferences to applications. &nbsp;Since ALTO<br>
 &nbsp;services may be run by entities with different levels of knowledge<br>
 &nbsp;about the underlying network, such preferences may have different<br>
 &nbsp;representations. &nbsp;Initially the WG will consider: IP ranges to prefer<br>
 &nbsp;and to avoid, ranked lists of the peers requested by the client,<br>
 &nbsp;information about topological proximity and approximate geographic<br>
 &nbsp;locations. &nbsp;Other usages will be considered as charter additions once<br>
 &nbsp;the work for the initial services has been completed.<br><br>
 &nbsp;- In order to query the ALTO server, clients must first know one or<br>
 &nbsp;more ALTO servers that might provide useful information. &nbsp;The WG will<br>
 &nbsp;look at service discovery mechanisms that are in use, or defined<br>
 &nbsp;elsewhere (e.g. based on DNS SRV records or DHCP options). &nbsp;If such<br>
 &nbsp;discovery mechanisms can be reused, the WG will produce a document to<br>
 &nbsp;specify how they may be adopted for locating such servers. &nbsp;However, a<br>
 &nbsp;new, general-purpose service discovery mechanism is not in scope.<br><br>
 &nbsp;- An informational document discussing deployment related issues and<br>
 &nbsp;documenting lessons learned from early implementation experiences.<br><br>
 &nbsp;When the WG considers standardizing information that the ALTO server<br>
 &nbsp;could provide, the following criteria are important to ensure real<br>
 &nbsp;feasibility:<br><br>
 &nbsp;- Can the ALTO service realistically discover that information?<br><br>
 &nbsp;- Is the distribution of that information allowed by the operators of<br>
 &nbsp;that service?<br><br>
 &nbsp;- Is it information that a client will find useful?<br><br>
 &nbsp;- Can a client get that information without excessive privacy concerns<br>
 &nbsp;(e.g. by sending large lists of peers)?<br><br>
 &nbsp;- Is it information that a client cannot find easily some other way?<br><br>
 &nbsp;After these criteria are met, the importance of the data will be<br>
 &nbsp;considered for prioritizing standardization work, for example the<br>
 &nbsp;number of operators and clients that are likely to be able to provide<br>
 &nbsp;or use that particular data. &nbsp;In any case, this WG will not propose<br>
 &nbsp;standards on how congestion is signaled, remediated, or avoided, and<br>
 &nbsp;will not deal with information representing instantaneous network<br>
 &nbsp;state. &nbsp;Such issues belong to other IETF areas and will be treated<br>
 &nbsp;accordingly by the specific area.<br><br>
 &nbsp;This WG will focus solely on the communication protocol between<br>
 &nbsp;applications and ALTO servers. &nbsp;Note that ALTO services may be useful<br>
 &nbsp;in client-server environments as well as P2P environments, although<br>
 &nbsp;P2P environments are the first focus. &nbsp;If, in the future, the IETF<br>
 &nbsp;considers changes to other protocols for actually implementing ALTO<br>
 &nbsp;services (e.g. application-layer protocols for Internet coordinate<br>
 &nbsp;systems, routing protocol extensions for ISP-based solutions), such<br>
 &nbsp;work will be done in strict coordination with the appropriate WGs.<br><br>
 &nbsp;Issues related to the content exchanged in P2P systems are also<br>
 &nbsp;excluded from the WG's scope, as is the issue dealing with enforcing<br>
 &nbsp;the legality of the content.<br><br>
Goals and Milestones:<br><br>
 &nbsp;Done &nbsp; &nbsp; - Working Group Last Call for problem statement<br>
 &nbsp;Done &nbsp; &nbsp; - Submit problem statement to IESG as Informational<br>
 &nbsp;Jan 2011 - Working Group Last Call for requirements document<br>
 &nbsp;Jan 2011 - Working Group Last Call for request/response protocol<br>
 &nbsp;Mar 2011 - Submit request/response protocol to IESG as Proposed<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Standard<br>
 &nbsp;Mar 2011 - Submit requirements document to IESG as Informational<br>
 &nbsp;May 2011 - Working Group Last Call of deployment considerations<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; document<br>
 &nbsp;Aug 2011 - Submit deployment considerations document to IESG as<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Informational<br>
 &nbsp;Nov 2011 - Working Group Last Call of discovery mechanism<br>
 &nbsp;Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard<br>
 &nbsp;Mar 2012 - Dissolve or re-charter<br><br>
_______________________________________________<br>
alto mailing list<br><a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a><br>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>Best wishes,<br><br>Beijing University of Posts &amp; Telecommunications (BUPT)<br>Zhu Xiao&nbsp; ( &#26417;&#28487; )<br>E-mail: <a href="mailto:buptxiaozhu <at> gmail.com" target="_blank">buptxiaozhu <at> gmail.com</a><br>

mobile:+86 134-8881-9004<br>
</div>
</div>
Y.J. GU | 13 Oct 04:34 2010

Re: WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

Go to this page, you can find all the history of Charter.

http://tools.ietf.org/wg/alto/charters?item=charter.2010-10-12_2010,1.txt

From: alto-bounces <at> ietf.org [mailto:alto-bounces <at> ietf.org] On Behalf Of 朱潇
Sent: Wednesday, October 13, 2010 10:26 AM
To: IESG Secretary
Cc: alto <at> ietf.org; IETF Announcement list
Subject: Re: [alto] WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

 

hi, all

 

has the new version of alto charter been synchronized to the ietf alo index?

can anyone be kind to give the last version of the alto charter so that we can know what has been updated?

On Wed, Oct 13, 2010 at 1:39 AM, IESG Secretary <iesg-secretary <at> ietf.org> wrote:

The Application-Layer Traffic Optimization (alto) working group in the
Applications Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Application-Layer Traffic Optimization (alto)
---------------------------------------------
Current Status: Active Working Group

 Chairs:
    Jon Peterson <jon.peterson <at> neustar.biz>
    Vijay Gurbani <vkg <at> bell-labs.com>
    Enrico Marocco <enrico.marocco <at> telecomitalia.it>

 Applications Area Directors:
    Alexey Melnikov <alexey.melnikov <at> isode.com>
    Peter Saint-Andre <stpeter <at> stpeter.im>

 Applications Area Advisor:
    Peter Saint-Andre <stpeter <at> stpeter.im>

 Mailing Lists:
    General Discussion: alto <at> ietf.org
    To Subscribe:       https://www.ietf.org/mailman/listinfo/alto
    Archive:
http://www.ietf.org/mail-archive/web/alto/current/maillist.html

Description of Working Group:

 A significant part of the Internet traffic today is generated by
 peer-to-peer (P2P) applications used for file sharing, real-time
 communications, and live media streaming.  P2P applications exchange
 large amounts of data, often uploading as much as downloading.  In
 contrast to client/server architectures, P2P applications often must
 choose one or more suitable candidates from a selection of peers
 offering the same resource or service.

 One of the advantages of P2P systems comes from redundancy in resource
 availability.  This requires choosing among a list of peers, yet
 applications have at best incomplete information to help the
 selection, e.g., topology of the network.

 Applications can sometimes obtain network information dynamically or
 measure link performance with respect to particular peers, but even
 when this is an option it takes time.  The application cannot always
 start out with an optimal arrangement of peers, thus risking at least
 temporary poor performance and excessive cross-domain traffic.
 Providing more information for use in peer selection can
 improve P2P performance and lower ISP costs.

 The Working Group will design and specify an Application-Layer Traffic
 Optimization (ALTO) service that will provide applications with
 information to perform better-than-random initial peer selection.
 ALTO services may take different approaches at balancing factors such
 as maximum bandwidth, minimum cross-domain traffic, lowest cost to the
 user, etc.  The WG will consider the needs of BitTorrent, tracker-less
 P2P, and other applications, such as content delivery networks (CDN)
 and mirror selection.

 The WG will focus on the following items:

 - A "problem statement" document providing a description of the
 problem and a common terminology.

 - A requirements document.  This document will list requirements for
 the ALTO service, identifying, for example, types of information P2P
 applications may need for optimizing their choices.

 - A request/response protocol for querying the ALTO service to obtain
 information useful for peer selection, and a format for requests and
 responses.  If the requirements analysis identifies the need to allow
 clients to delegate third-parties to query the ALTO service on their
 behalf, the WG will ensure that the protocol provides a mechanism to
 assert the consent of the delegating client.

 - A specification of core request and response formats and semantics
 to communicate network preferences to applications.  Since ALTO
 services may be run by entities with different levels of knowledge
 about the underlying network, such preferences may have different
 representations.  Initially the WG will consider: IP ranges to prefer
 and to avoid, ranked lists of the peers requested by the client,
 information about topological proximity and approximate geographic
 locations.  Other usages will be considered as charter additions once
 the work for the initial services has been completed.

 - In order to query the ALTO server, clients must first know one or
 more ALTO servers that might provide useful information.  The WG will
 look at service discovery mechanisms that are in use, or defined
 elsewhere (e.g. based on DNS SRV records or DHCP options).  If such
 discovery mechanisms can be reused, the WG will produce a document to
 specify how they may be adopted for locating such servers.  However, a
 new, general-purpose service discovery mechanism is not in scope.

 - An informational document discussing deployment related issues and
 documenting 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?

 - Is it information that a client will find useful?

 - Can a client get that information without excessive privacy concerns
 (e.g. by sending large lists of peers)?

 - 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.  Such issues belong to other IETF areas and will be treated
 accordingly by the specific area.

 This WG will focus solely on the communication protocol between
 applications and ALTO servers.  Note that ALTO services may be useful
 in client-server environments as well as P2P environments, although
 P2P environments are the first focus.  If, in the future, the IETF
 considers changes to other protocols for actually implementing ALTO
 services (e.g. application-layer protocols for Internet coordinate
 systems, routing protocol extensions for ISP-based solutions), such
 work will be done in strict coordination with the appropriate WGs.

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

Goals and Milestones:

 Done     - Working Group Last Call for problem statement
 Done     - Submit problem statement to IESG as Informational
 Jan 2011 - Working Group Last Call for requirements document
 Jan 2011 - Working Group Last Call for request/response protocol
 Mar 2011 - Submit request/response protocol to IESG as Proposed
            Standard
 Mar 2011 - Submit requirements document to IESG as Informational
 May 2011 - Working Group Last Call of deployment considerations
            document
 Aug 2011 - Submit deployment considerations document to IESG as
            Informational
 Nov 2011 - Working Group Last Call of discovery mechanism
 Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard
 Mar 2012 - Dissolve or re-charter

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto




--
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  (
朱潇 )
E-mail: buptxiaozhu <at> gmail.com
mobile:+86 134-8881-9004

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Go to this page, you can
find all the history of Charter.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><a href="http://tools.ietf.org/wg/alto/charters?item=charter.2010-10-12_2010,1.txt">http://tools.ietf.org/wg/alto/charters?item=charter.2010-10-12_2010,1.txt</a></span><span lang="EN-US"><p></p></span></p>

<div>

<div>

<div class="MsoNormal" align="center"><span lang="EN-US">

</span></div>

<p class="MsoNormal"><span lang="EN-US">From:</span><span lang="EN-US">
alto-bounces <at> ietf.org [mailto:alto-bounces <at> ietf.org] <span>On Behalf Of </span></span><span>&#26417;&#28487;</span><span lang="EN-US"><br><span>Sent:</span> Wednesday, October 13, 2010
10:26 AM<br><span>To:</span> IESG Secretary<br><span>Cc:</span> alto <at> ietf.org; IETF
Announcement list<br><span>Subject:</span> Re: [alto] WG Action:
RECHARTER: Application-Layer Traffic Optimization (alto)</span><span lang="EN-US"><p></p></span></p>

</div>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US"></span><span lang="EN-US">hi, all<p></p></span></p>

<div>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

</div>

<div>

<p class="MsoNormal"><span lang="EN-US">has
the new version of alto charter been synchronized to the ietf alo index?<p></p></span></p>

</div>

<div>

<p class="MsoNormal"><span lang="EN-US">can anyone be kind to give the last version
of the alto charter so that we can know what has been updated?<p></p></span></p>

<div>

<p class="MsoNormal"><span lang="EN-US">On
Wed, Oct 13, 2010 at 1:39 AM, IESG Secretary &lt;<a href="mailto:iesg-secretary <at> ietf.org" target="_blank">iesg-secretary <at> ietf.org</a>&gt;
wrote:<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">The
Application-Layer Traffic Optimization (alto) working group in the<br>
Applications Area of the IETF has been rechartered. &nbsp;For additional<br>
information, please contact the Area Directors or the working group<br>
Chairs.<br><br>
Application-Layer Traffic Optimization (alto)<br>
---------------------------------------------<br>
Current Status: Active Working Group<br><br>
&nbsp;Chairs:<br>
&nbsp; &nbsp; Jon Peterson &lt;<a href="mailto:jon.peterson <at> neustar.biz" target="_blank">jon.peterson <at> neustar.biz</a>&gt;<br>
&nbsp; &nbsp; Vijay Gurbani &lt;<a href="mailto:vkg <at> bell-labs.com" target="_blank">vkg <at> bell-labs.com</a>&gt;<br>
&nbsp; &nbsp; Enrico Marocco &lt;<a href="mailto:enrico.marocco <at> telecomitalia.it" target="_blank">enrico.marocco <at> telecomitalia.it</a>&gt;<br><br>
&nbsp;Applications Area Directors:<br>
&nbsp; &nbsp; Alexey Melnikov &lt;<a href="mailto:alexey.melnikov <at> isode.com" target="_blank">alexey.melnikov <at> isode.com</a>&gt;<br>
&nbsp; &nbsp; Peter Saint-Andre &lt;<a href="mailto:stpeter <at> stpeter.im" target="_blank">stpeter <at> stpeter.im</a>&gt;<br><br>
&nbsp;Applications Area Advisor:<br>
&nbsp; &nbsp; Peter Saint-Andre &lt;<a href="mailto:stpeter <at> stpeter.im" target="_blank">stpeter <at> stpeter.im</a>&gt;<br><br>
&nbsp;Mailing Lists:<br>
&nbsp; &nbsp; General Discussion: <a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br>
&nbsp; &nbsp; To Subscribe: &nbsp; &nbsp; &nbsp; <a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a><br>
&nbsp; &nbsp; Archive:<br><a href="http://www.ietf.org/mail-archive/web/alto/current/maillist.html" target="_blank">http://www.ietf.org/mail-archive/web/alto/current/maillist.html</a><br><br>
Description of Working Group:<br><br>
&nbsp;A significant part of the Internet traffic today is generated by<br>
&nbsp;peer-to-peer (P2P) applications used for file sharing, real-time<br>
&nbsp;communications, and live media streaming. &nbsp;P2P applications exchange<br>
&nbsp;large amounts of data, often uploading as much as downloading. &nbsp;In<br>
&nbsp;contrast to client/server architectures, P2P applications often must<br>
&nbsp;choose one or more suitable candidates from a selection of peers<br>
&nbsp;offering the same resource or service.<br><br>
&nbsp;One of the advantages of P2P systems comes from redundancy in resource<br>
&nbsp;availability. &nbsp;This requires choosing among a list of peers, yet<br>
&nbsp;applications have at best incomplete information to help the<br>
&nbsp;selection, e.g., topology of the network.<br><br>
&nbsp;Applications can sometimes obtain network information dynamically or<br>
&nbsp;measure link performance with respect to particular peers, but even<br>
&nbsp;when this is an option it takes time. &nbsp;The application cannot always<br>
&nbsp;start out with an optimal arrangement of peers, thus risking at least<br>
&nbsp;temporary poor performance and excessive cross-domain traffic.<br>
&nbsp;Providing more information for use in peer selection can<br>
&nbsp;improve P2P performance and lower ISP costs.<br><br>
&nbsp;The Working Group will design and specify an Application-Layer Traffic<br>
&nbsp;Optimization (ALTO) service that will provide applications with<br>
&nbsp;information to perform better-than-random initial peer selection.<br>
&nbsp;ALTO services may take different approaches at balancing factors such<br>
&nbsp;as maximum bandwidth, minimum cross-domain traffic, lowest cost to the<br>
&nbsp;user, etc. &nbsp;The WG will consider the needs of BitTorrent,
tracker-less<br>
&nbsp;P2P, and other applications, such as content delivery networks (CDN)<br>
&nbsp;and mirror selection.<br><br>
&nbsp;The WG will focus on the following items:<br><br>
&nbsp;- A "problem statement" document providing a description of the<br>
&nbsp;problem and a common terminology.<br><br>
&nbsp;- A requirements document. &nbsp;This document will list requirements for<br>
&nbsp;the ALTO service, identifying, for example, types of information P2P<br>
&nbsp;applications may need for optimizing their choices.<br><br>
&nbsp;- A request/response protocol for querying the ALTO service to obtain<br>
&nbsp;information useful for peer selection, and a format for requests and<br>
&nbsp;responses. &nbsp;If the requirements analysis identifies the need to
allow<br>
&nbsp;clients to delegate third-parties to query the ALTO service on their<br>
&nbsp;behalf, the WG will ensure that the protocol provides a mechanism to<br>
&nbsp;assert the consent of the delegating client.<br><br>
&nbsp;- A specification of core request and response formats and semantics<br>
&nbsp;to communicate network preferences to applications. &nbsp;Since ALTO<br>
&nbsp;services may be run by entities with different levels of knowledge<br>
&nbsp;about the underlying network, such preferences may have different<br>
&nbsp;representations. &nbsp;Initially the WG will consider: IP ranges to
prefer<br>
&nbsp;and to avoid, ranked lists of the peers requested by the client,<br>
&nbsp;information about topological proximity and approximate geographic<br>
&nbsp;locations. &nbsp;Other usages will be considered as charter additions
once<br>
&nbsp;the work for the initial services has been completed.<br><br>
&nbsp;- In order to query the ALTO server, clients must first know one or<br>
&nbsp;more ALTO servers that might provide useful information. &nbsp;The WG
will<br>
&nbsp;look at service discovery mechanisms that are in use, or defined<br>
&nbsp;elsewhere (e.g. based on DNS SRV records or DHCP options). &nbsp;If such<br>
&nbsp;discovery mechanisms can be reused, the WG will produce a document to<br>
&nbsp;specify how they may be adopted for locating such servers. &nbsp;However,
a<br>
&nbsp;new, general-purpose service discovery mechanism is not in scope.<br><br>
&nbsp;- An informational document discussing deployment related issues and<br>
&nbsp;documenting lessons learned from early implementation experiences.<br><br>
&nbsp;When the WG considers standardizing information that the ALTO server<br>
&nbsp;could provide, the following criteria are important to ensure real<br>
&nbsp;feasibility:<br><br>
&nbsp;- Can the ALTO service realistically discover that information?<br><br>
&nbsp;- Is the distribution of that information allowed by the operators of<br>
&nbsp;that service?<br><br>
&nbsp;- Is it information that a client will find useful?<br><br>
&nbsp;- Can a client get that information without excessive privacy concerns<br>
&nbsp;(e.g. by sending large lists of peers)?<br><br>
&nbsp;- Is it information that a client cannot find easily some other way?<br><br>
&nbsp;After these criteria are met, the importance of the data will be<br>
&nbsp;considered for prioritizing standardization work, for example the<br>
&nbsp;number of operators and clients that are likely to be able to provide<br>
&nbsp;or use that particular data. &nbsp;In any case, this WG will not propose<br>
&nbsp;standards on how congestion is signaled, remediated, or avoided, and<br>
&nbsp;will not deal with information representing instantaneous network<br>
&nbsp;state. &nbsp;Such issues belong to other IETF areas and will be treated<br>
&nbsp;accordingly by the specific area.<br><br>
&nbsp;This WG will focus solely on the communication protocol between<br>
&nbsp;applications and ALTO servers. &nbsp;Note that ALTO services may be
useful<br>
&nbsp;in client-server environments as well as P2P environments, although<br>
&nbsp;P2P environments are the first focus. &nbsp;If, in the future, the IETF<br>
&nbsp;considers changes to other protocols for actually implementing ALTO<br>
&nbsp;services (e.g. application-layer protocols for Internet coordinate<br>
&nbsp;systems, routing protocol extensions for ISP-based solutions), such<br>
&nbsp;work will be done in strict coordination with the appropriate WGs.<br><br>
&nbsp;Issues related to the content exchanged in P2P systems are also<br>
&nbsp;excluded from the WG's scope, as is the issue dealing with enforcing<br>
&nbsp;the legality of the content.<br><br>
Goals and Milestones:<br><br>
&nbsp;Done &nbsp; &nbsp; - Working Group Last Call for problem statement<br>
&nbsp;Done &nbsp; &nbsp; - Submit problem statement to IESG as Informational<br>
&nbsp;Jan 2011 - Working Group Last Call for requirements document<br>
&nbsp;Jan 2011 - Working Group Last Call for request/response protocol<br>
&nbsp;Mar 2011 - Submit request/response protocol to IESG as Proposed<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Standard<br>
&nbsp;Mar 2011 - Submit requirements document to IESG as Informational<br>
&nbsp;May 2011 - Working Group Last Call of deployment considerations<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; document<br>
&nbsp;Aug 2011 - Submit deployment considerations document to IESG as<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Informational<br>
&nbsp;Nov 2011 - Working Group Last Call of discovery mechanism<br>
&nbsp;Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard<br>
&nbsp;Mar 2012 - Dissolve or re-charter<br><br>
_______________________________________________<br>
alto mailing list<br><a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a><p></p></span></p>

</div>

<p class="MsoNormal"><span lang="EN-US"><br><br clear="all"><br>
-- <br>
Best wishes,<br><br>
Beijing University of Posts &amp; Telecommunications (BUPT)<br>
Zhu Xiao&nbsp; ( </span>&#26417;&#28487;<span lang="EN-US"> )<br>
E-mail: <a href="mailto:buptxiaozhu <at> gmail.com" target="_blank">buptxiaozhu <at> gmail.com</a><br>
mobile:+86 134-8881-9004<p></p></span></p>

</div>

</div>

</div>

</div>
Peter Saint-Andre | 13 Oct 04:36 2010

Re: WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

On 10/12/10 8:26 PM, 朱潇 wrote:
> hi, all
> 
> has the new version of alto charter been synchronized to the ietf alo index?
> can anyone be kind to give the last version of the alto charter so that
> we can know what has been updated?

Charters are here: http://tools.ietf.org/wg/alto/charters

The diff between 2010-03-26 and 2010-10-12 is quite small.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto
wangaijun | 13 Oct 05:21 2010
Picon

Re: alto Digest, Vol 24, Issue 5

Hi, Chairs

I have some opinions about current updated ALTO Charter:

In this charter, it is said, "... 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.  Such issues belong to other IETF areas and will be treated accordingly by the specific
area.", let's consider the following scenario:

When one ALTO Clients query the topology information from ALTO Server, is it reasonable that the ALTO
Server neglect the congestion condition of the underlying network? Is it efficient that ALTO Server give
the ALTO Clients initial peer list that most of them are located in congestion area? 

The congestion condition maybe be induced by various reason, I understand that the ALTO should not
consider how to eliminate it, but ALTO should consider how to avoid it, or not exacerbate it. On the other
hand, the information representing network state, not instantaneous, but in statistically in some
period, should be considered.  We can check such information(network state information within some
periods) against the criteria listed in current ALTO charter?

  - Can the ALTO service realistically discover that information?   [Yes, the ISP are monitoring their
network continuously]

  - Is the distribution of that information allowed by the operators of
  that service?    [Yes, the ISP are eager to distribute such information to lessen the congestion condition]

  - Is it information that a client will find useful? [Yes, the client can benefit from the initial peer list
that located in non-congestion area]

  - Can a client get that information without excessive privacy concerns
  (e.g. by sending large lists of peers)?  [Yes, this information does not relate to the privacy of any peer ]

  - Is it information that a client cannot find easily some other way? [Yes, the client must use some detect
algorithm in application layer to find such information]

So, why not consider the dynamic(not instantaneous, but may change aperiodically) network state
information in ALTO service? The ISP can provide such information.

Best Regards.

Wang Aijun
Network Infrastructure Research Division
Network Technology Research Department
China Telecom Coporation Beijing Research Institute

-----邮件原件-----
发件人: alto-bounces <at> ietf.org [mailto:alto-bounces <at> ietf.org] 代表 alto-request <at> ietf.org
发送时间: 2010年10月13日 3:00
收件人: alto <at> ietf.org
主题: alto Digest, Vol 24, Issue 5

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/alto

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send alto mailing list submissions to
	alto <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/alto
or, via email, send a message with subject or body 'help' to
	alto-request <at> ietf.org

You can reach the person managing the list at
	alto-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of alto digest..."

Today's Topics:

   1. WG Action: RECHARTER: Application-Layer Traffic Optimization
      (alto) (IESG Secretary)

----------------------------------------------------------------------

Message: 1
Date: Tue, 12 Oct 2010 10:39:07 -0700 (PDT)
From: IESG Secretary <iesg-secretary <at> ietf.org>
Subject: [alto] WG Action: RECHARTER: Application-Layer Traffic
	Optimization (alto)
To: IETF Announcement list <ietf-announce <at> ietf.org>
Cc: alto <at> ietf.org
Message-ID: <20101012173907.CFEA93A69CC <at> core3.amsl.com>
Content-Type: text/plain; charset="utf-8"

The Application-Layer Traffic Optimization (alto) working group in the
Applications Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Application-Layer Traffic Optimization (alto)
---------------------------------------------
Current Status: Active Working Group

 Chairs:
     Jon Peterson <jon.peterson <at> neustar.biz>
     Vijay Gurbani <vkg <at> bell-labs.com>
     Enrico Marocco <enrico.marocco <at> telecomitalia.it>

 Applications Area Directors:
     Alexey Melnikov <alexey.melnikov <at> isode.com>
     Peter Saint-Andre <stpeter <at> stpeter.im>

 Applications Area Advisor:
     Peter Saint-Andre <stpeter <at> stpeter.im>

 Mailing Lists:
     General Discussion: alto <at> ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/alto
     Archive:           
http://www.ietf.org/mail-archive/web/alto/current/maillist.html

Description of Working Group:

  A significant part of the Internet traffic today is generated by
  peer-to-peer (P2P) applications used for file sharing, real-time
  communications, and live media streaming.  P2P applications exchange
  large amounts of data, often uploading as much as downloading.  In
  contrast to client/server architectures, P2P applications often must
  choose one or more suitable candidates from a selection of peers
  offering the same resource or service.

  One of the advantages of P2P systems comes from redundancy in resource
  availability.  This requires choosing among a list of peers, yet
  applications have at best incomplete information to help the
  selection, e.g., topology of the network.

  Applications can sometimes obtain network information dynamically or
  measure link performance with respect to particular peers, but even
  when this is an option it takes time.  The application cannot always
  start out with an optimal arrangement of peers, thus risking at least
  temporary poor performance and excessive cross-domain traffic.  
  Providing more information for use in peer selection can
  improve P2P performance and lower ISP costs.

  The Working Group will design and specify an Application-Layer Traffic
  Optimization (ALTO) service that will provide applications with
  information to perform better-than-random initial peer selection.
  ALTO services may take different approaches at balancing factors such
  as maximum bandwidth, minimum cross-domain traffic, lowest cost to the
  user, etc.  The WG will consider the needs of BitTorrent, tracker-less
  P2P, and other applications, such as content delivery networks (CDN)
  and mirror selection.

  The WG will focus on the following items:

  - A "problem statement" document providing a description of the
  problem and a common terminology.

  - A requirements document.  This document will list requirements for
  the ALTO service, identifying, for example, types of information P2P
  applications may need for optimizing their choices.

  - A request/response protocol for querying the ALTO service to obtain
  information useful for peer selection, and a format for requests and
  responses.  If the requirements analysis identifies the need to allow
  clients to delegate third-parties to query the ALTO service on their
  behalf, the WG will ensure that the protocol provides a mechanism to
  assert the consent of the delegating client.

  - A specification of core request and response formats and semantics
  to communicate network preferences to applications.  Since ALTO
  services may be run by entities with different levels of knowledge
  about the underlying network, such preferences may have different
  representations.  Initially the WG will consider: IP ranges to prefer
  and to avoid, ranked lists of the peers requested by the client,
  information about topological proximity and approximate geographic
  locations.  Other usages will be considered as charter additions once
  the work for the initial services has been completed.

  - In order to query the ALTO server, clients must first know one or
  more ALTO servers that might provide useful information.  The WG will
  look at service discovery mechanisms that are in use, or defined
  elsewhere (e.g. based on DNS SRV records or DHCP options).  If such
  discovery mechanisms can be reused, the WG will produce a document to
  specify how they may be adopted for locating such servers.  However, a
  new, general-purpose service discovery mechanism is not in scope.

  - An informational document discussing deployment related issues and
  documenting 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?

  - Is it information that a client will find useful?

  - Can a client get that information without excessive privacy concerns
  (e.g. by sending large lists of peers)?

  - 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.  Such issues belong to other IETF areas and will be treated
  accordingly by the specific area.

  This WG will focus solely on the communication protocol between
  applications and ALTO servers.  Note that ALTO services may be useful
  in client-server environments as well as P2P environments, although
  P2P environments are the first focus.  If, in the future, the IETF
  considers changes to other protocols for actually implementing ALTO
  services (e.g. application-layer protocols for Internet coordinate
  systems, routing protocol extensions for ISP-based solutions), such
  work will be done in strict coordination with the appropriate WGs.

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

Goals and Milestones:

  Done     - Working Group Last Call for problem statement
  Done     - Submit problem statement to IESG as Informational
  Jan 2011 - Working Group Last Call for requirements document
  Jan 2011 - Working Group Last Call for request/response protocol
  Mar 2011 - Submit request/response protocol to IESG as Proposed
             Standard
  Mar 2011 - Submit requirements document to IESG as Informational
  May 2011 - Working Group Last Call of deployment considerations
             document
  Aug 2011 - Submit deployment considerations document to IESG as
             Informational
  Nov 2011 - Working Group Last Call of discovery mechanism
  Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard
  Mar 2012 - Dissolve or re-charter

------------------------------

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto

End of alto Digest, Vol 24, Issue 5
***********************************


_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto

Gmane