I also agree to move it forward. One example: ALTO issue is quickly
coming up in the IPTV business. P2P for IPTV service already takes
place in some of standard bodies (e.g., DVB, EBU, etc...). So, it's
a good timing not to missing over the important business changes...
--
Daniel Park [at] Samsung Electronics
Standard Architect, blog.naver.com/natpt
On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes <rbarnes@xxxxxxx>
wrote:
On the contrary, I perceived pretty strong agreement at the BoF that
the ALTO problem, as expressed in the documents and presentations,
as an important one to solve. There was some disagreement about
solutions, but there seemed to be agreement about the general idea
that it would be useful to create an ALTO service that could help
peers optimize their peer selection.
The question of "service" versus "server" in the text is a complete
non-issue, purely a matter of wording. In all of the "ALTO service"
scenarios Vidya describes, there is ultimately a single host that
provides ALTO information, which you might as well call an "ALTO
server".
Since it addresses an important problem, and a problem that many
people agree is important, I support moving forward with this work.
--Richard
Narayanan, Vidya wrote:
I am surprised to see that ALTO is being proposed for a WG after the
last BoF concluded with no consensus whatsoever. I think a second
BoF is more appropriate than a WG on the topic at this time. That
said, I do see the need for this work, although I have some comments
on the current direction.
Overall, I think we should work with the notion of an ALTO "service"
rather than specifically an ALTO "server". The ALTO service may be
provided by a server, a cluster of distributed servers or as a
service in an overlay. Although some of the charter wording talks
about a "service" rather than a "server", there is enough mention of
a "server" entity to imply a strict client-server protocol.
As part of that, I think there are a couple of key things that need
to be addressed here:
- A protocol that allows peers (or ALTO clients) to publish
information about themselves as part of the ALTO service. An
example of such information may be the uplink/downlink bandwidth of
the peer.
- The ability to register information types with IANA and extend
these. The request/response protocol should be a generic enough
container for any information that peers can provide and look for,
plus what may be available from service providers, etc. There may
be some guidelines on how such information types can be registered
and we may start with default ones.
Some further comments/questions inline.
-----Original Message-----
From: ietf-announce-bounces@xxxxxxxx
[mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of IESG Secretary
Sent: Monday, October 06, 2008 1:36 PM
To: IETF Announcement list
Cc: p2pi@xxxxxxxx
Subject: WG Review: Application-Layer Traffic Optimization (alto)
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@xxxxxxxx) 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.
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.
What does the above sentence mean? If we are putting such a list
together, we must also take into account needs from structured P2P
overlays such as those being specified in P2PSIP.
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
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.
Is this meant to allow for entities such as proxies to be in the path?
- 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.
Earlier, it is mentioned that the requirements document will
determine the types of information that are useful for P2P
applications. Given that, it seems premature to conclude that the
WG should consider the above mentioned parameters. Also, as I
mentioned earlier, I think it is essential to keep the protocol and
message formats extensible and allow for exchange of any registered
information type.
Another question I have is about the assumptions around expected
peer addressing models. Some of the above seems to hint at IP
addresses - is this an assumption already?
- 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.
Alternately, the clients may look for ALTO services within an
overlay. This can be modeled as service discovery within the
overlay - I'm, however, not suggesting that we take on solutions for
that.
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 technically provide that information?
- Is the ALTO service willing to obtain and divulge that information?
- Is it information that a client will find useful?
I'm not sure how useful it is for us to answer this question. The
protocol we develop simply needs to be a container for any
information that has a registered type and fits a certain format.
- 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 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.
If we can build an extensible protocol, we don't need to define all
possible kinds of information that get carried in it.
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 servers (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.
I hope we can also look at the above from a generalized service
perspective rather than just a client-server perspective.
Thanks,
Vidya
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 (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
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
p2pi mailing list
p2pi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
p2pi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/p2pi