Re: [alto] alto Digest, Vol 24, Issue 5
"wangaijun" <wangaijun@tsinghua.org.cn> Wed, 13 October 2010 03:20 UTC
Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF413A6B0B for <alto@core3.amsl.com>; Tue, 12 Oct 2010 20:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_73=0.6, RCVD_BAD_ID=2.837]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9cwKdwTZ+he for <alto@core3.amsl.com>; Tue, 12 Oct 2010 20:20:38 -0700 (PDT)
Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by core3.amsl.com (Postfix) with SMTP id C08E23A68B6 for <alto@ietf.org>; Tue, 12 Oct 2010 20:20:36 -0700 (PDT)
Received: from ctbriwangaj (unknown [219.142.69.35]) by app1 (Coremail) with SMTP id Z0GX06Cr_QATH7VMihYaAA==.7782S2; Wed, 13 Oct 2010 10:53:22 +0800 (CST)
From: wangaijun <wangaijun@tsinghua.org.cn>
To: alto@ietf.org
References: <mailman.47.1286910014.32638.alto@ietf.org>
In-Reply-To: <mailman.47.1286910014.32638.alto@ietf.org>
Date: Wed, 13 Oct 2010 11:21:35 +0800
Message-ID: <004401cb6a85$c6708a90$53519fb0$@org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActqPkWx+OdWBsewTSeCVkjWAQJ6awAPcKTw
Content-Language: zh-cn
X-Coremail-Antispam: 1U3129KBjvJXoW3Aw4rZw4ruw1kKr1fGw1kuFg_yoWkWr4kpF WfKr1fG397Jr1fGw18Zw4IgryrurZ5GF43JrnxKw18A398CFnFgF17tw4FvFyDGryfJryY qr4jvF15Xw48AaDanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQCb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAawVACjsI_Ar4v6c8GOVW06r1DJr WUAwAawVCIc40E5I027xCE548m6r1DJr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13MI8E67AF 67kF1VAFwI0_Jr0_JrDI43ZEXa7VUbJDG5UUUUU==
Subject: Re: [alto] alto Digest, Vol 24, Issue 5
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 03:20:39 -0000
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@ietf.org [mailto:alto-bounces@ietf.org] 代表 alto-request@ietf.org 发送时间: 2010年10月13日 3:00 收件人: alto@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@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@ietf.org You can reach the person managing the list at alto-owner@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@ietf.org> Subject: [alto] WG Action: RECHARTER: Application-Layer Traffic Optimization (alto) To: IETF Announcement list <ietf-announce@ietf.org> Cc: alto@ietf.org Message-ID: <20101012173907.CFEA93A69CC@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@neustar.biz> Vijay Gurbani <vkg@bell-labs.com> Enrico Marocco <enrico.marocco@telecomitalia.it> Applications Area Directors: Alexey Melnikov <alexey.melnikov@isode.com> Peter Saint-Andre <stpeter@stpeter.im> Applications Area Advisor: Peter Saint-Andre <stpeter@stpeter.im> Mailing Lists: General Discussion: alto@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@ietf.org https://www.ietf.org/mailman/listinfo/alto End of alto Digest, Vol 24, Issue 5 ***********************************
- Re: [alto] alto Digest, Vol 24, Issue 5 wangaijun
- Re: [alto] alto Digest, Vol 24, Issue 5 Enrico Marocco