Re: WG Review: Application-Layer Traffic Optimization (alto)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Review: Application-Layer Traffic Optimization (alto)
I support this moving forward. My reading of the room in Dublin was
that there was serious support
for this and certainly a critical mass to move forward.
Some comments in the charter below. This document clearly needs some
more work. As a overall comment,
I think it is premature to discuss ALTO "servers" and would keep the
charter focused on describing
the ALTO "service." I do not see consensus at this moment as to a
central service solution versus a distributed
solution.
Regards
Marshall
On Oct 6, 2008, at 4:35 PM, IESG Secretary wrote:
A new IETF working group has been proposed in the Applications
Area. The
IESG has not made any determination as yet. The following draft
charter
was submitted, and is provided for informational purposes only.
Please
send your comments to the IESG mailing list (iesg at ietf.org) by Monday,
October 13, 2008.
Application-Layer Traffic Optimization (alto)
=============================================
Last Modified: 2008-09-29
Current Status: Proposed Working Group
Chair(s): TBD
Applications Area Director(s):
Lisa Dusseault (lisa at osafoundation.org)
Chris Newman (Chris.Newman at sun.com)
Applications Area Advisor:
Lisa Dusseault (lisa at osafoundation.org)
Mailing List:
General Discussion: p2pi at ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi
Archive: http://www.ietf.org/pipermail/p2pi/
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 have
a selection of peers and must choose.
s/choose/choose the best peer or peers to exchange data with/
One of the advantages of P2P systems comes from redundancy in resource
availability. This requires choosing among download locations, yet
applications have at best incomplete information about the topology of
the network. Applications can sometimes make empirical measurements
of link performance, but even when this is an option it takes time.
The application cannot always start out with an optimal arrangement of
peers, thus causing at least temporary reduced 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
including 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, what kind of information
P2P applications will 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. The WG does not require intermediaries between the ALTO
This is strange wording, as WG themselves are not protocols.
More fundamentally, is this a requirement ? If so, it seems premature
before a requirements draft is adopted.
Saying "The ALTO server" here also seems limiting - is there a
solution draft describing a server ?
Others have already commented on central servers versus a distributed
system, and to
me the charter is not the place to make such decisions.
I would remove this sentence entirely.
server and the peer querying it. 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 document defining core request and response formats and
semantics to
communicate network preferences to applications. Since ALTO
services may
be run by entities with different level 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
extensions to the charter once the work for the initial services has
been
completed.
- In order to query the ALTO server, clients must first know one or
more
s/server/service/
s/know/find/
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.
When the WG considers standardizing information that the ALTO server
s/server/service/
could provide, the following criteria are important to ensure real
feasibility.
- Can the ALTO service technically provide that information?
I think that what is meant here is "Can the ALTO service realistically
discover that information?"
- Is the ALTO service willing to obtain and divulge that information?
Do computers have free will ?
More seriously, it seems very odd to assume that a P2P service will
not do something that the owners of
the peers want it to do. In my opinion that drives P2P adoption
much more than the efficiencies of bandwidth sharing.
- 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 generality of the data will be
What is meant by "the generality of the data" ?
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
Does this mean that congestion is not an issue to consider ?
If the closest peer to me was totally congested and had no available
bandwidth, isn't that something that
I would want to know ?
will not deal with information representing instantaneous network
state.
What is meant by "information representing instantaneous network
state" ? Isn't
this a protocol to share information about the state of the network ?
Or is this
an attempt to separate network topology from network performance ? But
should network performance
also be an issue ?
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
Not according to the previous paragraphs. Service discovery is not
part of
this communication protocol, Load balancing is not part of this, etc.
I would suggest changing "solely" to "primarily"
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
servers (e.g. application-layer protocols for Internet coordinate
systems,
What is an Internet coordinate system ?
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
s/also//
excluded from the WG's scope, as is the issue dealing with enforcing
s/is the issue/are issues/
the legality of the content.
s/the legality of the content/copyrights/
Goals and Milestones (very tentative dates):
Apr 2009: Working Group Last Call for problem statement
Jun 2009: Submit problem statement to IESG as Informational
Aug 2009: Working Group Last Call for requirements document
Oct 2009: Submit requirements document to IESG as Informational
Jan 2010: Working Group Last Call for request/response protocol
Jan 2010: Working Group Last Call for usage document for
communicating network preferences
Mar 2010: Submit request/response protocol to IESG as Proposed
Standard
Mar 2010: Submit usage document to IESG as Proposed Standard
May 2010: Working Group Last Call of discovery mechanism
Jul 2010: Submit discovery mechanism to IESG as Proposed Standard
Aug 2010: Dissolve or re-charter
Initial Drafts for Consideration
- draft-marocco-alto-problem-statement-02 -- Application-Layer Traffic
Optimization (ALTO) Problem Statement
- draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization
(ALTO) Requirements
Regards
Marshall
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
