From Fabio.Picconi@technicolor.com Mon Mar 1 08:11:39 2010 Return-Path: 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 BAF3328C102 for ; Mon, 1 Mar 2010 08:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 betxj6iTLeFG for ; Mon, 1 Mar 2010 08:11:38 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with ESMTP id CF74F28C0F3 for ; Mon, 1 Mar 2010 08:11:37 -0800 (PST) Received: from source ([141.11.137.61]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKS4vnObjPhp3Uxh6lG4VJC58vRm3v0dJt@postini.com; Mon, 01 Mar 2010 08:11:38 PST Received: from smtpio2.eu.thmulti.com (unknown [10.14.0.12]) by mail3.thomson.net (Postfix) with ESMTP id 662D52E92 for ; Mon, 1 Mar 2010 16:11:36 +0000 (GMT) Received: from CHSKSMAILBH01.eu.thmulti.com (chsksmailbh01.eu.thmulti.com [10.11.225.30]) by smtpio2.eu.thmulti.com (Postfix) with ESMTP id 3613F1247 for ; Mon, 1 Mar 2010 16:11:36 +0000 (GMT) Received: from MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) by CHSKSMAILBH01.eu.thmulti.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 16:11:35 +0000 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC01.eu.thmulti.com ([10.6.151.123]) with mapi; Mon, 1 Mar 2010 17:11:35 +0100 From: Picconi Fabio To: "alto@ietf.org" Date: Mon, 1 Mar 2010 17:11:34 +0100 Thread-Topic: new draft draft-picconi-alto-p2p-streaming-00 Thread-Index: Acq5Wd00g3hSFSnoSQSz2WDTi+aW3w== Message-ID: <320C4182454E96478DC039F2C48198720213183924@MOPESMBX01.eu.thmulti.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C48198720213183924MOPESMBX01eut_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2010 16:11:35.0382 (UTC) FILETIME=[DD8E9F60:01CAB959] Subject: [alto] new draft draft-picconi-alto-p2p-streaming-00 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:11:39 -0000 --_000_320C4182454E96478DC039F2C48198720213183924MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new draft on ISP-friendly peer-to-peer live streaming. You can find it at the following URL: http://tools.ietf.org/html/draft-picc= oni-alto-p2p-streaming-00 Comments welcome! Best, Fabio Picconi --_000_320C4182454E96478DC039F2C48198720213183924MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have submitted a new draft on ISP-friendly peer-to-= peer live streaming.

 

You can find it at the following URL: htt= p://tools.ietf.org/html/draft-picconi-alto-p2p-streaming-00<= /p>

 

Comments welcome!

 

Best,

 

Fabio Picconi

--_000_320C4182454E96478DC039F2C48198720213183924MOPESMBX01eut_-- From trac@tools.ietf.org Thu Mar 4 11:44:58 2010 Return-Path: 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 1F95E3A8E3C for ; Thu, 4 Mar 2010 11:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 douDyMPY0fI0 for ; Thu, 4 Mar 2010 11:44:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7C7443A8D69 for ; Thu, 4 Mar 2010 11:44:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnGyh-0000aV-Sx; Thu, 04 Mar 2010 11:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 19:44:59 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/1#comment:1 Message-ID: <079.b5f435289c6b4482c9a48210d612bf2c@tools.ietf.org> References: <070.965222bf44169db264bbca911efb8573@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <070.965222bf44169db264bbca911efb8573@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:44:58 -0000 #1: Message format ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: new Priority: blocker | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Comment(by richard.alimi@…): draft-ietf-alto-protocol-02 now includes a more complete protocol specification. The current encoding specification provides example requests and responses, as well as documenting the syntax and enumerating the components of the messages. The current encoding specification is not as formal and compact as it probably could be, so work is needed in this area. One possibility for a more compact representation is a C-style syntax where JSON objects are formally documented as C-style structs. -- Ticket URL: alto From root@core3.amsl.com Thu Mar 4 11:45:01 2010 Return-Path: X-Original-To: alto@ietf.org Delivered-To: alto@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9E1FA28C0DE; Thu, 4 Mar 2010 11:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100304194501.9E1FA28C0DE@core3.amsl.com> Date: Thu, 4 Mar 2010 11:45:01 -0800 (PST) Cc: alto@ietf.org Subject: [alto] I-D Action:draft-ietf-alto-protocol-02.txt X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF. Title : ALTO Protocol Author(s) : R. Alimi, et al. Filename : draft-ietf-alto-protocol-02.txt Pages : 51 Date : 2010-03-04 Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-alto-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-04113028.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Thu Mar 4 11:53:19 2010 Return-Path: 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 870413A8E4B for ; Thu, 4 Mar 2010 11:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 OKPW2zOmMy+A for ; Thu, 4 Mar 2010 11:53:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D5D013A8E49 for ; Thu, 4 Mar 2010 11:53:18 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnH6n-0005nW-9P; Thu, 04 Mar 2010 11:53:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 19:53:21 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/2#comment:1 Message-ID: <079.b340dd45cd903963493640718e8f4734@tools.ietf.org> References: <070.422795dc42b5a4378222f8f004988620@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.422795dc42b5a4378222f8f004988620@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #2: Protocol details: version number X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:53:19 -0000 #2: Protocol details: version number ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Comment(by richard.alimi@…): draft-ietf-alto-protocol-02 now includes protocol versioning. The current approach to versioning assumes that a distinct host handles a single protocol version. (Virtual hosting can be used to allow a single physical server to handle multiple protocol versions.) Protocol version numbers are echoed in the responses to allow responses to be redistributed to other hosts. The Server Capability allows an ALTO Client to discover ALTO Servers providing other protocol versions. Feedback on this approach is welcomed. -- Ticket URL: alto From trac@tools.ietf.org Thu Mar 4 11:54:20 2010 Return-Path: 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 7DF713A8E4D for ; Thu, 4 Mar 2010 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 sRNBrqQXvhCI for ; Thu, 4 Mar 2010 11:54:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF3B03A8E4B for ; Thu, 4 Mar 2010 11:54:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnH7m-0005qi-8C; Thu, 04 Mar 2010 11:54:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 19:54:22 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/3#comment:1 Message-ID: <079.f888adf788e8ac9ea52f48f7cca48730@tools.ietf.org> References: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #3: Protocol details: map version tags X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:54:20 -0000 #3: Protocol details: map version tags ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Comment(by richard.alimi@…): draft-ietf-alto-protocol-02 now includes map version tags in responses including Network Maps and Cost Maps. -- Ticket URL: alto From trac@tools.ietf.org Thu Mar 4 12:11:55 2010 Return-Path: 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 5750D3A8E51 for ; Thu, 4 Mar 2010 12:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 K3ygrI6ek50u for ; Thu, 4 Mar 2010 12:11:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 29DD93A8C09 for ; Thu, 4 Mar 2010 12:11:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnHOm-0000ev-IG; Thu, 04 Mar 2010 12:11:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 20:11:56 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/5 Message-ID: <061.442486a10bb7ab638f1e02acd104d450@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #5: Cost Map / Network Map terminology X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:11:55 -0000 #5: Cost Map / Network Map terminology ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: richard.alimi@… Type: enhancement | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- draft-ietf-alto-protocol-02 does not make a clear distinction between the data structure stored by the ALTO Server (comparable to a Table in database terminology) and the information returned by the queries (comparable to a View in database terminology). One way to make the terminology more specific is to rework the terminology to refer to the raw information base as something like "Map Information Base", and the responses from the ALTO Server (which may or may not have certain selection criteria used in generating the response) as Network Map Views or Cost Map Views. -- Ticket URL: alto From trac@tools.ietf.org Thu Mar 4 12:16:29 2010 Return-Path: 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 C50B728C0FC for ; Thu, 4 Mar 2010 12:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 lBin99MqyPCc for ; Thu, 4 Mar 2010 12:16:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EACA728C0FB for ; Thu, 4 Mar 2010 12:16:28 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnHTC-00046c-Kc; Thu, 04 Mar 2010 12:16:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 20:16:30 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/6 Message-ID: <061.2ba598d2b12598796ed7780f51ebed82@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #6: Feedback on Redistribution and Signatures X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:16:29 -0000 #6: Feedback on Redistribution and Signatures ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Pursuant to discussion at IETF76, since it appeard to be well-received, we have included the necessary components in draft-ietf-alto-protocol-02 to allow for ALTO Information Redistribution. The signature information is currently carried in HTTP headers (or trailers if desired for dynamically- generated responses) which use the "X-ALTO-..." pattern, which may be seen by some as "messy". Other suggestions here, or feedback about redistribution in general, is welcome. -- Ticket URL: alto From trac@tools.ietf.org Thu Mar 4 12:20:17 2010 Return-Path: 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 DA1D128C0EA for ; Thu, 4 Mar 2010 12:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 SN5e64sYzWzJ for ; Thu, 4 Mar 2010 12:20:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4AFC328C0E3 for ; Thu, 4 Mar 2010 12:20:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnHWn-0004mc-HK; Thu, 04 Mar 2010 12:20:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 20:20:13 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/7 Message-ID: <061.e728b04bba6c1e593cfa8159cabea9bc@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #7: Fix IP addresses in protocol examples X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:20:18 -0000 #7: Fix IP addresses in protocol examples ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Message examples must be converted to use proper IP addresses from RFC3330. -- Ticket URL: alto From trac@tools.ietf.org Thu Mar 4 12:24:16 2010 Return-Path: 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 1CABA3A8D51 for ; Thu, 4 Mar 2010 12:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Trlgu2iatyJy for ; Thu, 4 Mar 2010 12:24:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 410A13A8C7E for ; Thu, 4 Mar 2010 12:24:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnHai-0003z9-Pd; Thu, 04 Mar 2010 12:24:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: rpenno@juniper.net, richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 04 Mar 2010 20:24:16 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/8 Message-ID: <061.72c601df0d87a89bf3339391ce30cc69@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rpenno@juniper.net, richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #8: Add example ALTO Server configuration to guide protocol examples X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:24:16 -0000 #8: Add example ALTO Server configuration to guide protocol examples ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: rpenno@… Type: enhancement | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Current protocol examples are each relatively isolated. The protocol examples should be drawn from a common configuration which is documented/presented before introducing the protocol messages themselves. This configuration should be inserted into the document as an illustration/diagram and accompanying text, and the examples should be converted to match it. -- Ticket URL: alto From richard.alimi@gmail.com Thu Mar 4 12:32:51 2010 Return-Path: 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 982913A8DF2 for ; Thu, 4 Mar 2010 12:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 50EpBe7vO8hr for ; Thu, 4 Mar 2010 12:32:50 -0800 (PST) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 66E163A8DE7 for ; Thu, 4 Mar 2010 12:32:50 -0800 (PST) Received: by fxm27 with SMTP id 27so3236549fxm.28 for ; Thu, 04 Mar 2010 12:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=wtrmcjvFFc0+KAK4Vuf5KUbeFPMRNgA1uUTAE2+Edos=; b=TK4MKsEUjbv5qBirmcqgPYtqmQd5a7G5bBDbG/SOsKKlrI8NxwqOwRBrcoalFcU7zX RTXku8CWAIq+oFrvdfMcAsIhwJcReHiwf8WzecNJ5pZiJBBDCnehmGNkfpIKFiRioP1U tMXNOroQ/3PWJJzSgMS0HdTSel+0iMlluy8dE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=AJwVfs9rbjNJti3tmFj/OW0CgUvwJzgHbyGIT9Vj3lP+HMhVOANyjQyolwrjzEwhns 6oxdd43e9J4FJaGOwQDyqdNTV/oJzuyRBLW1buaIcJiWPdI1heS6kURB3rHmyhiVsxgq JjaNvFjp+Ax2S8+YdqHFYKjiS4JYm/PprMl/E= Received: by 10.87.66.14 with SMTP id t14mr311672fgk.60.1267734768960; Thu, 04 Mar 2010 12:32:48 -0800 (PST) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id e20sm1726953fga.25.2010.03.04.12.32.47 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Mar 2010 12:32:48 -0800 (PST) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 4 Mar 2010 15:32:45 -0500 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: <20100304194501.9E1FA28C0DE@core3.amsl.com> In-Reply-To: <20100304194501.9E1FA28C0DE@core3.amsl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003041532.45843.richard.alimi@yale.edu> Subject: Re: [alto] I-D Action:draft-ietf-alto-protocol-02.txt X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:32:51 -0000 Hi All, We have posted a new version of the ALTO Protocol draft: http://tools.ietf.org/html/draft-ietf-alto-protocol-02 The draft features heavily-reworked protocol sections (Section 6 and 7). There are also many additions to the Security Considerations section (Section 11) thanks to Jan Seedorf. There are a number of items about the draft that we've picked out as needing feedback and revisions and added these to the issue tracker: http://trac.tools.ietf.org/wg/alto/trac/report/1 Of course, please bring up other items as you see them or think about them. It would be great to get a good round of discussion and feedback on any major issues before Monday, so that we can make appropriate changes prior to March 8th and submit another revision. Thanks! -- Richard Alimi Department of Computer Science Yale University On Thursday 04 March 2010 2:45:01 pm Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Application-Layer Traffic > Optimization Working Group of the IETF. > > > Title : ALTO Protocol > Author(s) : R. Alimi, et al. > Filename : draft-ietf-alto-protocol-02.txt > Pages : 51 > Date : 2010-03-04 > > Networking applications today already have access to a great amount > of Inter-Provider network topology information. For example, views > of the Internet routing table are easily available at looking glass > servers and entirely practical to be downloaded by clients. What is > missing is knowledge of the underlying network topology from the ISP > or Content Provider (henceforth referred as Provider) point of view. > In other words, what a Provider prefers in terms of traffic > optimization -- and a way to distribute it. > > The ALTO Service provides information such as preferences of network > resources with the goal of modifying network resource consumption > patterns while maintaining or improving application performance. > This document describes a protocol implementing the ALTO Service. > While such service would primarily be provided by the network (i.e., > the ISP), content providers and third parties could also operate this > service. Applications that could use this service are those that > have a choice in connection endpoints. Examples of such applications > are peer-to-peer (P2P) and content delivery networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From tariqsaraj@gmail.com Thu Mar 4 22:31:46 2010 Return-Path: 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 668413A8EE0 for ; Thu, 4 Mar 2010 22:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] 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 qkzkbTdAUu-p for ; Thu, 4 Mar 2010 22:31:45 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id A513E3A8ED5 for ; Thu, 4 Mar 2010 22:31:44 -0800 (PST) Received: by yxe4 with SMTP id 4so1670161yxe.27 for ; Thu, 04 Mar 2010 22:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=7vs4Sqlzz/fvc1vmNbYRLg6cKZZdLV9y1bgqcK3/LiQ=; b=fwRCczzSdXI0+v14xzO/6/OUtFbJU7r2fW2lijJOodd7bk4DSBKm4BZOjfpKl4DR5R weDwyFysjAGFVwg0jhAc6TDyjzL/ApQcMmbz2g2oORwc51EqHEtRu+MA+unZFmvCGvar Xtg0wkFQK0UkQcKil8OUxIANanMYFMcPczhw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DdmbeeKWqAW0IONYbLddHJMTjQVIOes8qc8iAzXHEYbA82gduakc1E/CEVm2W81Jos t9sw71A6YEf3BjyRYHbBVzYLIEzHRzUtQOV/DCvOY6Zi2/vm0y1+nMSHNqg3Urf/VweU B9ZEX/Ir/YpV1orNRxNftYdL719oDO4tc1R0I= MIME-Version: 1.0 Received: by 10.100.235.24 with SMTP id i24mr1351439anh.155.1267770703545; Thu, 04 Mar 2010 22:31:43 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Mar 2010 11:31:43 +0500 Message-ID: <86153d911003042231w12a6986cp422d03860c085190@mail.gmail.com> From: Tariq Saraj To: alto@ietf.org Content-Type: multipart/alternative; boundary=001636b2b05c7107f4048107dea3 Subject: Re: [alto] alto Digest, Vol 17, Issue 2 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 06:31:46 -0000 --001636b2b05c7107f4048107dea3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 5, 2010 at 1:00 AM, wrote: > 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. Re: #1: Message format (alto issue tracker) > 2. I-D Action:draft-ietf-alto-protocol-02.txt > (Internet-Drafts@ietf.org) > 3. Re: #2: Protocol details: version number (alto issue tracker) > 4. Re: #3: Protocol details: map version tags (alto issue tracker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 04 Mar 2010 19:44:59 -0000 > From: "alto issue tracker" > Subject: Re: [alto] #1: Message format > To: richard.alimi@yale.edu > Cc: alto@ietf.org > Message-ID: <079.b5f435289c6b4482c9a48210d612bf2c@tools.ietf.org> > Content-Type: text/plain; charset="utf-8" > > #1: Message format > > ---------------------------------------------+------------------------------ > Reporter: enrico.marocco@? | Owner: > richard.alimi@? > Type: enhancement | Status: new > Priority: blocker | Milestone: > Component: protocol | Version: > Severity: Active WG Document | Keywords: > > ---------------------------------------------+------------------------------ > > Comment(by richard.alimi@?): > > draft-ietf-alto-protocol-02 now includes a more complete protocol > specification. The current encoding specification provides example > requests and responses, as well as documenting the syntax and enumerating > the components of the messages. > > The current encoding specification is not as formal and compact as it > probably could be, so work is needed in this area. One possibility for a > more compact representation is a C-style syntax where JSON objects are > formally documented as C-style structs. > > -- > Ticket URL: > alto > > > > ------------------------------ > > Message: 2 > Date: Thu, 4 Mar 2010 11:45:01 -0800 (PST) > From: Internet-Drafts@ietf.org > Subject: [alto] I-D Action:draft-ietf-alto-protocol-02.txt > To: i-d-announce@ietf.org > Cc: alto@ietf.org > Message-ID: <20100304194501.9E1FA28C0DE@core3.amsl.com> > Content-Type: text/plain; charset="us-ascii" > > > > ------------------------------ > > Message: 3 > Date: Thu, 04 Mar 2010 19:53:21 -0000 > From: "alto issue tracker" > Subject: Re: [alto] #2: Protocol details: version number > To: richard.alimi@yale.edu > Cc: alto@ietf.org > Message-ID: <079.b340dd45cd903963493640718e8f4734@tools.ietf.org> > Content-Type: text/plain; charset="utf-8" > > #2: Protocol details: version number > > ---------------------------------------------+------------------------------ > Reporter: enrico.marocco@? | Owner: > richard.alimi@? > Type: enhancement | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: Active WG Document | Keywords: > > ---------------------------------------------+------------------------------ > > Comment(by richard.alimi@?): > > draft-ietf-alto-protocol-02 now includes protocol versioning. The current > approach to versioning assumes that a distinct host handles a single > protocol version. (Virtual hosting can be used to allow a single physical > server to handle multiple protocol versions.) Protocol version numbers are > echoed in the responses to allow responses to be redistributed to other > hosts. The Server Capability allows an ALTO Client to discover ALTO > Servers providing other protocol versions. Feedback on this approach is > welcomed. > > -- > Ticket URL: > alto > > > > ------------------------------ > > Message: 4 > Date: Thu, 04 Mar 2010 19:54:22 -0000 > From: "alto issue tracker" > Subject: Re: [alto] #3: Protocol details: map version tags > To: richard.alimi@yale.edu > Cc: alto@ietf.org > Message-ID: <079.f888adf788e8ac9ea52f48f7cca48730@tools.ietf.org> > Content-Type: text/plain; charset="utf-8" > > #3: Protocol details: map version tags > > ---------------------------------------------+------------------------------ > Reporter: enrico.marocco@? | Owner: > richard.alimi@? > Type: enhancement | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: Active WG Document | Keywords: > > ---------------------------------------------+------------------------------ > > Comment(by richard.alimi@?): > > draft-ietf-alto-protocol-02 now includes map version tags in responses > including Network Maps and Cost Maps. > > -- > Ticket URL: > alto > > > > ------------------------------ > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > > > End of alto Digest, Vol 17, Issue 2 > *********************************** > --001636b2b05c7107f4048107dea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 5, 2010 at 1:00 AM, <alto-request@ietf.o= rg> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/alto

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



Send alto mailing list submissions to
=A0 =A0 =A0 =A0alto@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/alto
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0alto-request@ietf.= org

You can reach the person managing the list at
=A0 =A0 =A0 =A0alto-owner@ietf.org<= /a>

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


Today's Topics:

=A0 1. Re: #1: Message format (alto issue tracker)
=A0 2. I-D Action:draft-ietf-alto-protocol-02.txt
=A0 =A0 =A0(Internet-Drafts@ie= tf.org)
=A0 3. Re: #2: Protocol details: version number (alto issue tracker)
=A0 4. Re: #3: Protocol details: map version tags (alto issue tracker)


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

Message: 1
Date: Thu, 04 Mar 2010 19:44:59 -0000
From: "alto issue tracker" <trac@tools.ietf.org>
Subject: Re: [alto] #1: Message format
To: richard.alimi@yale.edu Cc: alto@ietf.org
Message-ID: <079.b5f435289c6b4482c9a48210d612bf2c@tools.ietf.org>
Content-Type: text/plain; charset=3D"utf-8"

#1: Message format
---------------------------------------------+-----------------------------= -
=A0Reporter: =A0enrico.marocco@? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner: =A0richard.alimi@?
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0Status: =A0new
=A0Priority: =A0blocker =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 Milestone:
Component: =A0protocol =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Key= words:
---------------------------------------------+-----------------------------= -

Comment(by richard.alimi@?):

=A0draft-ietf-alto-protocol-02 now includes a more complete protocol
=A0specification. =A0The current encoding specification provides example =A0requests and responses, as well as documenting the syntax and enumeratin= g
=A0the components of the messages.

=A0The current encoding specification is not as formal and compact as it =A0probably could be, so work is needed in this area. One possibility for a=
=A0more compact representation is a C-style syntax where JSON objects are =A0formally documented as C-style structs.

--
Ticket URL: <http://trac.tools.ietf.org/wg/alto/trac/ticke= t/1#comment:1>
alto <http://t= ools.ietf.org/alto/>



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

Message: 2
Date: Thu, =A04 Mar 2010 11:45:01 -0800 (PST)
From: Internet-Drafts@ietf.org<= /a>
Subject: [alto] I-D Action:draft-ietf-alto-protocol-02.txt
To: i-d-announce@ietf.org
Cc: alto@ietf.org
Message-ID: <20100304194501.9E1FA28C0DE@core3.amsl.com>
Content-Type: text/plain; charset=3D"us-ascii"



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

Message: 3
Date: Thu, 04 Mar 2010 19:53:21 -0000
From: "alto issue tracker" <trac@tools.ietf.org>
Subject: Re: [alto] #2: Protocol details: version number
To: richard.alimi@yale.edu Cc: alto@ietf.org
Message-ID: <079.b340dd45cd903963493640718e8f4734@tools.ietf.org>
Content-Type: text/plain; charset=3D"utf-8"

#2: Protocol details: version number
---------------------------------------------+-----------------------------= -
=A0Reporter: =A0enrico.marocco@? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner: =A0richard.alimi@?
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 Milestone:
Component: =A0protocol =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Key= words:
---------------------------------------------+-----------------------------= -

Comment(by richard.alimi@?):

=A0draft-ietf-alto-protocol-02 now includes protocol versioning. The curren= t
=A0approach to versioning assumes that a distinct host handles a single
=A0protocol version. (Virtual hosting can be used to allow a single physica= l
=A0server to handle multiple protocol versions.) Protocol version numbers a= re
=A0echoed in the responses to allow responses to be redistributed to other<= br> =A0hosts. =A0The Server Capability allows an ALTO Client to discover ALTO =A0Servers providing other protocol versions. =A0Feedback on this approach = is
=A0welcomed.

--
Ticket URL: <http://trac.tools.ietf.org/wg/alto/trac/ticke= t/2#comment:1>
alto <http://t= ools.ietf.org/alto/>



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

Message: 4
Date: Thu, 04 Mar 2010 19:54:22 -0000
From: "alto issue tracker" <trac@tools.ietf.org>
Subject: Re: [alto] #3: Protocol details: map version tags
To: richard.alimi@yale.edu Cc: alto@ietf.org
Message-ID: <079.f888adf788e8ac9ea52f48f7cca48730@tools.ietf.org>
Content-Type: text/plain; charset=3D"utf-8"

#3: Protocol details: map version tags
---------------------------------------------+-----------------------------= -
=A0Reporter: =A0enrico.marocco@? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner: =A0richard.alimi@?
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 Milestone:
Component: =A0protocol =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Key= words:
---------------------------------------------+-----------------------------= -

Comment(by richard.alimi@?):

=A0draft-ietf-alto-protocol-02 now includes map version tags in responses =A0including Network Maps and Cost Maps.

--
Ticket URL: <http://trac.tools.ietf.org/wg/alto/trac/ticke= t/3#comment:1>
alto <http://t= ools.ietf.org/alto/>



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

_______________________________________________
alto mailing list
alto@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/alto


End of alto Digest, Vol 17, Issue 2
***********************************

--001636b2b05c7107f4048107dea3-- From sun_xianghui@189.cn Thu Mar 4 23:51:32 2010 Return-Path: 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 DAD443A8F20 for ; Thu, 4 Mar 2010 23:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] 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 BuhNT4dg98KP for ; Thu, 4 Mar 2010 23:51:32 -0800 (PST) Received: from 189.cn (mta.189.cn [121.14.53.137]) by core3.amsl.com (Postfix) with ESMTP id B89FD3A8F1E for ; Thu, 4 Mar 2010 23:51:31 -0800 (PST) Received: from yt-as3-web (as3.inner-189.cn [10.62.8.13]) by 189.cn (HERMES) with ESMTP id CDBD01B8420 for ; Fri, 5 Mar 2010 15:51:30 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.62.8.13.872093830 HMM_SOURCE_TYPE: WEBMAIL Received: from yt-webmail5([10.62.4.15]) by yt-as3-web(Knowledge-based Antispam Gateway 2.127s39l(2009-10-29)) with ESMTP id mx15934.1267775490 for ; Fri, 05 Mar 2010 15:51:30 +0800 (CST) X-Original-MailFrom: sun_xianghui@189.cn Message-ID: <15132471.62841267775490907.JavaMail.hermes@yt-webmail5> Date: Fri, 5 Mar 2010 15:51:30 +0800 (CST) From: sun_xianghui@189.cn To: alto@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6261_6781381.1267775490897" HMM_WEBCLN_IP: 219.142.69.34 X-Priority: 3 X-Mailman-Approved-At: Sat, 06 Mar 2010 04:20:57 -0800 Subject: [alto] new draft: draft-sun-alto-notification-00 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 07:53:09 -0000 ------=_Part_6261_6781381.1267775490897 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi, all

 

We have submitted a new draft on server notification mechanism.

 

You can find it at the following URL: http://tools.ietf.org/html/draft-sun-alto-notification-00

 

Any comments are appreciated!

 

BRs,

 

Sun xianghui

 ------=_Part_6261_6781381.1267775490897-- From guyingjie@huawei.com Sun Mar 7 19:53:07 2010 Return-Path: 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 0720F3A68B0 for ; Sun, 7 Mar 2010 19:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 pMwjVjma8dIb for ; Sun, 7 Mar 2010 19:53:06 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F2F593A68B3 for ; Sun, 7 Mar 2010 19:53:05 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYY00AUU2SALP@szxga04-in.huawei.com> for alto@ietf.org; Mon, 08 Mar 2010 11:52:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYY0008S2SAGZ@szxga04-in.huawei.com> for alto@ietf.org; Mon, 08 Mar 2010 11:52:58 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYY004P82S943@szxml06-in.huawei.com> for alto@ietf.org; Mon, 08 Mar 2010 11:52:58 +0800 (CST) Date: Mon, 08 Mar 2010 11:52:57 +0800 From: "Y.J. Gu" In-reply-to: <4B87D18D.2010201@telecomitalia.it> To: 'Enrico Marocco' , alto@ietf.org Message-id: <008301cabe72$d75cc1d0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acq26qDOT6JK2y+MTk2MQYEGh5E78QHh+hYQ Subject: Re: [alto] Agenda requests for IETF77 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 03:53:07 -0000 Hi Enrico, Shall I request to put [draft-gu-alto-redistribution] into agenda? Thanks Yingjie Gu > -----Original Message----- > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On > Behalf Of Enrico Marocco > Sent: Friday, February 26, 2010 9:50 PM > To: alto@ietf.org > Subject: [alto] Agenda requests for IETF77 > > Usual reminder, folks: > > Deadlines for Anaheim are approaching. Cutoff dates for I-D > submissions are March 1 (for -00 drafts) and March 8; an > initial agenda for the ALTO session is expected by March 10, > so if you wish to have a slot please send us a request no > later than March 9. > > -- > Ciao, > Enrico > From trac@tools.ietf.org Mon Mar 8 07:52:00 2010 Return-Path: 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 1BE0D3A6A16 for ; Mon, 8 Mar 2010 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 M-lQdrilPwjP for ; Mon, 8 Mar 2010 07:51:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4A62C3A6A0C for ; Mon, 8 Mar 2010 07:51:59 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NofFT-00030M-3O; Mon, 08 Mar 2010 07:52:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Mon, 08 Mar 2010 15:52:03 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/alto/trac/ticket/9 Message-ID: <061.f6e2f3c8cb93d7a06d6851c90ee10564@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #9: Semantics and handling for IPv4 and IPv6 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:52:00 -0000 #9: Semantics and handling for IPv4 and IPv6 ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- The current protocol draft (draft-ietf-protocol-02) deals only with IPv4. Adjustments need to be made to include at least IPv6 host group descriptors and along with IPv6 addresses in cost map queries/responses. Some initial TODO items related to IPv6 are: (1) Need notation for distinguishing IPv4 and IPv6 identifiers (perhaps extensible to others types of identifiers in the future?) (2) Semantics for ALTO information containing both IPv4 and IPv6 information. One simple possibility is to forbid mixing identifiers of different types (e.g., ALTO client requests IPv4 map or IPv6 map, but never both). (3) Handling for dual-stack hosts. In particular, Steven Wright raised a number of good questions in this post: http://www.ietf.org/mail- archive/web/alto/current/msg00428.html. His question regarding indicating preference between IPv4/IPv6 relates to (2) above. Please add other discussion items related to IPv4/IPv6 here. -- Ticket URL: alto From root@core3.amsl.com Mon Mar 8 08:30:08 2010 Return-Path: X-Original-To: alto@ietf.org Delivered-To: alto@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CEE583A6A33; Mon, 8 Mar 2010 08:30:06 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308163007.CEE583A6A33@core3.amsl.com> Date: Mon, 8 Mar 2010 08:30:07 -0800 (PST) Cc: alto@ietf.org Subject: [alto] I-D Action:draft-ietf-alto-reqs-04.txt X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF. Title : Application-Layer Traffic Optimization (ALTO) Requirements Author(s) : S. Kiesel, et al. Filename : draft-ietf-alto-reqs-04.txt Pages : 27 Date : 2010-03-08 Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations, and it solicits feedback and discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-alto-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-alto-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08082400.I-D@ietf.org> --NextPart-- From sebi@smtp.ehlo.wurstkaes.de Mon Mar 8 09:17:34 2010 Return-Path: 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 B8C5B3A6A5E for ; Mon, 8 Mar 2010 09:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 uweOWhg6H53z for ; Mon, 8 Mar 2010 09:17:34 -0800 (PST) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id A2BC43A69D3 for ; Mon, 8 Mar 2010 09:17:33 -0800 (PST) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1Noga9-0004If-2r; Mon, 08 Mar 2010 18:17:29 +0100 Date: Mon, 8 Mar 2010 18:17:29 +0100 From: Sebastian Kiesel To: Enrico Marocco Message-ID: <20100308171729.GJ4437@nat01e.ehlo.wurstkaes.de> References: <4B87D18D.2010201@telecomitalia.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B87D18D.2010201@telecomitalia.it> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "alto@ietf.org" Subject: Re: [alto] Agenda requests for IETF77 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:17:34 -0000 Dear ALTO chairs, Title: Third-party ALTO server discovery Draft: draft-kiesel-alto-3pdisc-02 Req. duration: 15 minutes Presenter: Michael Scharf thanks, Michael and Sebastian On Fri, Feb 26, 2010 at 02:50:05PM +0100, Enrico Marocco wrote: > Usual reminder, folks: > > Deadlines for Anaheim are approaching. Cutoff dates for I-D submissions > are March 1 (for -00 drafts) and March 8; an initial agenda for the ALTO > session is expected by March 10, so if you wish to have a slot please > send us a request no later than March 9. > > -- > Ciao, > Enrico From richard.alimi@gmail.com Mon Mar 8 16:56:08 2010 Return-Path: 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 8992C3A677E for ; Mon, 8 Mar 2010 16:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 NSxAkzs7xyTZ for ; Mon, 8 Mar 2010 16:56:07 -0800 (PST) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id AE0323A6BCB for ; Mon, 8 Mar 2010 16:56:07 -0800 (PST) Received: by iwn10 with SMTP id 10so178175iwn.31 for ; Mon, 08 Mar 2010 16:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nn007p4Qii77WF17t1f+62Obfx21ZWvJz1EcnhUS6bY=; b=jJh23HMCrCLghCJN6kkBNbx9psbp+KznLwApjBbi7R6uTUWX5bPVffERClyMneL2el 96vgWaQxt82UV5ILW9TMIRjrA4aKycBXw6qleulJwazByl6sAu7bbqOaUQzXH75wm4em /SbI9BG/EcZCGBozQXqdSyf3gF6sNPKx3AZs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=FHOuQk3FaWIZcQK6XpD70h7qA7YtjbLd+lpRogFjY2ra06/m48qMvR5RzlZ2B43wDK nSJaYY22JHary2hH8B1jftiW0MwW+S3KybaZfjD44oaFolPkVsVxeUNmjzgf2QyCI12v 9OcABRt1wYVFtNfaOk8plRMme2wm9ce65vyc4= MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.146.2 with SMTP id f2mr345179ibv.23.1268096167454; Mon, 08 Mar 2010 16:56:07 -0800 (PST) In-Reply-To: <20100309004757.3F5EB3A6C3E@core3.amsl.com> References: <20100309004757.3F5EB3A6C3E@core3.amsl.com> Date: Mon, 8 Mar 2010 19:56:07 -0500 X-Google-Sender-Auth: f62a8b47576d4d67 Message-ID: From: Richard Alimi To: alto@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [alto] Fwd: New Version Notification for draft-ietf-alto-protocol-03 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:56:08 -0000 FYI, we have submitted an updated copy of the ALTO Protocol draft. In this version, we have adjusted IP addresses used in examples to be proper TEST-NET addresses. We have also adjusted the notation used to specify structure of protocol messages (i.e., JSON objects) to use a more C-like struct syntax that should be both more concise and precise. Of course, feedback and comments are welcome. Please also see some open issues for which we would particularly like feedback: http://tools.ietf.org/wg/alto/trac/report/1 Thanks! Rich ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Mar 8, 2010 at 7:47 PM Subject: New Version Notification for draft-ietf-alto-protocol-03 To: richard.alimi@yale.edu Cc: rpenno@juniper.net, yry@cs.yale.edu A new version of I-D, draft-ietf-alto-protocol-03.txt has been successfuly submitted by Richard Alimi and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-alto-protocol Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 ALTO Protocol Creation_date: =A0 2010-03-08 WG ID: =A0 =A0 =A0 =A0 =A0 alto Number_of_pages: 52 Abstract: Networking applications today already have access to a great amount of Inter-Provider network topology information. =A0For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. =A0What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. =A0Applications that could use this service are those that have a choice in connection endpoints. =A0Examples of such applications are peer-to-peer (P2P) and content delivery networks. The IETF Secretariat. From trac@tools.ietf.org Mon Mar 8 16:57:51 2010 Return-Path: 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 D301E3A6A66 for ; Mon, 8 Mar 2010 16:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 wAdUmytWNUgt for ; Mon, 8 Mar 2010 16:57:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2CA683A677E for ; Mon, 8 Mar 2010 16:57:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nonli-0001Fo-AC; Mon, 08 Mar 2010 16:57:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 00:57:54 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/1#comment:2 Message-ID: <079.4b54283ee21a4da885819e2b18aa72f6@tools.ietf.org> References: <070.965222bf44169db264bbca911efb8573@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <070.965222bf44169db264bbca911efb8573@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:57:51 -0000 #1: Message format ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: assigned Priority: blocker | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Changes (by richard.alimi@…): * status: new => assigned Comment: draft-ietf-alto-protocol-03 now uses a more concise representation (using C-style structs) for formally specifying protocol structure. Still leaving this issue open since there has been no discussion yet in the WG regarding the messaging. -- Ticket URL: alto From trac@tools.ietf.org Mon Mar 8 16:58:20 2010 Return-Path: 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 BC4283A6C46 for ; Mon, 8 Mar 2010 16:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 eCZRBCXhNdEt for ; Mon, 8 Mar 2010 16:58:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D013A3A6C3E for ; Mon, 8 Mar 2010 16:58:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NonmC-0001Gc-Cd; Mon, 08 Mar 2010 16:58:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 00:58:24 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/alto/trac/ticket/2#comment:2 Message-ID: <079.c5f1a96416d99cb952bd86d4adf2b62e@tools.ietf.org> References: <070.422795dc42b5a4378222f8f004988620@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.422795dc42b5a4378222f8f004988620@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #2: Protocol details: version number X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:58:20 -0000 #2: Protocol details: version number ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: assigned Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Changes (by richard.alimi@…): * status: new => assigned -- Ticket URL: alto From trac@tools.ietf.org Mon Mar 8 16:58:46 2010 Return-Path: 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 03F383A6BCB for ; Mon, 8 Mar 2010 16:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 vc9IXrueI3CH for ; Mon, 8 Mar 2010 16:58:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4544D3A677E for ; Mon, 8 Mar 2010 16:58:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nonmb-0001H5-QZ; Mon, 08 Mar 2010 16:58:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 00:58:49 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/alto/trac/ticket/3#comment:2 Message-ID: <079.061a044b483540b1fa5e0ae19baf2e64@tools.ietf.org> References: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #3: Protocol details: map version tags X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:58:46 -0000 #3: Protocol details: map version tags ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: assigned Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Changes (by richard.alimi@…): * status: new => assigned -- Ticket URL: alto From trac@tools.ietf.org Mon Mar 8 16:59:21 2010 Return-Path: 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 6A5CF3A6BCB for ; Mon, 8 Mar 2010 16:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 lEu4lhtlbSjn for ; Mon, 8 Mar 2010 16:59:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB0963A677E for ; Mon, 8 Mar 2010 16:59:20 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NonnB-0001Hg-8e; Mon, 08 Mar 2010 16:59:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 00:59:25 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/alto/trac/ticket/3#comment:3 Message-ID: <079.3540635e0b1a9e132bf7b3a0cc3e4335@tools.ietf.org> References: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <070.4220111835c94aa6244cb06e6968c864@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #3: Protocol details: map version tags X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:59:21 -0000 #3: Protocol details: map version tags ---------------------------------------------+------------------------------ Reporter: enrico.marocco@… | Owner: richard.alimi@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------ Changes (by richard.alimi@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: alto From root@core3.amsl.com Mon Mar 8 17:00:01 2010 Return-Path: X-Original-To: alto@ietf.org Delivered-To: alto@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B0B913A6C57; Mon, 8 Mar 2010 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100309010001.B0B913A6C57@core3.amsl.com> Date: Mon, 8 Mar 2010 17:00:01 -0800 (PST) Cc: alto@ietf.org Subject: [alto] I-D Action:draft-ietf-alto-protocol-03.txt X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF. Title : ALTO Protocol Author(s) : R. Alimi, et al. Filename : draft-ietf-alto-protocol-03.txt Pages : 52 Date : 2010-03-08 Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-alto-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08164757.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Mon Mar 8 17:01:01 2010 Return-Path: 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 39C3C3A6C66 for ; Mon, 8 Mar 2010 17:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 rAhRPw+dAjCn for ; Mon, 8 Mar 2010 17:01:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 568EE3A6C63 for ; Mon, 8 Mar 2010 17:01:00 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nonol-0001Na-UI; Mon, 08 Mar 2010 17:01:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 01:01:03 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/7#comment:1 Message-ID: <070.9bcf549ea780ece26306d2baaa7f5a2f@tools.ietf.org> References: <061.e728b04bba6c1e593cfa8159cabea9bc@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <061.e728b04bba6c1e593cfa8159cabea9bc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #7: Fix IP addresses in protocol examples X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:01:01 -0000 #7: Fix IP addresses in protocol examples ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: richard.alimi@… Type: defect | Status: assigned Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Changes (by richard.alimi@…): * owner: => richard.alimi@… * status: new => assigned Comment: Ticket description should mention RFC5737. -- Ticket URL: alto From trac@tools.ietf.org Mon Mar 8 17:01:22 2010 Return-Path: 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 5AD733A6CA5 for ; Mon, 8 Mar 2010 17:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 jQvMmiLgCIjd for ; Mon, 8 Mar 2010 17:01:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 525D03A6CA2 for ; Mon, 8 Mar 2010 17:01:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nonp1-0001Ne-Sf; Mon, 08 Mar 2010 17:01:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Tue, 09 Mar 2010 01:01:19 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/alto/trac/ticket/7#comment:2 Message-ID: <070.02dd93081ee160c8ce1d9cb876a4c342@tools.ietf.org> References: <061.e728b04bba6c1e593cfa8159cabea9bc@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <061.e728b04bba6c1e593cfa8159cabea9bc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: Re: [alto] #7: Fix IP addresses in protocol examples X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:01:22 -0000 #7: Fix IP addresses in protocol examples ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: richard.alimi@… Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by richard.alimi@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: alto From enrico.marocco@telecomitalia.it Tue Mar 9 07:41:19 2010 Return-Path: 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 4C5E93A698F for ; Tue, 9 Mar 2010 07:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 DbAOGQazIIcN for ; Tue, 9 Mar 2010 07:41:12 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id BB6DD3A6B97 for ; Tue, 9 Mar 2010 07:41:11 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 9 Mar 2010 16:41:10 +0100 Received: from [163.162.173.9] (163.162.173.9) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 9 Mar 2010 16:41:09 +0100 Message-ID: <4B966C2A.4020003@telecomitalia.it> Date: Tue, 9 Mar 2010 16:41:30 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "Y.J. Gu" References: <008301cabe72$d75cc1d0$400ca40a@china.huawei.com> In-Reply-To: <008301cabe72$d75cc1d0$400ca40a@china.huawei.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020301010404090403000906" Cc: "alto@ietf.org" Subject: Re: [alto] Agenda requests for IETF77 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 15:41:19 -0000 --------------ms020301010404090403000906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Y.J. Gu wrote: > Shall I request to put [draft-gu-alto-redistribution] into agenda? Just to be clear, since there's been almost no discussion on the topic since Hiroshima, I guess the purpose of the presentation will be to specifically address the issue about signatures in the protocol draft -- basically the ticket Richard opened a few days ago: http://trac.tools.ietf.org/wg/alto/trac/ticket/6 Is that the intention? -- Ciao, Enrico --------------ms020301010404090403000906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMzA5 MTU0MTMwWjAjBgkqhkiG9w0BCQQxFgQUJb/F3CY5oH8gf6agA88/OtJwvDgwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBALHtR167B6r5sOdcnZKX Dta8IT2SNAtdrd0TFN2b6jQ3gQCj3+Ev2b9bASg+tRl4W890GZy6U5VhpuSAJJ3FULQCwX59 rgydZT5/0MiQT+teIZ6HuvYwzOcJyp+mBNDC4YcUUFDsbwRdQ8rjSoRR2HENav2N28jttgjU vTp7iI0aCdhkuKRphd0af5EODCiL2wnBo9sHFK05pxioCNxLlRB8SDVm75OC6Apg49KdWyX9 3tt2t0YYRjiUPR5Qml2uormdG5nmi1EulJtiNq+X+hW2LI88EaCPS46Rx9GuRNBqjLCLClkc Xr3lIcrbRusPGZMfkJO3XLdhua2qB12iRXgAAAAAAAA= --------------ms020301010404090403000906-- From enrico.marocco@telecomitalia.it Wed Mar 10 01:26:49 2010 Return-Path: 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 94EEF3A65A6 for ; Wed, 10 Mar 2010 01:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.647 X-Spam-Level: * X-Spam-Status: No, score=1.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 yFrvWwDZnnYz for ; Wed, 10 Mar 2010 01:26:48 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 42FE93A63C9 for ; Wed, 10 Mar 2010 01:26:48 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Mar 2010 10:26:46 +0100 Received: from [163.162.173.9] (163.162.173.9) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Mar 2010 10:26:45 +0100 Message-ID: <4B9765E9.9000206@telecomitalia.it> Date: Wed, 10 Mar 2010 10:27:05 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "alto@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090506040403020100020305" Subject: [alto] Draft agenda posted X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 09:26:49 -0000 --------------ms090506040403020100020305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, the _draft_ agenda for Anaheim is available at http://www.ietf.org/proceedings/10mar/agenda/alto.html If you sent a request that has not been satisfied with no explanation, that's simply because it got lost somewhere in the tubes or in our mailboxes; if that is the case, feel free to resend it. Please note that some presentations are still under discussion, so expect changes. -- Ciao, Enrico --------------ms090506040403020100020305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMzEw MDkyNzA1WjAjBgkqhkiG9w0BCQQxFgQUPX3aSh9XkPAYCcNVgLfkh60Eat0wXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAJLDOONfI6vVlTHUqVi5 YuBDb/WBmIG/eeAVGg9Ot5DbGySfX9ZNCO7Gdqg6C7fB+xLmvLwUcE8OJ7/OrcHJ54FT4ZQm vuGLc5W9TJilWOArl/GCo4POmwJgXR1F1/GsQJe9cI234zuY/F9uU606AZrTwXklu6Tlp8na 3d7Mep/aRvgAzKaIzC+BrvFlCDN4Z5Ps9z8oK0XZ1SEzHNQIVJKKju3Yt5EM+hcVqFUqGJwD +lCaojZdXCaweUdvuUuJRFNIy9rSajLeGPqrGpusTNcMcLpUhsUcWIh/RkEBrNuri0bFZtO8 IxYCr1VVGXKYs67DvHfn8pyPdaEyGXQcArUAAAAAAAA= --------------ms090506040403020100020305-- From jason_livingood@cable.comcast.com Thu Mar 11 12:48:21 2010 Return-Path: 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 F1A453A68E9 for ; Thu, 11 Mar 2010 12:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 Qvgdjc8lwqjR for ; Thu, 11 Mar 2010 12:48:21 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 726153A6C3F for ; Thu, 11 Mar 2010 12:39:31 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88293611; Thu, 11 Mar 2010 15:39:05 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 15:39:06 -0500 Received: from 10.36.138.43 ([10.36.138.43]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Mar 2010 20:39:05 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 11 Mar 2010 15:38:53 -0500 From: Jason Livingood To: , Message-ID: Thread-Topic: [alto] #1: Message format Thread-Index: AcrBWtzaJI6AQxA4oEGcHDW4NBVgpQ== In-Reply-To: <079.4b54283ee21a4da885819e2b18aa72f6@tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 11 Mar 2010 20:39:06.0843 (UTC) FILETIME=[E51AB2B0:01CAC15A] Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 20:48:22 -0000 You may want to make some of these tracker notes more verbose. In any case, was your objective to make the request and response simpler or what's in body of the itself? And depending upon the case, which section of http://tools.ietf.org/html/draft-ietf-alto-protocol-03 would you like targeted comments on? (7.5?) Thanks Jason On 3/8/10 7:57 PM, "alto issue tracker" wrote: > #1: Message=20 > format ---------------------------------------------+------------------------- > ----- Reporter: enrico.marocco@=8A | Owner: > richard.alimi@=8A Type: enhancement | > Status: assigned Priority: blocker | > Milestone: Component: protocol > | Version: Severity: Active WG Document > | Keywords: =20 > ---------------------------------------------+-----------------------------= - > Changes (by richard.alimi@=8A): * status: new =3D> assigned Comment: > draft-ietf-alto-protocol-03 now uses a more concise representation (using= > C-style structs) for formally specifying protocol structure. Still leaving > this issue open since there has been no discussion yet in the WG regarding > the messaging. -- Ticket URL: > alto > _______________________________________________ > alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto From richard.alimi@gmail.com Thu Mar 11 14:29:37 2010 Return-Path: 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 EAE033A6957 for ; Thu, 11 Mar 2010 14:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 UpnHDB1Mpieg for ; Thu, 11 Mar 2010 14:29:37 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id A28B33A6925 for ; Thu, 11 Mar 2010 14:29:36 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so96634fgg.13 for ; Thu, 11 Mar 2010 14:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=ZUVeeOggckKZnXn6wZ9C4HDGso2zXuF1vHAw2rEvHS8=; b=Wl4WZFM/rqwltLXiMiSmn5NvXvfso0di7ZRlQBys7dj88Kbg9pmjUGZI8VtPBptO3U 6gIxPQRS8eW7C5O6U0WXK4PZ/qspAGs2++dLIbPBC9iS3Shlp0bnhlEN+SrYi4M+qhZi 16QtZ/jq2Z8uhjo/IOINPJy+DjTZ4CvfrpEuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=GUKAlEhz3OdrKmsM69mSbUcwZCAdN4G7o6zJrx697crtqwEAKJ6a+0z1UdT5ug0m1M UFuIH/h9JE7jD2zizrCM6kOqneYgcJ0IyHVWU5x8RUztLTVhGpXxqrbMQryV0sV8dlE8 Coqbz366GwT0w+AVveG58fwBNNHC4Ka3wGVc8= Received: by 10.87.65.40 with SMTP id s40mr6461195fgk.14.1268346576637; Thu, 11 Mar 2010 14:29:36 -0800 (PST) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id e3sm600239fga.13.2010.03.11.14.29.35 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Mar 2010 14:29:35 -0800 (PST) Sender: Richard Alimi From: Richard Alimi To: Jason Livingood Date: Thu, 11 Mar 2010 17:29:33 -0500 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003111729.33544.richard.alimi@yale.edu> Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 22:29:38 -0000 Hi Jason, Thank you very much for taking a look. Please see below: On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > You may want to make some of these tracker notes more verbose. At this point, since this is a first stab at fully specifying protocol details, my personal feeling is that we are still wide-open for discussion on the whole document. However, there on a few points that I think are particular important for this go-around: - IPv4/IPv6 needs much more thought before integrating it into the document. In particular, what are the right semantics for handling IPv4 and IPv6 with respect to indicating provider preferences? (Some initial questions are noted on Issue #9 for this)? - With regard to messaging (including usage of HTTP URIs and the actual body encodings), can people think of issues that might cause problems for deployment in an operational network (e.g., load-balancing configuration)? Difficult or non-intuitive implementation (both server-side and client-side)? Are there any ambiguities you can see? I thinking through the current protocol details we have tried to address these, but input from others would be extremely helpful. - For Redistribution, this is a capability that seemed to get favorable feedback at IETF76. The current implementation uses HTTP headers/trailers to send the signatures, and a certificate is encoded in the Server Capability response. The idea is that an ALTO Client can locally cache the certificate and only contact the ALTO Server very infrequently even if it is gathering ALTO information (i.e., ALTOResponse structs) from other ALTO Clients instead of the ALTO Server itself. For this part, what do people think about how such redistribution information is encoded in the protocol? Is there a clean way to do this without requiring custom HTTP headers/trailers? Does the spec sufficiently convey when redistribution should or should not be used? > In any case, was your objective to make the request and response simpler or > what's in body of the itself? The changes from -02 -> -03 were to bring the encoding specification more in sync with other IETF specs and specify the structure of messages more formally (with adjustments made since we are actually specifying encoding within JSON). They were not intended to make the request/response simpler -- only to make the specification more precise. In the document, ALTOResponse is a JSON Object with certain required fields, which are specified in 7.2.3.3 (and the subsections thereof). This was the intent, anyways. Should this be made more clear? > > And depending upon the case, which section of > http://tools.ietf.org/html/draft-ietf-alto-protocol-03 would you like > targeted comments on? (7.5?) For protocol messaging, 7.5 is currently the guts of how ALTO Information is encoded. However, the current usage of HTTP (e.g., URI's, status codes, etc) in earlier subsections of Section 7 would be good to get feedback. As mentioned above, I would think that comments about the entire document are very useful, but the major changes in these couple of revisions have been to sections 6, 7, and 11 (so feel free to focus there). -- Richard Alimi Department of Computer Science Yale University From wangaijun@tsinghua.org.cn Sat Mar 13 06:55:50 2010 Return-Path: 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 08CC13A68E3 for ; Sat, 13 Mar 2010 06:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.994 X-Spam-Level: ** X-Spam-Status: No, score=2.994 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 60Yploa-O+3V for ; Sat, 13 Mar 2010 06:55:49 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by core3.amsl.com (Postfix) with SMTP id 448D83A6A1E for ; Sat, 13 Mar 2010 06:55:43 -0800 (PST) Received: from Wangaijun (unknown [115.170.78.68]) by app1 (Coremail) with SMTP id Z0GX06AbNwAYoptLDxlQAg==.16506S2; Sat, 13 Mar 2010 22:32:57 +0800 (CST) From: "wangaijun" To: Date: Sat, 13 Mar 2010 22:55:47 +0800 Message-ID: <000501cac2bd$445a0c40$cd0e24c0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CAC300.527D4C40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrCu76+X+fwcAc2QCS7EgNogaIBdAAATgsw Content-Language: zh-cn X-Coremail-Antispam: 1U3129KBjvdXoWrWr1kZFWDGr4kurykWw1fCrg_yoWxWFc_Cr WDt3yqk3W5AFZ5Ar15XFZ8WrWFv3y8Ar10ka4DtFy3G348Xw4kJ3Z3Cr9xG3yrW34rC3s8 uF98AasaqrWa9jkaLaAFLSUrUUUUjbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRxYjs xI4VWUJwAqx4xG67k08I80eVW5JVWrJwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048I F2xKxVW8JVW5JwAqx4xG6xAIxVCFxsxG0wAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1I0E4x 80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4ylx4CE17CEb7AF67AKxVWUJVWUXwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6I 8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4U0xZFpf9x0JUAnYwU UUUU= Subject: [alto] New draft notification: draft-sun-alto-notification-00 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 14:58:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CAC300.527D4C40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, all=A3=BA =20 We posted a new draft for notification mechanism(http://tools.ietf.org/id/draft-sun-alto-notification-00.txt) = from the ALTO server to reflect the change of network information timely. It = can lead the p2p stream traffic to keep up with the ISP=A1=AFs policy and = the topology adjustment. It can also lessen the burden of the ALTO client = and server for getting the same information repeatedly via the current query/response mechanism. =20 Any comment are welcome. =20 Best Regards.=20 =20 Wang Aijun Network Infrastructure Research Division Network and Service Research Department China Telecom Coporation Beijing Research Institute =20 =20 ------=_NextPart_000_0006_01CAC300.527D4C40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all=A3=BA

 

We posted a new draft for notification mechanism(http://tools.ietf.org/id/draft-sun-alto-notificatio= n-00.txt) from the ALTO server to reflect the change of network information = timely. It can lead the p2p stream traffic to keep up with the ISP=A1=AFs policy and = the topology adjustment. It can also lessen the burden of the ALTO client and server for getting = the same information repeatedly via the current query/response = mechanism.

 

Any comment are welcome.

 

Best Regards.

 

Wang = Aijun

Network = Infrastructure Research Division

Network and Service = Research Department

China Telecom = Coporation Beijing Research Institute

 

 

------=_NextPart_000_0006_01CAC300.527D4C40-- From Martin.Stiemerling@neclab.eu Tue Mar 16 07:44:37 2010 Return-Path: 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 AF2FA3A681B for ; Tue, 16 Mar 2010 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_05=-1.11] 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 FY7u7S3V6S3D for ; Tue, 16 Mar 2010 07:44:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id EDB4D3A69B3 for ; Tue, 16 Mar 2010 07:43:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 54B4A2C020505 for ; Tue, 16 Mar 2010 15:43:28 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aGs2NJAtr+o for ; Tue, 16 Mar 2010 15:43:28 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 3938B2C0204F9 for ; Tue, 16 Mar 2010 15:43:23 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {DCAA237A-2315-4A54-92E6-8C3F89BD109D} x-cr-hashedpuzzle: JSI= oeY= ARYq CyDE DdYS Dhrt D0dk Es89 FK98 GUmn GfJe GxUx I8PL Jz1m Ka0E KcFH; 1; YQBsAHQAbwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DCAA237A-2315-4A54-92E6-8C3F89BD109D}; bQBhAHIAdABpAG4ALgBzAHQAaQBlAG0AZQByAGwAaQBuAGcAQABuAGUAYwBsAGEAYgAuAGUAdQA=; Tue, 16 Mar 2010 14:43:19 GMT; QQBuACAAYQBsAHQAZQByAG4AYQB0AGkAdgBlACAAcwBlAHIAdgBpAGMAZQAgAHAAbAB1AGcALQBpAG4AIABmAG8AcgAgAHQAaABlACAAQQBMAFQATwAgAHAAcgBvAHQAbwBjAG8AbAAgACgAQQBLAEEAIABIADEAMgApAA== Content-class: urn:content-classes:message Date: Tue, 16 Mar 2010 15:43:19 +0100 Message-ID: <547F018265F92642B577B986577D671C012A2D5A@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An alternative service plug-in for the ALTO protocol (AKA H12) Thread-Index: AcrFFwUlw6aBDaE5RWmGYkzrYq9p8g== From: "Martin Stiemerling" To: Subject: [alto] An alternative service plug-in for the ALTO protocol (AKA H12) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 14:44:37 -0000 Dear all, Sebastian and me have updated the ALTO H12 draft: (http://tools.ietf.org/id/draft-kiesel-alto-h12-02.txt) This draft is the continuation of what we have presented at the San = Francisco IETF meeting (in conjunction with the H1H2 draft and the = follow-up discussions by the chairs): http://www.ietf.org/proceedings/74/slides/alto-3.pdf The draft describes another way, similar to the oracle approach, on how = the ALTO client can query the ALTO server. The draft is not meant to be = a competitor to the ALTO protocol, but we see the H12 as a good = alternative service plug-in for the ALTO protocol itself.=20 Thanks Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 From richard_woundy@cable.comcast.com Wed Mar 17 23:48:56 2010 Return-Path: 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 00CDF3A6359 for ; Wed, 17 Mar 2010 23:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-3.154, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 Awnet8jrgMs2 for ; Wed, 17 Mar 2010 23:48:55 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 4720E3A6765 for ; Wed, 17 Mar 2010 23:48:53 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88554639; Thu, 18 Mar 2010 02:48:45 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:48:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 02:42:20 -0400 Message-ID: In-Reply-To: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2Q References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> From: "Woundy, Richard" To: X-OriginalArrivalTime: 18 Mar 2010 06:48:46.0666 (UTC) FILETIME=[0EDB3AA0:01CAC667] Subject: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:48:56 -0000 Rm9sa3MsDQoNCkkgaGFkIHByb3ZpZGVkIHNvbWUgb2ZmbGluZSBjb21tZW50cyBhYm91dCB0aGUg aW5jbHVzaW9uIG9mIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBpbiBBTFRPLiBFbnJpY28gYXNrZWQg bWUgdG8gcmUtc2VuZCB0aGVtIHRvIHRoZSBtYWlsaW5nIGxpc3QuIEkgY2FuIGFsc28gZGlzY3Vz cyBpbiBuZXh0IHdlZWsncyBBTFRPIHNlc3Npb24uDQoNCkhlcmUgYXJlIG15IHByaXZhY3kgY29u Y2VybnMuDQoNCjEuIERlcGVuZGluZyBvbiB0aGUgSVNQJ3MgcHJpY2luZyBhbmQgcm9sbG91dCBv ZiBiYW5kd2lkdGggdGllcnMsIHRoZXJlIG1heSBiZSByZWxhdGl2ZWx5IGZldyBzdWJzY3JpYmVy cyB3aXRoaW4gYSBwYXJ0aWN1bGFyIHRpZXIuIFRoZXJlZm9yZSBhIHRoaXJkIHBhcnR5IGNvbnN1 bWluZyBBTFRPIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBpbmZvcm1hdGlvbiBjYW4gbWFrZSBhIGdv b2QgZ3Vlc3MgYWJvdXQgdGhlIGlkZW50aXR5IG9mIGEgc3Vic2NyaWJlciB3aXRoaW4gYSAicmFy ZWx5IHVzZWQiIGJhbmR3aWR0aCB0aWVyLg0KDQoyLiBTZXBhcmF0ZWx5LCBhIHRoaXJkIHBhcnR5 IGNvbnN1bWluZyBBTFRPIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBpbmZvcm1hdGlvbiBtYXkgYmUg YWJsZSB0byBtYWtlIGFuIGluZm9ybWVkIGd1ZXNzIGFib3V0IHRoZSBlY29ub21pYyBzdGF0dXMg b2YgYSBzdWJzY3JpYmVyIGJhc2VkIG9uIHRoZSBiYW5kd2lkdGggdGllciwgd2hpY2ggbWF5IG5v dCBiZSBkZXNpcmFibGUgdG8gdGhlIHN1YnNjcmliZXIuDQoNCjMuIFRoZSBzdWJzY3JpYmVyIG1h eSBub3QgaW50ZW5kIHRvIHVzZSAqYWxsKiBwcm92aXNpb25lZCBiYW5kd2lkdGggZm9yIGEgcGFy dGljdWxhciBhcHBsaWNhdGlvbiAoZS5nLiBQMlApLiBGb3IgZXhhbXBsZSwgcGVyaGFwcyB0aGUg c3Vic2NyaWJlciBpbnRlbmRzIHRvIHVzZSBwcm92aXNpb25lZCB1cGxpbmsgYmFuZHdpZHRoIGZv ciB0ZWxlY29tbXV0aW5nLCB0ZWxlcHJlc2VuY2UsIG9ubGluZSBzdG9yYWdlIGJhY2t1cHMsIGV0 Yy4gQSB0aGlyZCBwYXJ0eSBjb25zdW1pbmcgQUxUTyBwcm92aXNpb25lZCBiYW5kd2lkdGggaW5m b3JtYXRpb24gc2hvdWxkIGJlIGF3YXJlIHRoYXQgdGhlIHN1YnNjcmliZXIncyBwcm92aXNpb25l ZCBiYW5kd2lkdGggbWF5IGJlIHJlc2VydmVkIGZvciBkaWZmZXJlbnQgYXBwbGljYXRpb25zLg0K DQpIZXJlIGFyZSBteSB0aG91Z2h0cyBvbiBkeW5hbWljIGFkZHJlc3MgcmUtYWxsb2NhdGlvbi4N Cg0KSVNQcyByZWFsbG9jYXRlIElQdjQgc3VibmV0cyB3aXRoaW4gdGhlaXIgaW5mcmFzdHJ1Y3R1 cmUgZnJvbSB0aW1lIHRvIHRpbWUsIHBhcnRseSB0byBlbnN1cmUgdGhlIGVmZmljaWVudCB1c2Fn ZSBvZiBJUHY0IGFkZHJlc3NlcyAoYSBzY2FyY2UgcmVzb3VyY2UpLCBhbmQgcGFydGx5IHRvIGVu YWJsZSBlZmZpY2llbnQgcm91dGUgdGFibGVzIHdpdGhpbiB0aGVpciBuZXR3b3JrIHJvdXRlcnMu IFRoZSBmcmVxdWVuY3kgb2YgdGhlc2UgInJlbnVtYmVyaW5nIGV2ZW50cyIgZGVwZW5kIG9uIHRo ZSBncm93dGggaW4gbnVtYmVyIG9mIHN1YnNjcmliZXJzIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9m IGFkZHJlc3Mgc3BhY2Ugd2l0aGluIHRoZSBJU1AuIEFzIGEgcmVzdWx0LCBhIHN1YnNjcmliZXIn cyBob3VzZWhvbGQgZGV2aWNlIGNvdWxkIHJldGFpbiBhbiBJUHY0IGFkZHJlc3MgZm9yIGFzIHNo b3J0IGFzIGEgZmV3IG1pbnV0ZXMsIG9yIGZvciBtb250aHMgYXQgYSB0aW1lIG9yIGV2ZW4gbG9u Z2VyLg0KDQpTb21lIGZvbGtzIGhhdmUgc3VnZ2VzdGVkIHRoYXQgSVNQcyBwcm92aWRpbmcgQUxU TyBzZXJ2aWNlcyBjb3VsZCBzdWItZGl2aWRlIHRoZWlyIHN1YnNjcmliZXJzJyBkZXZpY2VzIGlu dG8gZGlmZmVyZW50IElQdjQgc3VibmV0cyAob3IgY2VydGFpbiBJUHY0IGFkZHJlc3MgcmFuZ2Vz KSBiYXNlZCBvbiB0aGUgcHVyY2hhc2VkIHNlcnZpY2UgdGllciwgYXMgd2VsbCBhcyBiYXNlZCBv biB0aGUgbG9jYXRpb24gaW4gdGhlIG5ldHdvcmsgdG9wb2xvZ3kuIFRoZSBwcm9ibGVtIGlzIHRo YXQgdGhpcyBzdWItYWxsb2NhdGlvbiBvZiBJUHY0IHN1Ym5ldHMgdGVuZHMgdG8gZGVjcmVhc2Ug dGhlIGVmZmljaWVuY3kgb2YgSVB2NCBhZGRyZXNzIGFsbG9jYXRpb24uIEEgZ3Jvd2luZyBJU1Ag dGhhdCBuZWVkcyB0byBtYWludGFpbiBoaWdoIGVmZmljaWVuY3kgb2YgSVB2NCBhZGRyZXNzIHV0 aWxpemF0aW9uIG1heSBiZSByZWx1Y3RhbnQgdG8gamVvcGFyZGl6ZSB0aGVpciBmdXR1cmUgYWNx dWlzaXRpb24gb2YgSVB2NCBhZGRyZXNzIHNwYWNlLg0KDQpUaGVyZWZvcmUsIGNvbnN1bWVycyBv ZiBwZXItdXNlciBBTFRPIGluZm9ybWF0aW9uIHNob3VsZCBhc3N1bWUgdGhhdCBzdWJzY3JpYmVy cyByZXRhaW4gSVB2NCBhZGRyZXNzZXMgZm9yIG9ubHkgYSByZWxhdGl2ZWx5IHNob3J0IHBlcmlv ZCBvZiB0aW1lLCBlLmcuIG1pbnV0ZXMsIGFuZCB0aGF0IHN1YnNjcmliZXJzIG9mIGRpZmZlcmVu dCBzZXJ2aWNlIHRpZXJzIHdpbGwgY28tZXhpc3QgaW4gc29tZSBJU1AncyBJUHY0IHN1Ym5ldHMu DQoNCi0tIFJpY2gNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGFsdG8tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFsdG8tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGFsdG8gaXNzdWUgdHJhY2tlcg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNywgMjAxMCA1 OjE0IEFNDQpUbzogaWV0Zi1hbHRvQHNraWVzZWwuZGU7IGVucmljby5tYXJvY2NvQHRlbGVjb21p dGFsaWEuaXQNCkNjOiBhbHRvQGlldGYub3JnDQpTdWJqZWN0OiBbYWx0b10gIzQ6IFByb3Zpc2lv bmVkIGJhbmR3aWR0aA0KDQojNDogUHJvdmlzaW9uZWQgYmFuZHdpZHRoDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogUmVwb3J0ZXI6ICBlbnJpY28ubWFyb2Njb0DigKYgICAgICAgICAgICAgICAgIHwg ICAgICAgT3duZXI6ICBTZWJhc3RpYW4gS2llc2VsIDxpZXRmLWFsdG9A4oCmPiAgICAgICAgIA0K ICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1 czogIG5ldyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIFByaW9yaXR5OiAg bWFqb3IgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ29tcG9uZW50OiAgcmVxcyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KIFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFRoZSBkb2N1bWVudCBzaG91bGQgdHJhY2sg KGFuZCBpZGVhbGx5IHN0aW11bGF0ZSBkaXNjdXNzaW9uIHRvIHJlYWNoDQogY29uc2Vuc3VzKSB0 aGUgYXJndW1lbnRzIGFib3V0IHByb3ZpZGluZyBpbmZvcm1hdGlvbiBhYm91dCBwcm92aXNpb25l ZA0KIGJhbmR3aWR0aCwgYXMgaXQgbWF5IGhhdmUgbm9uIHRyaXZpYWwgaW1wYWN0IG9uIHRoZSBw cm90b2NvbCBkZXNpZ24uIFRoZQ0KIHRvcGljIHdhcyBkaXNjdXNzZWQgaW4gW3dpa2k6SWV0Zjc2 IEhpcm9zaGltYV0gYW5kIHByZXZpb3VzbHkgb24gdGhlDQogbWFpbGluZyBsaXN0Og0KIFtodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWx0by9jdXJyZW50L21zZzAwMzIyLmh0 bWxdDQogW2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hbHRvL2N1cnJlbnQv bXNnMDA0NzYuaHRtbF0NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMuaWV0 Zi5vcmcvd2cvYWx0by90cmFjL3RpY2tldC80Pg0KYWx0byA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2FsdG8vPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KYWx0byBtYWlsaW5nIGxpc3QNCmFsdG9AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWx0bw0K From sa2086@columbia.edu Thu Mar 18 00:18:34 2010 Return-Path: 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 3277D3A68D9 for ; Thu, 18 Mar 2010 00:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 hfubMoSPO31Q for ; Thu, 18 Mar 2010 00:18:33 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 951563A68D6 for ; Thu, 18 Mar 2010 00:18:04 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2I7IBvX015404; Thu, 18 Mar 2010 03:18:12 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2I7IB9f011871; Thu, 18 Mar 2010 03:18:11 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.3/Submit) with ESMTP id o2I7IBFM011868; Thu, 18 Mar 2010 03:18:11 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 18 Mar 2010 03:18:11 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "Woundy, Richard" In-Reply-To: Message-ID: References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1254324197-1268896691=:10619" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 07:18:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1254324197-1268896691=:10619 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT As you point out, allowing third party to query ALTO servers to determine the provisioned bandwidth of *any user* has privacy implications. However, the same privacy implications do not apply if a user wants to query the provisioned bandwidth of the broadband connection it purchased. There could be access limitations, however. For example, a user that is connected to Starbucks WiFi is likely to be limited from querying the connection bandwidth. Also, an application may want to query its gateway or cable modem to determine the current load at the modem. Such a mechanism does not require querying any ISP managed ALTO server. It will be helpful to clarify these two issues. Salman On Thu, 18 Mar 2010, Woundy, Richard wrote: > Folks, > > I had provided some offline comments about the inclusion of provisioned bandwidth in ALTO. Enrico asked me to re-send them to the mailing list. I can also discuss in next week's ALTO session. > > Here are my privacy concerns. > > 1. Depending on the ISP's pricing and rollout of bandwidth tiers, there may be relatively few subscribers within a particular tier. Therefore a third party consuming ALTO provisioned bandwidth information can make a good guess about the identity of a subscriber within a "rarely used" bandwidth tier. > > 2. Separately, a third party consuming ALTO provisioned bandwidth information may be able to make an informed guess about the economic status of a subscriber based on the bandwidth tier, which may not be desirable to the subscriber. > > 3. The subscriber may not intend to use *all* provisioned bandwidth for a particular application (e.g. P2P). For example, perhaps the subscriber intends to use provisioned uplink bandwidth for telecommuting, telepresence, online storage backups, etc. A third party consuming ALTO provisioned bandwidth information should be aware that the subscriber's provisioned bandwidth may be reserved for different applications. > > Here are my thoughts on dynamic address re-allocation. > > ISPs reallocate IPv4 subnets within their infrastructure from time to time, partly to ensure the efficient usage of IPv4 addresses (a scarce resource), and partly to enable efficient route tables within their network routers. The frequency of these "renumbering events" depend on the growth in number of subscribers and the availability of address space within the ISP. As a result, a subscriber's household device could retain an IPv4 address for as short as a few minutes, or for months at a time or even longer. > > Some folks have suggested that ISPs providing ALTO services could sub-divide their subscribers' devices into different IPv4 subnets (or certain IPv4 address ranges) based on the purchased service tier, as well as based on the location in the network topology. The problem is that this sub-allocation of IPv4 subnets tends to decrease the efficiency of IPv4 address allocation. A growing ISP that needs to maintain high efficiency of IPv4 address utilization may be reluctant to jeopardize their future acquisition of IPv4 address space. > > Therefore, consumers of per-user ALTO information should assume that subscribers retain IPv4 addresses for only a relatively short period of time, e.g. minutes, and that subscribers of different service tiers will co-exist in some ISP's IPv4 subnets. > > -- Rich > > -----Original Message----- > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of alto issue tracker > Sent: Wednesday, February 17, 2010 5:14 AM > To: ietf-alto@skiesel.de; enrico.marocco@telecomitalia.it > Cc: alto@ietf.org > Subject: [alto] #4: Provisioned bandwidth > > #4: Provisioned bandwidth > ---------------------------------------------+------------------------------ > Reporter: enrico.marocco@… | Owner: Sebastian Kiesel > Type: enhancement | Status: new > Priority: major | Milestone: > Component: reqs | Version: > Severity: - | Keywords: > ---------------------------------------------+------------------------------ > The document should track (and ideally stimulate discussion to reach > consensus) the arguments about providing information about provisioned > bandwidth, as it may have non trivial impact on the protocol design. The > topic was discussed in [wiki:Ietf76 Hiroshima] and previously on the > mailing list: > [http://www.ietf.org/mail-archive/web/alto/current/msg00322.html] > [http://www.ietf.org/mail-archive/web/alto/current/msg00476.html] > > -- > Ticket URL: > alto > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto ---559023410-1254324197-1268896691=:10619-- From richard_woundy@cable.comcast.com Thu Mar 18 01:04:53 2010 Return-Path: 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 CF86F3A6AB9 for ; Thu, 18 Mar 2010 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 gbJWohYd5bMF for ; Thu, 18 Mar 2010 01:04:52 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 065703A6B50 for ; Thu, 18 Mar 2010 01:00:59 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74607464; Thu, 18 Mar 2010 04:01:01 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 04:01:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 03:52:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: AcrGay2y3mL4uJcoTjS7bxhosSwjjAABMWQj From: "Woundy, Richard" To: X-OriginalArrivalTime: 18 Mar 2010 08:01:01.0992 (UTC) FILETIME=[26E97A80:01CAC671] Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 08:04:53 -0000 SSBhZ3JlZSB3aXRoIHlvdSBvbiB0aG9zZSB0d28gY2FzZXMuIFRoZSBwcml2YWN5IGlzc3VlcyBJ IHJhaXNlZCBhcmUgYWJvdXQgdGhpcmQgcGFydHkgcmVxdWVzdHMgZm9yIGluZm9ybWF0aW9uLg0K DQotLSBSaWNoDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2EyMDg2 QGNvbHVtYmlhLmVkdSA8c2EyMDg2QGNvbHVtYmlhLmVkdT4NClRvOiBXb3VuZHksIFJpY2hhcmQN CkNjOiBhbHRvQGlldGYub3JnIDxhbHRvQGlldGYub3JnPg0KU2VudDogVGh1IE1hciAxOCAwMzox ODoxMSAyMDEwDQpTdWJqZWN0OiBSZTogW2FsdG9dIENvbW1lbnRzIG9uIHByb3Zpc2lvbmVkIGJh bmR3aWR0aCBhbmQgQUxUTw0KDQpBcyB5b3UgcG9pbnQgb3V0LCBhbGxvd2luZyB0aGlyZCBwYXJ0 eSB0byBxdWVyeSBBTFRPIHNlcnZlcnMgdG8gZGV0ZXJtaW5lIA0KdGhlIHByb3Zpc2lvbmVkIGJh bmR3aWR0aCBvZiAqYW55IHVzZXIqIGhhcyBwcml2YWN5IGltcGxpY2F0aW9ucy4NCg0KSG93ZXZl ciwgdGhlIHNhbWUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgZG8gbm90IGFwcGx5IGlmIGEgdXNlciB3 YW50cyB0byANCnF1ZXJ5IHRoZSBwcm92aXNpb25lZCBiYW5kd2lkdGggb2YgdGhlIGJyb2FkYmFu ZCBjb25uZWN0aW9uIGl0IHB1cmNoYXNlZC4NClRoZXJlIGNvdWxkIGJlIGFjY2VzcyBsaW1pdGF0 aW9ucywgaG93ZXZlci4gRm9yIGV4YW1wbGUsIGEgdXNlciANCnRoYXQgaXMgY29ubmVjdGVkIHRv IFN0YXJidWNrcyBXaUZpIGlzIGxpa2VseSB0byBiZSBsaW1pdGVkIGZyb20gcXVlcnlpbmcgDQp0 aGUgY29ubmVjdGlvbiBiYW5kd2lkdGguDQoNCkFsc28sIGFuIGFwcGxpY2F0aW9uIG1heSB3YW50 IHRvIHF1ZXJ5IGl0cyBnYXRld2F5IG9yIGNhYmxlIG1vZGVtIHRvIA0KZGV0ZXJtaW5lIHRoZSBj dXJyZW50IGxvYWQgYXQgdGhlIG1vZGVtLiBTdWNoIGEgbWVjaGFuaXNtIGRvZXMgbm90IHJlcXVp cmUgDQpxdWVyeWluZyBhbnkgSVNQIG1hbmFnZWQgQUxUTyBzZXJ2ZXIuDQoNCkl0IHdpbGwgYmUg aGVscGZ1bCB0byBjbGFyaWZ5IHRoZXNlIHR3byBpc3N1ZXMuDQoNClNhbG1hbg0KDQoNCk9uIFRo dSwgMTggTWFyIDIwMTAsIFdvdW5keSwgUmljaGFyZCB3cm90ZToNCg0KPiBGb2xrcywNCj4NCj4g SSBoYWQgcHJvdmlkZWQgc29tZSBvZmZsaW5lIGNvbW1lbnRzIGFib3V0IHRoZSBpbmNsdXNpb24g b2YgcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGluIEFMVE8uIEVucmljbyBhc2tlZCBtZSB0byByZS1z ZW5kIHRoZW0gdG8gdGhlIG1haWxpbmcgbGlzdC4gSSBjYW4gYWxzbyBkaXNjdXNzIGluIG5leHQg d2VlaydzIEFMVE8gc2Vzc2lvbi4NCj4NCj4gSGVyZSBhcmUgbXkgcHJpdmFjeSBjb25jZXJucy4N Cj4NCj4gMS4gRGVwZW5kaW5nIG9uIHRoZSBJU1AncyBwcmljaW5nIGFuZCByb2xsb3V0IG9mIGJh bmR3aWR0aCB0aWVycywgdGhlcmUgbWF5IGJlIHJlbGF0aXZlbHkgZmV3IHN1YnNjcmliZXJzIHdp dGhpbiBhIHBhcnRpY3VsYXIgdGllci4gVGhlcmVmb3JlIGEgdGhpcmQgcGFydHkgY29uc3VtaW5n IEFMVE8gcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIGNhbiBtYWtlIGEgZ29vZCBn dWVzcyBhYm91dCB0aGUgaWRlbnRpdHkgb2YgYSBzdWJzY3JpYmVyIHdpdGhpbiBhICJyYXJlbHkg dXNlZCIgYmFuZHdpZHRoIHRpZXIuDQo+DQo+IDIuIFNlcGFyYXRlbHksIGEgdGhpcmQgcGFydHkg Y29uc3VtaW5nIEFMVE8gcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIG1heSBiZSBh YmxlIHRvIG1ha2UgYW4gaW5mb3JtZWQgZ3Vlc3MgYWJvdXQgdGhlIGVjb25vbWljIHN0YXR1cyBv ZiBhIHN1YnNjcmliZXIgYmFzZWQgb24gdGhlIGJhbmR3aWR0aCB0aWVyLCB3aGljaCBtYXkgbm90 IGJlIGRlc2lyYWJsZSB0byB0aGUgc3Vic2NyaWJlci4NCj4NCj4gMy4gVGhlIHN1YnNjcmliZXIg bWF5IG5vdCBpbnRlbmQgdG8gdXNlICphbGwqIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBmb3IgYSBw YXJ0aWN1bGFyIGFwcGxpY2F0aW9uIChlLmcuIFAyUCkuIEZvciBleGFtcGxlLCBwZXJoYXBzIHRo ZSBzdWJzY3JpYmVyIGludGVuZHMgdG8gdXNlIHByb3Zpc2lvbmVkIHVwbGluayBiYW5kd2lkdGgg Zm9yIHRlbGVjb21tdXRpbmcsIHRlbGVwcmVzZW5jZSwgb25saW5lIHN0b3JhZ2UgYmFja3Vwcywg ZXRjLiBBIHRoaXJkIHBhcnR5IGNvbnN1bWluZyBBTFRPIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBp bmZvcm1hdGlvbiBzaG91bGQgYmUgYXdhcmUgdGhhdCB0aGUgc3Vic2NyaWJlcidzIHByb3Zpc2lv bmVkIGJhbmR3aWR0aCBtYXkgYmUgcmVzZXJ2ZWQgZm9yIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMu DQo+DQo+IEhlcmUgYXJlIG15IHRob3VnaHRzIG9uIGR5bmFtaWMgYWRkcmVzcyByZS1hbGxvY2F0 aW9uLg0KPg0KPiBJU1BzIHJlYWxsb2NhdGUgSVB2NCBzdWJuZXRzIHdpdGhpbiB0aGVpciBpbmZy YXN0cnVjdHVyZSBmcm9tIHRpbWUgdG8gdGltZSwgcGFydGx5IHRvIGVuc3VyZSB0aGUgZWZmaWNp ZW50IHVzYWdlIG9mIElQdjQgYWRkcmVzc2VzIChhIHNjYXJjZSByZXNvdXJjZSksIGFuZCBwYXJ0 bHkgdG8gZW5hYmxlIGVmZmljaWVudCByb3V0ZSB0YWJsZXMgd2l0aGluIHRoZWlyIG5ldHdvcmsg cm91dGVycy4gVGhlIGZyZXF1ZW5jeSBvZiB0aGVzZSAicmVudW1iZXJpbmcgZXZlbnRzIiBkZXBl bmQgb24gdGhlIGdyb3d0aCBpbiBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgYW5kIHRoZSBhdmFpbGFi aWxpdHkgb2YgYWRkcmVzcyBzcGFjZSB3aXRoaW4gdGhlIElTUC4gQXMgYSByZXN1bHQsIGEgc3Vi c2NyaWJlcidzIGhvdXNlaG9sZCBkZXZpY2UgY291bGQgcmV0YWluIGFuIElQdjQgYWRkcmVzcyBm b3IgYXMgc2hvcnQgYXMgYSBmZXcgbWludXRlcywgb3IgZm9yIG1vbnRocyBhdCBhIHRpbWUgb3Ig ZXZlbiBsb25nZXIuDQo+DQo+IFNvbWUgZm9sa3MgaGF2ZSBzdWdnZXN0ZWQgdGhhdCBJU1BzIHBy b3ZpZGluZyBBTFRPIHNlcnZpY2VzIGNvdWxkIHN1Yi1kaXZpZGUgdGhlaXIgc3Vic2NyaWJlcnMn IGRldmljZXMgaW50byBkaWZmZXJlbnQgSVB2NCBzdWJuZXRzIChvciBjZXJ0YWluIElQdjQgYWRk cmVzcyByYW5nZXMpIGJhc2VkIG9uIHRoZSBwdXJjaGFzZWQgc2VydmljZSB0aWVyLCBhcyB3ZWxs IGFzIGJhc2VkIG9uIHRoZSBsb2NhdGlvbiBpbiB0aGUgbmV0d29yayB0b3BvbG9neS4gVGhlIHBy b2JsZW0gaXMgdGhhdCB0aGlzIHN1Yi1hbGxvY2F0aW9uIG9mIElQdjQgc3VibmV0cyB0ZW5kcyB0 byBkZWNyZWFzZSB0aGUgZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3MgYWxsb2NhdGlvbi4gQSBn cm93aW5nIElTUCB0aGF0IG5lZWRzIHRvIG1haW50YWluIGhpZ2ggZWZmaWNpZW5jeSBvZiBJUHY0 IGFkZHJlc3MgdXRpbGl6YXRpb24gbWF5IGJlIHJlbHVjdGFudCB0byBqZW9wYXJkaXplIHRoZWly IGZ1dHVyZSBhY3F1aXNpdGlvbiBvZiBJUHY0IGFkZHJlc3Mgc3BhY2UuDQo+DQo+IFRoZXJlZm9y ZSwgY29uc3VtZXJzIG9mIHBlci11c2VyIEFMVE8gaW5mb3JtYXRpb24gc2hvdWxkIGFzc3VtZSB0 aGF0IHN1YnNjcmliZXJzIHJldGFpbiBJUHY0IGFkZHJlc3NlcyBmb3Igb25seSBhIHJlbGF0aXZl bHkgc2hvcnQgcGVyaW9kIG9mIHRpbWUsIGUuZy4gbWludXRlcywgYW5kIHRoYXQgc3Vic2NyaWJl cnMgb2YgZGlmZmVyZW50IHNlcnZpY2UgdGllcnMgd2lsbCBjby1leGlzdCBpbiBzb21lIElTUCdz IElQdjQgc3VibmV0cy4NCj4NCj4gLS0gUmljaA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBhbHRvLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphbHRvLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBhbHRvIGlzc3VlIHRyYWNrZXINCj4gU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAxNywgMjAxMCA1OjE0IEFNDQo+IFRvOiBpZXRmLWFsdG9Ac2tpZXNlbC5k ZTsgZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdA0KPiBDYzogYWx0b0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBbYWx0b10gIzQ6IFByb3Zpc2lvbmVkIGJhbmR3aWR0aA0KPg0KPiAjNDogUHJv dmlzaW9uZWQgYmFuZHdpZHRoDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gUmVwb3J0ZXI6ICBl bnJpY28ubWFyb2Njb0DigKYgICAgICAgICAgICAgICAgIHwgICAgICAgT3duZXI6ICBTZWJhc3Rp YW4gS2llc2VsIDxpZXRmLWFsdG9A4oCmPg0KPiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4gUHJpb3JpdHk6ICBtYWpvciAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBy ZXFzICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiBTZXZlcml0 eTogIC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5d29yZHM6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhlIGRvY3VtZW50IHNob3VsZCB0cmFjayAoYW5kIGlkZWFs bHkgc3RpbXVsYXRlIGRpc2N1c3Npb24gdG8gcmVhY2gNCj4gY29uc2Vuc3VzKSB0aGUgYXJndW1l bnRzIGFib3V0IHByb3ZpZGluZyBpbmZvcm1hdGlvbiBhYm91dCBwcm92aXNpb25lZA0KPiBiYW5k d2lkdGgsIGFzIGl0IG1heSBoYXZlIG5vbiB0cml2aWFsIGltcGFjdCBvbiB0aGUgcHJvdG9jb2wg ZGVzaWduLiBUaGUNCj4gdG9waWMgd2FzIGRpc2N1c3NlZCBpbiBbd2lraTpJZXRmNzYgSGlyb3No aW1hXSBhbmQgcHJldmlvdXNseSBvbiB0aGUNCj4gbWFpbGluZyBsaXN0Og0KPiBbaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FsdG8vY3VycmVudC9tc2cwMDMyMi5odG1sXQ0K PiBbaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FsdG8vY3VycmVudC9tc2cw MDQ3Ni5odG1sXQ0KPg0KPiAtLQ0KPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMuaWV0 Zi5vcmcvd2cvYWx0by90cmFjL3RpY2tldC80Pg0KPiBhbHRvIDxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvYWx0by8+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGFsdG8gbWFpbGluZyBsaXN0DQo+IGFsdG9AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbHRvDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFsdG8gbWFpbGluZyBsaXN0DQo+IGFsdG9A aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbHRvDQo= From Martin.Stiemerling@neclab.eu Thu Mar 18 03:01:46 2010 Return-Path: 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 AB5303A6925 for ; Thu, 18 Mar 2010 03:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=-1.365, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 xKtYVrVyX28E for ; Thu, 18 Mar 2010 03:01:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3D2FA3A68EA for ; Thu, 18 Mar 2010 03:01:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 47AAD2C020505; Thu, 18 Mar 2010 11:01:56 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e86eFJCx10oa; Thu, 18 Mar 2010 11:01:56 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 2AF162C0204F9; Thu, 18 Mar 2010 11:01:46 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 18 Mar 2010 11:01:45 +0100 Message-ID: <547F018265F92642B577B986577D671C012A2FD8@VENUS.office> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2QAAXOucA= References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> From: "Martin Stiemerling" To: "Woundy, Richard" , Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 10:01:46 -0000 SGkgUmljaCwgDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhbHRv LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphbHRvLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZg0KPiBXb3VuZHksIFJpY2hhcmQNCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDE4LCAyMDEw IDc6NDIgQU0NCj4gVG86IGFsdG9AaWV0Zi5vcmcNCj4gU3ViamVjdDogW2FsdG9dIENvbW1lbnRz IG9uIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhbmQgQUxUTw0KPiANCj4gRm9sa3MsDQo+IA0KPiBJ IGhhZCBwcm92aWRlZCBzb21lIG9mZmxpbmUgY29tbWVudHMgYWJvdXQgdGhlIGluY2x1c2lvbiBv ZiBwcm92aXNpb25lZA0KPiBiYW5kd2lkdGggaW4gQUxUTy4gRW5yaWNvIGFza2VkIG1lIHRvIHJl LXNlbmQgdGhlbSB0byB0aGUgbWFpbGluZyBsaXN0Lg0KPiBJIGNhbiBhbHNvIGRpc2N1c3MgaW4g bmV4dCB3ZWVrJ3MgQUxUTyBzZXNzaW9uLg0KPiANCj4gSGVyZSBhcmUgbXkgcHJpdmFjeSBjb25j ZXJucy4NCj4gDQo+IDEuIERlcGVuZGluZyBvbiB0aGUgSVNQJ3MgcHJpY2luZyBhbmQgcm9sbG91 dCBvZiBiYW5kd2lkdGggdGllcnMsIHRoZXJlDQo+IG1heSBiZSByZWxhdGl2ZWx5IGZldyBzdWJz Y3JpYmVycyB3aXRoaW4gYSBwYXJ0aWN1bGFyIHRpZXIuIFRoZXJlZm9yZSBhDQo+IHRoaXJkIHBh cnR5IGNvbnN1bWluZyBBTFRPIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBpbmZvcm1hdGlvbiBjYW4g bWFrZSBhDQo+IGdvb2QgZ3Vlc3MgYWJvdXQgdGhlIGlkZW50aXR5IG9mIGEgc3Vic2NyaWJlciB3 aXRoaW4gYSAicmFyZWx5IHVzZWQiDQo+IGJhbmR3aWR0aCB0aWVyLg0KPiANCj4gMi4gU2VwYXJh dGVseSwgYSB0aGlyZCBwYXJ0eSBjb25zdW1pbmcgQUxUTyBwcm92aXNpb25lZCBiYW5kd2lkdGgN Cj4gaW5mb3JtYXRpb24gbWF5IGJlIGFibGUgdG8gbWFrZSBhbiBpbmZvcm1lZCBndWVzcyBhYm91 dCB0aGUgZWNvbm9taWMNCj4gc3RhdHVzIG9mIGEgc3Vic2NyaWJlciBiYXNlZCBvbiB0aGUgYmFu ZHdpZHRoIHRpZXIsIHdoaWNoIG1heSBub3QgYmUNCj4gZGVzaXJhYmxlIHRvIHRoZSBzdWJzY3Jp YmVyLg0KDQpXaHkgc2hvdWxkIEkgd2FpdCBmb3IgQUxUTyBpZiBJIGNhbiBkbyB0aGlzIHdpdGgg cmVhc29uYWJsZSBlZmZvcnQgYnkgdG9kYXkgd2l0aCB0b2RheSdzIG1lYW5zPw0KDQpZb3UgY2Fu IHVzZSB0aGUgZ2VvIGluZm9ybWF0aW9uIHByb3ZpZGVkIGZvciBhIHBhcnRpY3VsYXIgSVAgYWRk cmVzcyBvdXQgb2YgdGhlIHdob2lzIGFuZCBjb21iaW5lIHRoaXMgd2l0aCBzb21lIG90aGVyIGF2 YWlsYWJsZSBkYXRhIChnb29nbGUgbWFwcy9zdHJlZXQgdmlldykgdG8gc2VlIGlmIHBlb3BsZSBh cmUgbGl2aW5nIGluIHdlYWx0aHkgYXJlYSBvciBub3QuIFRyeSB0aGlzIHdpdGggdGhlIElQIGFk ZHJlc3NlcyBpbmRpY2F0ZWQgZm9yIHRoaXMgZW1haWwgYXMgc210cCBzZW5kZXIuLi4oIDE5NS4z Ny43MC40MSkuIFVuZm9ydHVuYXRlbHksIHRoZXJlIGlzIG5vIHN0cmVldCB2aWV3IGZvciB0aGlz IGxvY2F0aW9uLCBidXQgaW4gb3RoZXIgcGxhY2VzIHRoaXMgd2lsbCBoZWxwIGV2ZW4gYmV0dGVy IHRvIGRldGVybWluZSBpZiB0aGUgcmVzaWRlbnRzIGFyZSB3ZWFsdGh5IG9yIG5vdC4gOykNCg0K aHR0cDovL21hcHMuZ29vZ2xlLmNvbS9tYXBzP3E9NDkuNDA1ODM5LDguNjg0NTgyJm51bT0xJnQ9 aCZzbGw9NDkuNDA5OTg4LDguNjk5OTI1JnNzcG49MC4wMDYyOTUsMC4wMDYyOTUmaWU9VVRGOCZs bD00OS40MDYxMjksOC42ODU4MDgmc3BuPTAuMDA2ODI4LDAuMDEyNzQ2Jno9MTYmaXdsb2M9QQ0K DQpZb3UgbWF5IGFsc28gZ2V0IG11Y2ggYmV0dGVyIGRhdGEgaWYgeW91IGdldCBhY2Nlc3MgdG8g c29tZSBjb25zdW1lciByYXRpbmcgYWdlbmN5J3MgZGF0YWJhc2UuIEF0IGxlYXN0IGluIEdlcm1h bnkgdGhleSBjYW4gdGVsbCBpbiBtb3N0IGFyZWFzIGhvdXNlIGJ5IGhvdXNlIHRoZSBpbmNvbWUg dG8gYmUgZXhwZWN0ZWQuIFVzZWQgYnkgZGlyZWN0IG1hcmtldGluZy4uLg0KDQpJIHNlZSB0aGUg cG9pbnQgeW91IGFyZSBtYWtpbmcsIGJ1dCBJIHdvdWxkIG9wdCBmb3IgaW5jbHVkaW5nIHRoZSBw b3NzaWJpbGl0eSB0byBxdWVyeSB0byBwcm92aXNpb25lZCBiYW5kd2lkdGggaW4gdGhlIEFMVE8g cHJvdG9jb2wsIGJ1dCBsZWF2ZSBpdCB0byB0aGUgZGlzY3JldGlvbiBvZiB0aGUgSVNQIGRlcGxv eWluZyB0aGUgc2VydmljZSB0byBlbmFibGUgdGhpcyBvciBub3QuIEluY2x1ZGluZyBkb2N1bWVu dGluZyB0aGUgcHJpdmFjeSByaXNrcyBpZiBlbmFibGVkLiANCg0KTXkgdXNlIGNhc2UgZm9yIHRo aXM6DQpUaGUgcHJvdmlzaW9uZWQgYmFuZHdpZHRoIG1heSBiZSB1c2VkIGJ5IHAycCBzdHJlYW1p bmcgc3lzdGVtcyB0byBydWxlIG91dCBwZWVycyB0aGF0IHdpbGwgYW55d2F5IG5vdCBoZWxwIGlu IHN0cmVhbWluZyAoZS5nLiwgYW4gcGVlciB3aXRoIDEyOGtiaXQvcyB1cGxpbmsgaW50ZW5kZWQg dG8gc2VydmUgZnVsbCBIRFRWIHN0cmVhbXMpLg0KDQo+IA0KPiAzLiBUaGUgc3Vic2NyaWJlciBt YXkgbm90IGludGVuZCB0byB1c2UgKmFsbCogcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGZvcg0KPiBh IHBhcnRpY3VsYXIgYXBwbGljYXRpb24gKGUuZy4gUDJQKS4gRm9yIGV4YW1wbGUsIHBlcmhhcHMg dGhlDQo+IHN1YnNjcmliZXIgaW50ZW5kcyB0byB1c2UgcHJvdmlzaW9uZWQgdXBsaW5rIGJhbmR3 aWR0aCBmb3INCj4gdGVsZWNvbW11dGluZywgdGVsZXByZXNlbmNlLCBvbmxpbmUgc3RvcmFnZSBi YWNrdXBzLCBldGMuIEEgdGhpcmQgcGFydHkNCj4gY29uc3VtaW5nIEFMVE8gcHJvdmlzaW9uZWQg YmFuZHdpZHRoIGluZm9ybWF0aW9uIHNob3VsZCBiZSBhd2FyZSB0aGF0DQo+IHRoZSBzdWJzY3Jp YmVyJ3MgcHJvdmlzaW9uZWQgYmFuZHdpZHRoIG1heSBiZSByZXNlcnZlZCBmb3IgZGlmZmVyZW50 DQo+IGFwcGxpY2F0aW9ucy4NCg0KVHJ1ZSwgdGhpcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBhcyBh biBpc3N1ZSwgYnV0IGFzIHNhaWQgYWJvdmUgdGhpcyBpcyBoZWxwZnVsIGluIHJ1bGluZyBvdXQg cGVlcnMgYW55d2F5IG5vdCB1c2VmdWwuIFNlY29uZCwgdGhlIGFjdHVhbCB1c2FibGUgYmFuZHdp ZHRoIG5lZWRzIHRvIGJlIHRlc3RlZCBpbiB0aGUgZm9sbG93aW5nIG9wZXJhdGlvbmFsIHN0ZXBz IG9mIHRoZSBwMnAgc3lzdGVtIGFueXdheS4gDQoNCj4gDQo+IEhlcmUgYXJlIG15IHRob3VnaHRz IG9uIGR5bmFtaWMgYWRkcmVzcyByZS1hbGxvY2F0aW9uLg0KPiANCj4gSVNQcyByZWFsbG9jYXRl IElQdjQgc3VibmV0cyB3aXRoaW4gdGhlaXIgaW5mcmFzdHJ1Y3R1cmUgZnJvbSB0aW1lIHRvDQo+ IHRpbWUsIHBhcnRseSB0byBlbnN1cmUgdGhlIGVmZmljaWVudCB1c2FnZSBvZiBJUHY0IGFkZHJl c3NlcyAoYSBzY2FyY2UNCj4gcmVzb3VyY2UpLCBhbmQgcGFydGx5IHRvIGVuYWJsZSBlZmZpY2ll bnQgcm91dGUgdGFibGVzIHdpdGhpbiB0aGVpcg0KPiBuZXR3b3JrIHJvdXRlcnMuIFRoZSBmcmVx dWVuY3kgb2YgdGhlc2UgInJlbnVtYmVyaW5nIGV2ZW50cyIgZGVwZW5kIG9uDQo+IHRoZSBncm93 dGggaW4gbnVtYmVyIG9mIHN1YnNjcmliZXJzIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9mIGFkZHJl c3MNCj4gc3BhY2Ugd2l0aGluIHRoZSBJU1AuIEFzIGEgcmVzdWx0LCBhIHN1YnNjcmliZXIncyBo b3VzZWhvbGQgZGV2aWNlDQo+IGNvdWxkIHJldGFpbiBhbiBJUHY0IGFkZHJlc3MgZm9yIGFzIHNo b3J0IGFzIGEgZmV3IG1pbnV0ZXMsIG9yIGZvcg0KPiBtb250aHMgYXQgYSB0aW1lIG9yIGV2ZW4g bG9uZ2VyLg0KPiANCj4gU29tZSBmb2xrcyBoYXZlIHN1Z2dlc3RlZCB0aGF0IElTUHMgcHJvdmlk aW5nIEFMVE8gc2VydmljZXMgY291bGQgc3ViLQ0KPiBkaXZpZGUgdGhlaXIgc3Vic2NyaWJlcnMn IGRldmljZXMgaW50byBkaWZmZXJlbnQgSVB2NCBzdWJuZXRzIChvcg0KPiBjZXJ0YWluIElQdjQg YWRkcmVzcyByYW5nZXMpIGJhc2VkIG9uIHRoZSBwdXJjaGFzZWQgc2VydmljZSB0aWVyLCBhcw0K PiB3ZWxsIGFzIGJhc2VkIG9uIHRoZSBsb2NhdGlvbiBpbiB0aGUgbmV0d29yayB0b3BvbG9neS4g VGhlIHByb2JsZW0gaXMNCj4gdGhhdCB0aGlzIHN1Yi1hbGxvY2F0aW9uIG9mIElQdjQgc3VibmV0 cyB0ZW5kcyB0byBkZWNyZWFzZSB0aGUNCj4gZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3MgYWxs b2NhdGlvbi4gQSBncm93aW5nIElTUCB0aGF0IG5lZWRzIHRvDQo+IG1haW50YWluIGhpZ2ggZWZm aWNpZW5jeSBvZiBJUHY0IGFkZHJlc3MgdXRpbGl6YXRpb24gbWF5IGJlIHJlbHVjdGFudA0KPiB0 byBqZW9wYXJkaXplIHRoZWlyIGZ1dHVyZSBhY3F1aXNpdGlvbiBvZiBJUHY0IGFkZHJlc3Mgc3Bh Y2UuDQo+IA0KPiBUaGVyZWZvcmUsIGNvbnN1bWVycyBvZiBwZXItdXNlciBBTFRPIGluZm9ybWF0 aW9uIHNob3VsZCBhc3N1bWUgdGhhdA0KPiBzdWJzY3JpYmVycyByZXRhaW4gSVB2NCBhZGRyZXNz ZXMgZm9yIG9ubHkgYSByZWxhdGl2ZWx5IHNob3J0IHBlcmlvZCBvZg0KPiB0aW1lLCBlLmcuIG1p bnV0ZXMsIGFuZCB0aGF0IHN1YnNjcmliZXJzIG9mIGRpZmZlcmVudCBzZXJ2aWNlIHRpZXJzDQo+ IHdpbGwgY28tZXhpc3QgaW4gc29tZSBJU1AncyBJUHY0IHN1Ym5ldHMuDQoNCkkgd2lsbCByZXBs eSB0byB0aGlzIGluIGEgc2VwYXJhdGUgZW1haWwuDQoNClRoYW5rcywNCg0KICBNYXJ0aW4NCg0K DQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3Bl IC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbg0KTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0 ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMIHwg UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCg== From Martin.Stiemerling@neclab.eu Thu Mar 18 04:17:35 2010 Return-Path: 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 90C903A6901 for ; Thu, 18 Mar 2010 04:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 SnN53xio3h2W for ; Thu, 18 Mar 2010 04:17:34 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 54D9D3A68DB for ; Thu, 18 Mar 2010 04:17:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 785602C0204F9; Thu, 18 Mar 2010 12:17:45 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrQS4-1dqUtf; Thu, 18 Mar 2010 12:17:45 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 5A2AB2C017B2E; Thu, 18 Mar 2010 12:17:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 18 Mar 2010 12:17:34 +0100 Message-ID: <547F018265F92642B577B986577D671C012A301B@VENUS.office> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2QAAcZlXA= References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> From: "Martin Stiemerling" To: "Woundy, Richard" , Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 11:17:35 -0000 UmljaCwNCg0KSGVyZSBJIGdvIHdpdGggbXkgY29tbWVudHMgb24gdGhlIGR5bmFtaWMgSVAgYWRk cmVzcyByZS1hbGxvY2F0aW9uLg0KDQpJIGNvbW1lbnRlZCBvbiB0aGlzIGR1cmluZyB0aGUgSUVU Ri03NiBvbiAodGFrZW4gZnJvbSB0aGUgbWludXRlcykNCk1hcnRpbjogaG93IHN0YXRpYyBpcyBh IG5ldHdvcmsgbWFwIGluIHJlYWxpdHk/DQphbmQgYWxzbyBieSBlbWFpbDoNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hbHRvL2N1cnJlbnQvbXNnMDA1MTkuaHRtbA0KDQpN eSBwb2ludCB3YXMgdGhhdCB0aGUgcHJvcG9zZWQgbmV0d29yayBtYXAvY29zdCBtYXAgaW4gdGhl IEFMVE8gcHJvdG9jb2wgd291bGQgYmUgbGVzcyBiZW5lZmljaWFsbHksIGlmIHRoZSBJU1AgYXJl IGV4YWN0bHkgZG9pbmcgd2hhdCB5b3UgaGF2ZSBkZXNjcmliZWQgYW5kIHdoYXQgSSBoYXZlIGNv bW1lbnRlZCBvbiBkdXJpbmcgdGhlIGxhc3QgSUVURi4gDQoNCkhvd2V2ZXIsIEkndmUgaGFkIHRo ZSBpbXByZXNzaW9uIHRoYXQgbW9zdCBwZW9wbGUgaW4gdGhlIHJvb20gZGlkbid0IGFncmVlIHRv IHRoaXMgdmlldzoNCg0KVGhlIG5ldHdvcmsgbWFwcyAoYW5kIHRoZSBhc3NvY2lhdGVkIGNvc3Qg bWFwKSBpcyBmaW5lIGFzIGxvbmcgYXMgdGhlIElQIHByZWZpeCBhbGxvY2F0aW9uIGluIGFuIElT UCdzIG5ldHdvcmsgaXMgc3RhYmxlLiBXaGVyZSBzdGFibGUgbWVhbnMgY2hhbmdlcyBvZiB0aGUg SVAgcHJlZml4IGFsbG9jYXRpb24gYXJlIGhhcHBlbmluZyBpbiB0aGUgcmFuZ2Ugb2Ygd2Vla3Mu IA0KDQpOb3cgdGhlIGNhdmVhdHMgb2YgbmV0d29yayBtYXBzOg0KSXQgaXMgdXAgdG8gdGhlIElT UCB0byBjaGFuZ2UgdGhlIElQIHByZWZpeCBhbGxvY2F0aW9uIGluIGl0cyBvd24gbmV0d29yayBh dCBhbnl0aW1lLiBJbmNsdWRpbmcgdXNpbmcgc29tZSBkeW5hbWljIHJlLWFsbG9jYXRpb24gc2No ZW1lcywgZm9yIGluc3RhbmNlLCBzdXBwb3J0ZWQgYnkgdXNpbmcgQ2lzY28ncyBPREFQIGZlYXR1 cmUsIGJ1dCBhbHNvIHNodWZmbGluZyB0aGVtIG1hbnVhbGx5LiBJZiBub3csIGEgZHluYW1pYyBy ZWFsbG9jYXRpb24gc2NoZW1lIGlzIHVzZWQgKGFuZCBJIGd1ZXNzIHNvbWUgSVNQIHdpbGwgbmVl ZCB0byBkbyB0aGlzIHNvb24sIGFzIHRoZXJlIG5vdCB0b28gbWFueSBmcmVlIElTUCBwcmVmaXgg YmxvY2tzIGxlZnQpLCB0aGUgbmV0d29yayBtYXBzIGhhdmUgdG8gYmUgdXBkYXRlZCBpbiBtdWNo IHNob3J0ZXIgdGltZSBmcmFtZSB0aGFuIGFjdHVhbGx5IGVudmlzaW9uZWQgYnkgdGhlIEFMVE8g cHJvdG9jb2wuDQoNClRoaXMgdGFrZXMgYXdheSB0aGUgYWR2YW50YWdlIG9mIGhhdmluZyBuZXR3 b3JrIG1hcHMgYW5kIHdvdWxkIGNsZWFybHkgYXJndWUgZm9yIGVuaGFuY2VkIG9yYWNsZSBhcHBy b2FjaC4NCg0KDQpDb21pbmcgbm93IHRvIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhbmQgZHluYW1p YyBJUCBhZGRyZXNzIHJlLWFsbG9jYXRpb246DQpJIGRvbid0IHNlZSBhIHBhcnRpY3VsYXIgcmVh c29uIHdoeSB0aGUgaW5mb3JtYXRpb24gZ2FpbmVkIGZyb20gcHJvdmlzaW9uZWQgYmFuZHdpZHRo IGlzIG5vdCBzdWJqZWN0IHRvIHRoZSBzYW1lIHJ1bGVzIGFzIHRvcG9sb2d5IGluZm9ybWF0aW9u IGRlbGl2ZXJlZCBmb3IgYSBwZWVyJ3MgSVAgYWRkcmVzcy4NCg0KQm90aCBhcmUgc3ViamVjdCB0 byBjaGFuZ2UgYW5kIGhhdmUgbW9yZSBsZXNzIG9ubHkgYSBnb29kIG1lYW5pbmcgYXQgdGhlIHRp bWUgb2YgdGhlIHF1ZXJ5LiBXaXRoIHRpbWUgZXZvbHZpbmcsIHRoZSBpbmZvcm1hdGlvbiB3aGVy ZSBhIHBlZXIgaXMgdG9wb2xvZ3kgd2lzZSBjbG9zZSBvciBpZiB0aGUgcGVlciBoYXMgYSBwYXJ0 aWN1bGFyIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCB3aWxsIGFueWhvdyBjaGFuZ2UgKGUuZy4sIGhv bWUgZ2F0ZXdheSBvciBjYWJsZSBtb2RlbSBpcyByZWJvb3RpbmcsIGNhdXNpbmcgdG8gZ2V0IGEg bmV3IElQIGFkZHJlc3MgYXNzaWduZWQgYW5kIHRoZSBvbGQgb25lIGJlaW5nIHJlLWFzc2lnbmVk IHRvIHNvbWUgb3RoZXIgY3VzdG9tZXIgYWNjZXNzIGxpbmUpLg0KDQpUaGFua3MsDQoNCiAgTWFy dGluDQoNCj4gDQo+IEhlcmUgYXJlIG15IHRob3VnaHRzIG9uIGR5bmFtaWMgYWRkcmVzcyByZS1h bGxvY2F0aW9uLg0KPiANCj4gSVNQcyByZWFsbG9jYXRlIElQdjQgc3VibmV0cyB3aXRoaW4gdGhl aXIgaW5mcmFzdHJ1Y3R1cmUgZnJvbSB0aW1lIHRvDQo+IHRpbWUsIHBhcnRseSB0byBlbnN1cmUg dGhlIGVmZmljaWVudCB1c2FnZSBvZiBJUHY0IGFkZHJlc3NlcyAoYSBzY2FyY2UNCj4gcmVzb3Vy Y2UpLCBhbmQgcGFydGx5IHRvIGVuYWJsZSBlZmZpY2llbnQgcm91dGUgdGFibGVzIHdpdGhpbiB0 aGVpcg0KPiBuZXR3b3JrIHJvdXRlcnMuIFRoZSBmcmVxdWVuY3kgb2YgdGhlc2UgInJlbnVtYmVy aW5nIGV2ZW50cyIgZGVwZW5kIG9uDQo+IHRoZSBncm93dGggaW4gbnVtYmVyIG9mIHN1YnNjcmli ZXJzIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9mIGFkZHJlc3MNCj4gc3BhY2Ugd2l0aGluIHRoZSBJ U1AuIEFzIGEgcmVzdWx0LCBhIHN1YnNjcmliZXIncyBob3VzZWhvbGQgZGV2aWNlDQo+IGNvdWxk IHJldGFpbiBhbiBJUHY0IGFkZHJlc3MgZm9yIGFzIHNob3J0IGFzIGEgZmV3IG1pbnV0ZXMsIG9y IGZvcg0KPiBtb250aHMgYXQgYSB0aW1lIG9yIGV2ZW4gbG9uZ2VyLg0KPiANCj4gU29tZSBmb2xr cyBoYXZlIHN1Z2dlc3RlZCB0aGF0IElTUHMgcHJvdmlkaW5nIEFMVE8gc2VydmljZXMgY291bGQg c3ViLQ0KPiBkaXZpZGUgdGhlaXIgc3Vic2NyaWJlcnMnIGRldmljZXMgaW50byBkaWZmZXJlbnQg SVB2NCBzdWJuZXRzIChvcg0KPiBjZXJ0YWluIElQdjQgYWRkcmVzcyByYW5nZXMpIGJhc2VkIG9u IHRoZSBwdXJjaGFzZWQgc2VydmljZSB0aWVyLCBhcw0KPiB3ZWxsIGFzIGJhc2VkIG9uIHRoZSBs b2NhdGlvbiBpbiB0aGUgbmV0d29yayB0b3BvbG9neS4gVGhlIHByb2JsZW0gaXMNCj4gdGhhdCB0 aGlzIHN1Yi1hbGxvY2F0aW9uIG9mIElQdjQgc3VibmV0cyB0ZW5kcyB0byBkZWNyZWFzZSB0aGUN Cj4gZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3MgYWxsb2NhdGlvbi4gQSBncm93aW5nIElTUCB0 aGF0IG5lZWRzIHRvDQo+IG1haW50YWluIGhpZ2ggZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3Mg dXRpbGl6YXRpb24gbWF5IGJlIHJlbHVjdGFudA0KPiB0byBqZW9wYXJkaXplIHRoZWlyIGZ1dHVy ZSBhY3F1aXNpdGlvbiBvZiBJUHY0IGFkZHJlc3Mgc3BhY2UuDQo+IA0KPiBUaGVyZWZvcmUsIGNv bnN1bWVycyBvZiBwZXItdXNlciBBTFRPIGluZm9ybWF0aW9uIHNob3VsZCBhc3N1bWUgdGhhdA0K PiBzdWJzY3JpYmVycyByZXRhaW4gSVB2NCBhZGRyZXNzZXMgZm9yIG9ubHkgYSByZWxhdGl2ZWx5 IHNob3J0IHBlcmlvZCBvZg0KPiB0aW1lLCBlLmcuIG1pbnV0ZXMsIGFuZCB0aGF0IHN1YnNjcmli ZXJzIG9mIGRpZmZlcmVudCBzZXJ2aWNlIHRpZXJzDQo+IHdpbGwgY28tZXhpc3QgaW4gc29tZSBJ U1AncyBJUHY0IHN1Ym5ldHMuDQo+IA0KPiAtLSBSaWNoDQoNCm1hcnRpbi5zdGllbWVybGluZ0Bu ZWNsYWIuZXUNCg0KTkVDIExhYm9yYXRvcmllcyBFdXJvcGUgLSBOZXR3b3JrIFJlc2VhcmNoIERp dmlzaW9uDQpORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNl LCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQg MjgzMjAxNA0K From Martin.Stiemerling@neclab.eu Thu Mar 18 04:29:18 2010 Return-Path: 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 14E823A6828 for ; Thu, 18 Mar 2010 04:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 eNpdzxhuuD6m for ; Thu, 18 Mar 2010 04:29:17 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2948B3A680C for ; Thu, 18 Mar 2010 04:29:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 51F4D2C0204FC for ; Thu, 18 Mar 2010 12:29:28 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy9MFSiJjr4j for ; Thu, 18 Mar 2010 12:29:28 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 330362C0204F9 for ; Thu, 18 Mar 2010 12:29:23 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {87789D38-94D0-40FB-9271-58906BF44795} x-cr-hashedpuzzle: DIPf DXiA DrBO EOwc EQoB Fliz F9tY GKrI Gxft HEGo HMJ1 HNaI HY6p H1uL JA7k Jn4N; 1; YQBsAHQAbwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {87789D38-94D0-40FB-9271-58906BF44795}; bQBhAHIAdABpAG4ALgBzAHQAaQBlAG0AZQByAGwAaQBuAGcAQABuAGUAYwBsAGEAYgAuAGUAdQA=; Thu, 18 Mar 2010 11:29:18 GMT; RQByAHIAbwByACAAaABhAG4AZABsAGkAbgBnACAAaQBuACAAdABoAGUAIABBAEwAVABPACAAcAByAG8AdABvAGMAbwBsACAAKAAtADAAMwApAA== Content-class: urn:content-classes:message Date: Thu, 18 Mar 2010 12:29:18 +0100 Message-ID: <547F018265F92642B577B986577D671C012A301F@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error handling in the ALTO protocol (-03) Thread-Index: AcrGjj+EuqGXx59iTeWAsLMUBTt0fg== From: "Martin Stiemerling" To: Subject: [alto] Error handling in the ALTO protocol (-03) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 11:29:18 -0000 Hi all, While reading draft-ietf-alto-protocol-03 is stumbled over the error = handling.=20 It seems that the error handling of ALTO relies on the http error codes, = but does not provide its own error code or proceed.=20 I see this a shortcoming of the current design and also as not = favourably. This mixes transport related error messages (e.g., 404 not found, i.e., = the general alto resource your asking for isn't here) and errors related = the actual ALTO handling (e.g., asking guidance for private or reserved = IP addresses that cannot be rated by ALTO, syntax errors, or not = understood objects).=20 My proposal: - separate both levels clearly - define an error object for cases where no or only a partial answer can = be given - define that the server can deliver some information he has understood = (e.g., some IP addresses) within the given semantics, as defined in the = draft as is.=20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Martin.Stiemerling@neclab.eu Thu Mar 18 04:39:16 2010 Return-Path: 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 B31523A6AE7 for ; Thu, 18 Mar 2010 04:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 QQiD5e9Xne+n for ; Thu, 18 Mar 2010 04:39:15 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5454D3A680E for ; Thu, 18 Mar 2010 04:39:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7D3DB2C01D47A; Thu, 18 Mar 2010 12:39:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BbcyftzxQi3; Thu, 18 Mar 2010 12:39:26 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 61D892C000352; Thu, 18 Mar 2010 12:39:16 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 18 Mar 2010 12:39:15 +0100 Message-ID: <547F018265F92642B577B986577D671C012A3023@VENUS.office> In-reply-to: <201003111729.33544.richard.alimi@yale.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] #1: Message format Thread-Index: AcrBamanNqnihdYGQUq5p/7QJLE5cQFJIH/w References: <201003111729.33544.richard.alimi@yale.edu> From: "Martin Stiemerling" To: "Richard Alimi" Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 11:39:16 -0000 Rich,=20 a few comments inline: > -----Original Message----- > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf = Of > Richard Alimi > Sent: Thursday, March 11, 2010 11:30 PM > To: Jason Livingood > Cc: alto@ietf.org > Subject: Re: [alto] #1: Message format >=20 > Hi Jason, >=20 > Thank you very much for taking a look. Please see below: >=20 > On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > > You may want to make some of these tracker notes more verbose. >=20 > At this point, since this is a first stab at fully specifying protocol > details, my personal feeling is that we are still wide-open for > discussion on > the whole document. However, there on a few points that I think are > particular > important for this go-around: >=20 > - IPv4/IPv6 needs much more thought before integrating it into > the document. In particular, what are the right semantics for > handling IPv4 > and IPv6 with respect to indicating provider preferences? (Some > initial > questions are noted on Issue #9 for this)? A simple turn on this: limit a single query-object to an IP address = family. However, a query to the server can include multiple = query-objects, i.e., one each for an IP address family or whatever = identifier comes up later on (e.g. HIP IDs ;) >=20 > - With regard to messaging (including usage of HTTP URIs and the = actual > body > encodings), can people think of issues that might cause problems for > deployment in an operational network (e.g., load-balancing > configuration)? > Difficult or non-intuitive implementation (both server-side and > client-side)? Are there any ambiguities you can see? > I thinking through the current protocol details we have tried to > address > these, but input from others would be extremely helpful. I'm still browsing through this and how JSON works.=20 >=20 > - For Redistribution, this is a capability that seemed to get = favorable > feedback at IETF76. The current implementation uses HTTP > headers/trailers to > send the signatures, and a certificate is encoded in the Server > Capability > response. The idea is that an ALTO Client can locally cache the > certificate > and only contact the ALTO Server very infrequently even if it is > gathering > ALTO information (i.e., ALTOResponse structs) from other ALTO = Clients > instead of the ALTO Server itself. For this part, what do people > think about > how such redistribution information is encoded in the protocol? Is > there a > clean way to do this without requiring custom HTTP headers/trailers? > Does > the spec sufficiently convey when redistribution should or should = not > be > used? I'm not sure that the spec is doing good in this respect. The emphasize = is on the security (i.e., using certificates), but an important point is = missing. The server should state in what area (i.e., IP prefix) this = information is allowed to be distributed.=20 See draft-kiesel-alto-h12-02 under redistribution: The response contains also a resource consumer host location attribute (rc_hla). This rc_hla echos partially the information from the request, but gives actually guidance to the ALTO client in what scope this information can be distributed amongst other peers. In this response, the server allows the redistribution of the received guidance to peers with the IP prefix 195.37.0.0/16. > As mentioned above, I would think that comments about the entire > document are > very useful, but the major changes in these couple of revisions have > been to > sections 6, 7, and 11 (so feel free to focus there). I'm still reading... =20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 From richard_woundy@cable.comcast.com Thu Mar 18 05:48:07 2010 Return-Path: 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 797E83A69C6 for ; Thu, 18 Mar 2010 05:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.041 X-Spam-Level: X-Spam-Status: No, score=0.041 tagged_above=-999 required=5 tests=[AWL=-3.226, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 cOGEhLRMN4aE for ; Thu, 18 Mar 2010 05:48:06 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 334DD3A69AD for ; Thu, 18 Mar 2010 05:48:05 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78780312; Thu, 18 Mar 2010 08:47:59 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 08:48:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 08:47:37 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2QAAXOucAABxMQCg== From: "Woundy, Richard" To: , X-OriginalArrivalTime: 18 Mar 2010 12:48:00.0619 (UTC) FILETIME=[3E0373B0:01CAC699] Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 12:48:07 -0000 PldoeSBzaG91bGQgSSB3YWl0IGZvciBBTFRPIGlmIEkgY2FuIGRvIHRoaXMgd2l0aCByZWFzb25h YmxlIGVmZm9ydCBieSB0b2RheSB3aXRoIHRvZGF5J3MgbWVhbnM/DQoNCkl0IGlzIHRydWUgdGhh dCB5b3UgY2FuIHVzZSBhIGdlby1JUCBtYXBwaW5nIGRhdGFiYXNlIHRvIGd1ZXNzIHRoZSByb3Vn aCBsb2NhdGlvbiBvZiBhIHVzZXIuIEJ1dCBJIGhhdmUgZm91bmQgKGJ5IGxvb2tpbmcgYXQgYWRz IHNlcnZlZCB0byBtZSkgdGhhdCBzb21ldGltZXMgdGhlIGRhdGFiYXNlIGlzIG9mZiBieSBhIG11 bmljaXBhbGl0eSBvciB0d28uDQoNCk15IHBvaW50IGlzLCB0aGlzIHBhcmFtZXRlciAqbWlnaHQq IGhlbHAgYSB0aGlyZCBwYXJ0eSBmaWd1cmUgb3V0IHdobyBoYXMgdGhlIGhpZ2hlc3QgZGlzcG9z YWJsZSBpbmNvbWUgd2l0aGluIGEgcGFydGljdWxhciBuZWlnaGJvcmhvb2QuDQoNCj5Zb3UgbWF5 IGFsc28gZ2V0IG11Y2ggYmV0dGVyIGRhdGEgaWYgeW91IGdldCBhY2Nlc3MgdG8gc29tZSBjb25z dW1lciByYXRpbmcgYWdlbmN5J3MgZGF0YWJhc2UuDQoNCkFzIGEgdGhpcmQgcGFydHkgKG5vdCB0 aGUgdXNlciBvciBJU1ApLCBob3cgd291bGQgeW91IG1ha2UgdXNlIG9mIHRoYXQgZGF0YWJhc2U/ IFdvdWxkbid0IGl0IGJlIGluZGV4ZWQgYnkgbmFtZS9wZXJzb25hbCBpZGVudGl0eSBhbmQvb3Ig aG9tZSBhZGRyZXNzPyBUaGF0IGluZm9ybWF0aW9uIHNlZW1zIHRvIGJlIG91dHNpZGUgdGhlIGNv bnRleHQgb2YgcmVndWxhciBJbnRlcm5ldCB0cmFmZmljIG9yIEFMVE8gLSBleGNlcHQgZm9yIHBo aXNoaW5nIHNjYW1zIGFuZCBuYcOvdmUgdXNlcnMuIDooDQoNCj5JIHNlZSB0aGUgcG9pbnQgeW91 IGFyZSBtYWtpbmcsIGJ1dCBJIHdvdWxkIG9wdCBmb3IgaW5jbHVkaW5nIHRoZSBwb3NzaWJpbGl0 eSB0byBxdWVyeSB0byBwcm92aXNpb25lZCBiYW5kd2lkdGggaW4gdGhlIEFMVE8gcHJvdG9jb2ws IGJ1dCBsZWF2ZSBpdCB0byB0aGUgZGlzY3JldGlvbiBvZiB0aGUgSVNQIGRlcGxveWluZyB0aGUg c2VydmljZSB0byBlbmFibGUgdGhpcyBvciBub3QuIEluY2x1ZGluZyBkb2N1bWVudGluZyB0aGUg cHJpdmFjeSByaXNrcyBpZiBlbmFibGVkLg0KDQpJIGFncmVlIHdpdGggeW91IGhlcmU6IHRoYXQg aXMsIGFsbG93IHByb3Zpc2lvbmVkIGJhbmR3aWR0aCwgbWFrZSBpdCBvcHRpb25hbCwgYW5kIGRv Y3VtZW50IHRoZSBwcml2YWN5IHJpc2tzLg0KDQpJIHVuZGVyc3RhbmQgeW91ciB1c2UgY2FzZSBh cyB3ZWxsLg0KDQotLSBSaWNoDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJv bTogTWFydGluIFN0aWVtZXJsaW5nIDxNYXJ0aW4uU3RpZW1lcmxpbmdAbmVjbGFiLmV1Pg0KVG86 IFdvdW5keSwgUmljaGFyZDsgYWx0b0BpZXRmLm9yZyA8YWx0b0BpZXRmLm9yZz4NClNlbnQ6IFRo dSBNYXIgMTggMDY6MDE6NDUgMjAxMA0KU3ViamVjdDogUkU6IFthbHRvXSBDb21tZW50cyBvbiBw cm92aXNpb25lZCBiYW5kd2lkdGggYW5kIEFMVE8NCg0KSGkgUmljaCwgDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhbHRvLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzphbHRvLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBXb3VuZHksIFJpY2hhcmQN Cj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDE4LCAyMDEwIDc6NDIgQU0NCj4gVG86IGFsdG9AaWV0 Zi5vcmcNCj4gU3ViamVjdDogW2FsdG9dIENvbW1lbnRzIG9uIHByb3Zpc2lvbmVkIGJhbmR3aWR0 aCBhbmQgQUxUTw0KPiANCj4gRm9sa3MsDQo+IA0KPiBJIGhhZCBwcm92aWRlZCBzb21lIG9mZmxp bmUgY29tbWVudHMgYWJvdXQgdGhlIGluY2x1c2lvbiBvZiBwcm92aXNpb25lZA0KPiBiYW5kd2lk dGggaW4gQUxUTy4gRW5yaWNvIGFza2VkIG1lIHRvIHJlLXNlbmQgdGhlbSB0byB0aGUgbWFpbGlu ZyBsaXN0Lg0KPiBJIGNhbiBhbHNvIGRpc2N1c3MgaW4gbmV4dCB3ZWVrJ3MgQUxUTyBzZXNzaW9u Lg0KPiANCj4gSGVyZSBhcmUgbXkgcHJpdmFjeSBjb25jZXJucy4NCj4gDQo+IDEuIERlcGVuZGlu ZyBvbiB0aGUgSVNQJ3MgcHJpY2luZyBhbmQgcm9sbG91dCBvZiBiYW5kd2lkdGggdGllcnMsIHRo ZXJlDQo+IG1heSBiZSByZWxhdGl2ZWx5IGZldyBzdWJzY3JpYmVycyB3aXRoaW4gYSBwYXJ0aWN1 bGFyIHRpZXIuIFRoZXJlZm9yZSBhDQo+IHRoaXJkIHBhcnR5IGNvbnN1bWluZyBBTFRPIHByb3Zp c2lvbmVkIGJhbmR3aWR0aCBpbmZvcm1hdGlvbiBjYW4gbWFrZSBhDQo+IGdvb2QgZ3Vlc3MgYWJv dXQgdGhlIGlkZW50aXR5IG9mIGEgc3Vic2NyaWJlciB3aXRoaW4gYSAicmFyZWx5IHVzZWQiDQo+ IGJhbmR3aWR0aCB0aWVyLg0KPiANCj4gMi4gU2VwYXJhdGVseSwgYSB0aGlyZCBwYXJ0eSBjb25z dW1pbmcgQUxUTyBwcm92aXNpb25lZCBiYW5kd2lkdGgNCj4gaW5mb3JtYXRpb24gbWF5IGJlIGFi bGUgdG8gbWFrZSBhbiBpbmZvcm1lZCBndWVzcyBhYm91dCB0aGUgZWNvbm9taWMNCj4gc3RhdHVz IG9mIGEgc3Vic2NyaWJlciBiYXNlZCBvbiB0aGUgYmFuZHdpZHRoIHRpZXIsIHdoaWNoIG1heSBu b3QgYmUNCj4gZGVzaXJhYmxlIHRvIHRoZSBzdWJzY3JpYmVyLg0KDQpXaHkgc2hvdWxkIEkgd2Fp dCBmb3IgQUxUTyBpZiBJIGNhbiBkbyB0aGlzIHdpdGggcmVhc29uYWJsZSBlZmZvcnQgYnkgdG9k YXkgd2l0aCB0b2RheSdzIG1lYW5zPw0KDQpZb3UgY2FuIHVzZSB0aGUgZ2VvIGluZm9ybWF0aW9u IHByb3ZpZGVkIGZvciBhIHBhcnRpY3VsYXIgSVAgYWRkcmVzcyBvdXQgb2YgdGhlIHdob2lzIGFu ZCBjb21iaW5lIHRoaXMgd2l0aCBzb21lIG90aGVyIGF2YWlsYWJsZSBkYXRhIChnb29nbGUgbWFw cy9zdHJlZXQgdmlldykgdG8gc2VlIGlmIHBlb3BsZSBhcmUgbGl2aW5nIGluIHdlYWx0aHkgYXJl YSBvciBub3QuIFRyeSB0aGlzIHdpdGggdGhlIElQIGFkZHJlc3NlcyBpbmRpY2F0ZWQgZm9yIHRo aXMgZW1haWwgYXMgc210cCBzZW5kZXIuLi4oIDE5NS4zNy43MC40MSkuIFVuZm9ydHVuYXRlbHks IHRoZXJlIGlzIG5vIHN0cmVldCB2aWV3IGZvciB0aGlzIGxvY2F0aW9uLCBidXQgaW4gb3RoZXIg cGxhY2VzIHRoaXMgd2lsbCBoZWxwIGV2ZW4gYmV0dGVyIHRvIGRldGVybWluZSBpZiB0aGUgcmVz aWRlbnRzIGFyZSB3ZWFsdGh5IG9yIG5vdC4gOykNCg0KaHR0cDovL21hcHMuZ29vZ2xlLmNvbS9t YXBzP3E9NDkuNDA1ODM5LDguNjg0NTgyJm51bT0xJnQ9aCZzbGw9NDkuNDA5OTg4LDguNjk5OTI1 JnNzcG49MC4wMDYyOTUsMC4wMDYyOTUmaWU9VVRGOCZsbD00OS40MDYxMjksOC42ODU4MDgmc3Bu PTAuMDA2ODI4LDAuMDEyNzQ2Jno9MTYmaXdsb2M9QQ0KDQpZb3UgbWF5IGFsc28gZ2V0IG11Y2gg YmV0dGVyIGRhdGEgaWYgeW91IGdldCBhY2Nlc3MgdG8gc29tZSBjb25zdW1lciByYXRpbmcgYWdl bmN5J3MgZGF0YWJhc2UuIEF0IGxlYXN0IGluIEdlcm1hbnkgdGhleSBjYW4gdGVsbCBpbiBtb3N0 IGFyZWFzIGhvdXNlIGJ5IGhvdXNlIHRoZSBpbmNvbWUgdG8gYmUgZXhwZWN0ZWQuIFVzZWQgYnkg ZGlyZWN0IG1hcmtldGluZy4uLg0KDQpJIHNlZSB0aGUgcG9pbnQgeW91IGFyZSBtYWtpbmcsIGJ1 dCBJIHdvdWxkIG9wdCBmb3IgaW5jbHVkaW5nIHRoZSBwb3NzaWJpbGl0eSB0byBxdWVyeSB0byBw cm92aXNpb25lZCBiYW5kd2lkdGggaW4gdGhlIEFMVE8gcHJvdG9jb2wsIGJ1dCBsZWF2ZSBpdCB0 byB0aGUgZGlzY3JldGlvbiBvZiB0aGUgSVNQIGRlcGxveWluZyB0aGUgc2VydmljZSB0byBlbmFi bGUgdGhpcyBvciBub3QuIEluY2x1ZGluZyBkb2N1bWVudGluZyB0aGUgcHJpdmFjeSByaXNrcyBp ZiBlbmFibGVkLiANCg0KTXkgdXNlIGNhc2UgZm9yIHRoaXM6DQpUaGUgcHJvdmlzaW9uZWQgYmFu ZHdpZHRoIG1heSBiZSB1c2VkIGJ5IHAycCBzdHJlYW1pbmcgc3lzdGVtcyB0byBydWxlIG91dCBw ZWVycyB0aGF0IHdpbGwgYW55d2F5IG5vdCBoZWxwIGluIHN0cmVhbWluZyAoZS5nLiwgYW4gcGVl ciB3aXRoIDEyOGtiaXQvcyB1cGxpbmsgaW50ZW5kZWQgdG8gc2VydmUgZnVsbCBIRFRWIHN0cmVh bXMpLg0KDQo+IA0KPiAzLiBUaGUgc3Vic2NyaWJlciBtYXkgbm90IGludGVuZCB0byB1c2UgKmFs bCogcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGZvcg0KPiBhIHBhcnRpY3VsYXIgYXBwbGljYXRpb24g KGUuZy4gUDJQKS4gRm9yIGV4YW1wbGUsIHBlcmhhcHMgdGhlDQo+IHN1YnNjcmliZXIgaW50ZW5k cyB0byB1c2UgcHJvdmlzaW9uZWQgdXBsaW5rIGJhbmR3aWR0aCBmb3INCj4gdGVsZWNvbW11dGlu ZywgdGVsZXByZXNlbmNlLCBvbmxpbmUgc3RvcmFnZSBiYWNrdXBzLCBldGMuIEEgdGhpcmQgcGFy dHkNCj4gY29uc3VtaW5nIEFMVE8gcHJvdmlzaW9uZWQgYmFuZHdpZHRoIGluZm9ybWF0aW9uIHNo b3VsZCBiZSBhd2FyZSB0aGF0DQo+IHRoZSBzdWJzY3JpYmVyJ3MgcHJvdmlzaW9uZWQgYmFuZHdp ZHRoIG1heSBiZSByZXNlcnZlZCBmb3IgZGlmZmVyZW50DQo+IGFwcGxpY2F0aW9ucy4NCg0KVHJ1 ZSwgdGhpcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBhcyBhbiBpc3N1ZSwgYnV0IGFzIHNhaWQgYWJv dmUgdGhpcyBpcyBoZWxwZnVsIGluIHJ1bGluZyBvdXQgcGVlcnMgYW55d2F5IG5vdCB1c2VmdWwu IFNlY29uZCwgdGhlIGFjdHVhbCB1c2FibGUgYmFuZHdpZHRoIG5lZWRzIHRvIGJlIHRlc3RlZCBp biB0aGUgZm9sbG93aW5nIG9wZXJhdGlvbmFsIHN0ZXBzIG9mIHRoZSBwMnAgc3lzdGVtIGFueXdh eS4gDQoNCj4gDQo+IEhlcmUgYXJlIG15IHRob3VnaHRzIG9uIGR5bmFtaWMgYWRkcmVzcyByZS1h bGxvY2F0aW9uLg0KPiANCj4gSVNQcyByZWFsbG9jYXRlIElQdjQgc3VibmV0cyB3aXRoaW4gdGhl aXIgaW5mcmFzdHJ1Y3R1cmUgZnJvbSB0aW1lIHRvDQo+IHRpbWUsIHBhcnRseSB0byBlbnN1cmUg dGhlIGVmZmljaWVudCB1c2FnZSBvZiBJUHY0IGFkZHJlc3NlcyAoYSBzY2FyY2UNCj4gcmVzb3Vy Y2UpLCBhbmQgcGFydGx5IHRvIGVuYWJsZSBlZmZpY2llbnQgcm91dGUgdGFibGVzIHdpdGhpbiB0 aGVpcg0KPiBuZXR3b3JrIHJvdXRlcnMuIFRoZSBmcmVxdWVuY3kgb2YgdGhlc2UgInJlbnVtYmVy aW5nIGV2ZW50cyIgZGVwZW5kIG9uDQo+IHRoZSBncm93dGggaW4gbnVtYmVyIG9mIHN1YnNjcmli ZXJzIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9mIGFkZHJlc3MNCj4gc3BhY2Ugd2l0aGluIHRoZSBJ U1AuIEFzIGEgcmVzdWx0LCBhIHN1YnNjcmliZXIncyBob3VzZWhvbGQgZGV2aWNlDQo+IGNvdWxk IHJldGFpbiBhbiBJUHY0IGFkZHJlc3MgZm9yIGFzIHNob3J0IGFzIGEgZmV3IG1pbnV0ZXMsIG9y IGZvcg0KPiBtb250aHMgYXQgYSB0aW1lIG9yIGV2ZW4gbG9uZ2VyLg0KPiANCj4gU29tZSBmb2xr cyBoYXZlIHN1Z2dlc3RlZCB0aGF0IElTUHMgcHJvdmlkaW5nIEFMVE8gc2VydmljZXMgY291bGQg c3ViLQ0KPiBkaXZpZGUgdGhlaXIgc3Vic2NyaWJlcnMnIGRldmljZXMgaW50byBkaWZmZXJlbnQg SVB2NCBzdWJuZXRzIChvcg0KPiBjZXJ0YWluIElQdjQgYWRkcmVzcyByYW5nZXMpIGJhc2VkIG9u IHRoZSBwdXJjaGFzZWQgc2VydmljZSB0aWVyLCBhcw0KPiB3ZWxsIGFzIGJhc2VkIG9uIHRoZSBs b2NhdGlvbiBpbiB0aGUgbmV0d29yayB0b3BvbG9neS4gVGhlIHByb2JsZW0gaXMNCj4gdGhhdCB0 aGlzIHN1Yi1hbGxvY2F0aW9uIG9mIElQdjQgc3VibmV0cyB0ZW5kcyB0byBkZWNyZWFzZSB0aGUN Cj4gZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3MgYWxsb2NhdGlvbi4gQSBncm93aW5nIElTUCB0 aGF0IG5lZWRzIHRvDQo+IG1haW50YWluIGhpZ2ggZWZmaWNpZW5jeSBvZiBJUHY0IGFkZHJlc3Mg dXRpbGl6YXRpb24gbWF5IGJlIHJlbHVjdGFudA0KPiB0byBqZW9wYXJkaXplIHRoZWlyIGZ1dHVy ZSBhY3F1aXNpdGlvbiBvZiBJUHY0IGFkZHJlc3Mgc3BhY2UuDQo+IA0KPiBUaGVyZWZvcmUsIGNv bnN1bWVycyBvZiBwZXItdXNlciBBTFRPIGluZm9ybWF0aW9uIHNob3VsZCBhc3N1bWUgdGhhdA0K PiBzdWJzY3JpYmVycyByZXRhaW4gSVB2NCBhZGRyZXNzZXMgZm9yIG9ubHkgYSByZWxhdGl2ZWx5 IHNob3J0IHBlcmlvZCBvZg0KPiB0aW1lLCBlLmcuIG1pbnV0ZXMsIGFuZCB0aGF0IHN1YnNjcmli ZXJzIG9mIGRpZmZlcmVudCBzZXJ2aWNlIHRpZXJzDQo+IHdpbGwgY28tZXhpc3QgaW4gc29tZSBJ U1AncyBJUHY0IHN1Ym5ldHMuDQoNCkkgd2lsbCByZXBseSB0byB0aGlzIGluIGEgc2VwYXJhdGUg ZW1haWwuDQoNClRoYW5rcywNCg0KICBNYXJ0aW4NCg0KDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVj bGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZp c2lvbg0KTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwg MSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4 MzIwMTQNCg== From richard_woundy@cable.comcast.com Thu Mar 18 06:06:41 2010 Return-Path: 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 E99FC3A6AB6 for ; Thu, 18 Mar 2010 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=-2.978, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 flZoJxYdbLub for ; Thu, 18 Mar 2010 06:06:40 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id A214D3A659A for ; Thu, 18 Mar 2010 06:06:39 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88559759; Thu, 18 Mar 2010 09:06:32 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 09:06:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 09:06:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2QAAcZlXAABm8QLw== From: "Woundy, Richard" To: , X-OriginalArrivalTime: 18 Mar 2010 13:06:34.0250 (UTC) FILETIME=[D5CA0EA0:01CAC69B] Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:06:41 -0000 PlRoZSBuZXR3b3JrIG1hcHMgKGFuZCB0aGUgYXNzb2NpYXRlZCBjb3N0IG1hcCkgaXMgZmluZSBh cyBsb25nIGFzIHRoZSBJUCBwcmVmaXggYWxsb2NhdGlvbiBpbiBhbiBJU1AncyBuZXR3b3JrIGlz IHN0YWJsZS4gV2hlcmUgc3RhYmxlIG1lYW5zIGNoYW5nZXMgb2YgdGhlIElQIHByZWZpeCBhbGxv Y2F0aW9uIGFyZSBoYXBwZW5pbmcgaW4gdGhlIHJhbmdlIG9mIHdlZWtzLg0KDQpJbiB0aGUgbmV0 d29ya3MgSSBhbSBmYW1pbGlhciB3aXRoIChjYWJsZSksIG1vc3Qgb2YgdGhlIHRpbWUgdGhlIElQ IGFkZHJlc3MgaXMgZmFpcmx5IHN0YWJsZSwgd2l0aCBESENQIGxlYXNlIHRpbWVzIG9uIHRoZSBv cmRlciBvZiBzZXZlcmFsIGRheXMgb3IgYSB3ZWVrLiBBbmQgdGhlIHNhbWUgbGVhc2UgaXMgb2Z0 ZW4gcmVuZXdlZCB0byB0aGUgc2FtZSBESENQIGNsaWVudCAoZXZlbiBvbiBhIG1vZGVtIHJlYm9v dCksIHNvIGEgREhDUCBjbGllbnQgY291bGQgbWFpbnRhaW4gdGhlIHNhbWUgSVAgYWRkcmVzcyBm b3IgbW9udGhzIGF0IGEgdGltZS4gU28gbW9zdCBvZiB0aGUgdGltZSwgbW9zdCBvZiB0aGUgaW5m b3JtYXRpb24gaW4gYSBuZXR3b3JrIG1hcCB3aWxsIGJlIGZhaXJseSBzdGFibGUuDQoNCihPbiBu b24tY2FibGUgbmV0d29ya3MsIHlvdXIgbWlsZWFnZSBtYXkgdmFyeS4pDQoNCk15IG9yaWdpbmFs IHBvaW50IGlzIHRoYXQgc29tZSBpbmRpdmlkdWFsIG1hcCBlbnRyaWVzIG1heSBub3QgYmUgYXMg c3RhYmxlLCBpZiB0aGVyZSBhcmUgcmVudW1iZXJpbmcgZXZlbnRzIGluIHBhcnRpY3VsYXIgcGFy dHMgb2YgdGhlIHRvcG9sb2d5LiBTbyBtb3N0IG9mIHRoZSBtYXAgaXMgc3RhYmxlIGZvciBhIGxv bmcgcGVyaW9kIG9mIHRpbWUsIGJ1dCBhIGZldyBwYXJ0cyBtYXkgYmUgc3ViamVjdCB0byByZW51 bWJlcmluZyBpbiBob3VycyBvciBtaW51dGVzLg0KDQo+SSBkb24ndCBzZWUgYSBwYXJ0aWN1bGFy IHJlYXNvbiB3aHkgdGhlIGluZm9ybWF0aW9uIGdhaW5lZCBmcm9tIHByb3Zpc2lvbmVkIGJhbmR3 aWR0aCBpcyBub3Qgc3ViamVjdCB0byB0aGUgc2FtZSBydWxlcyBhcyB0b3BvbG9neSBpbmZvcm1h dGlvbiBkZWxpdmVyZWQgZm9yIGEgcGVlcidzIElQIGFkZHJlc3MuDQoNCkkgdGhpbmsgSSBhZ3Jl ZS4NCg0KLS0gUmljaA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IE1h cnRpbiBTdGllbWVybGluZyA8TWFydGluLlN0aWVtZXJsaW5nQG5lY2xhYi5ldT4NClRvOiBXb3Vu ZHksIFJpY2hhcmQ7IGFsdG9AaWV0Zi5vcmcgPGFsdG9AaWV0Zi5vcmc+DQpTZW50OiBUaHUgTWFy IDE4IDA3OjE3OjM0IDIwMTANClN1YmplY3Q6IFJFOiBbYWx0b10gQ29tbWVudHMgb24gcHJvdmlz aW9uZWQgYmFuZHdpZHRoIGFuZCBBTFRPDQoNClJpY2gsDQoNCkhlcmUgSSBnbyB3aXRoIG15IGNv bW1lbnRzIG9uIHRoZSBkeW5hbWljIElQIGFkZHJlc3MgcmUtYWxsb2NhdGlvbi4NCg0KSSBjb21t ZW50ZWQgb24gdGhpcyBkdXJpbmcgdGhlIElFVEYtNzYgb24gKHRha2VuIGZyb20gdGhlIG1pbnV0 ZXMpDQpNYXJ0aW46IGhvdyBzdGF0aWMgaXMgYSBuZXR3b3JrIG1hcCBpbiByZWFsaXR5Pw0KYW5k IGFsc28gYnkgZW1haWw6DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWx0 by9jdXJyZW50L21zZzAwNTE5Lmh0bWwNCg0KTXkgcG9pbnQgd2FzIHRoYXQgdGhlIHByb3Bvc2Vk IG5ldHdvcmsgbWFwL2Nvc3QgbWFwIGluIHRoZSBBTFRPIHByb3RvY29sIHdvdWxkIGJlIGxlc3Mg YmVuZWZpY2lhbGx5LCBpZiB0aGUgSVNQIGFyZSBleGFjdGx5IGRvaW5nIHdoYXQgeW91IGhhdmUg ZGVzY3JpYmVkIGFuZCB3aGF0IEkgaGF2ZSBjb21tZW50ZWQgb24gZHVyaW5nIHRoZSBsYXN0IElF VEYuIA0KDQpIb3dldmVyLCBJJ3ZlIGhhZCB0aGUgaW1wcmVzc2lvbiB0aGF0IG1vc3QgcGVvcGxl IGluIHRoZSByb29tIGRpZG4ndCBhZ3JlZSB0byB0aGlzIHZpZXc6DQoNClRoZSBuZXR3b3JrIG1h cHMgKGFuZCB0aGUgYXNzb2NpYXRlZCBjb3N0IG1hcCkgaXMgZmluZSBhcyBsb25nIGFzIHRoZSBJ UCBwcmVmaXggYWxsb2NhdGlvbiBpbiBhbiBJU1AncyBuZXR3b3JrIGlzIHN0YWJsZS4gV2hlcmUg c3RhYmxlIG1lYW5zIGNoYW5nZXMgb2YgdGhlIElQIHByZWZpeCBhbGxvY2F0aW9uIGFyZSBoYXBw ZW5pbmcgaW4gdGhlIHJhbmdlIG9mIHdlZWtzLiANCg0KTm93IHRoZSBjYXZlYXRzIG9mIG5ldHdv cmsgbWFwczoNCkl0IGlzIHVwIHRvIHRoZSBJU1AgdG8gY2hhbmdlIHRoZSBJUCBwcmVmaXggYWxs b2NhdGlvbiBpbiBpdHMgb3duIG5ldHdvcmsgYXQgYW55dGltZS4gSW5jbHVkaW5nIHVzaW5nIHNv bWUgZHluYW1pYyByZS1hbGxvY2F0aW9uIHNjaGVtZXMsIGZvciBpbnN0YW5jZSwgc3VwcG9ydGVk IGJ5IHVzaW5nIENpc2NvJ3MgT0RBUCBmZWF0dXJlLCBidXQgYWxzbyBzaHVmZmxpbmcgdGhlbSBt YW51YWxseS4gSWYgbm93LCBhIGR5bmFtaWMgcmVhbGxvY2F0aW9uIHNjaGVtZSBpcyB1c2VkIChh bmQgSSBndWVzcyBzb21lIElTUCB3aWxsIG5lZWQgdG8gZG8gdGhpcyBzb29uLCBhcyB0aGVyZSBu b3QgdG9vIG1hbnkgZnJlZSBJU1AgcHJlZml4IGJsb2NrcyBsZWZ0KSwgdGhlIG5ldHdvcmsgbWFw cyBoYXZlIHRvIGJlIHVwZGF0ZWQgaW4gbXVjaCBzaG9ydGVyIHRpbWUgZnJhbWUgdGhhbiBhY3R1 YWxseSBlbnZpc2lvbmVkIGJ5IHRoZSBBTFRPIHByb3RvY29sLg0KDQpUaGlzIHRha2VzIGF3YXkg dGhlIGFkdmFudGFnZSBvZiBoYXZpbmcgbmV0d29yayBtYXBzIGFuZCB3b3VsZCBjbGVhcmx5IGFy Z3VlIGZvciBlbmhhbmNlZCBvcmFjbGUgYXBwcm9hY2guDQoNCg0KQ29taW5nIG5vdyB0byBwcm92 aXNpb25lZCBiYW5kd2lkdGggYW5kIGR5bmFtaWMgSVAgYWRkcmVzcyByZS1hbGxvY2F0aW9uOg0K SSBkb24ndCBzZWUgYSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgdGhlIGluZm9ybWF0aW9uIGdhaW5l ZCBmcm9tIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBpcyBub3Qgc3ViamVjdCB0byB0aGUgc2FtZSBy dWxlcyBhcyB0b3BvbG9neSBpbmZvcm1hdGlvbiBkZWxpdmVyZWQgZm9yIGEgcGVlcidzIElQIGFk ZHJlc3MuDQoNCkJvdGggYXJlIHN1YmplY3QgdG8gY2hhbmdlIGFuZCBoYXZlIG1vcmUgbGVzcyBv bmx5IGEgZ29vZCBtZWFuaW5nIGF0IHRoZSB0aW1lIG9mIHRoZSBxdWVyeS4gV2l0aCB0aW1lIGV2 b2x2aW5nLCB0aGUgaW5mb3JtYXRpb24gd2hlcmUgYSBwZWVyIGlzIHRvcG9sb2d5IHdpc2UgY2xv c2Ugb3IgaWYgdGhlIHBlZXIgaGFzIGEgcGFydGljdWxhciBwcm92aXNpb25lZCBiYW5kd2lkdGgg d2lsbCBhbnlob3cgY2hhbmdlIChlLmcuLCBob21lIGdhdGV3YXkgb3IgY2FibGUgbW9kZW0gaXMg cmVib290aW5nLCBjYXVzaW5nIHRvIGdldCBhIG5ldyBJUCBhZGRyZXNzIGFzc2lnbmVkIGFuZCB0 aGUgb2xkIG9uZSBiZWluZyByZS1hc3NpZ25lZCB0byBzb21lIG90aGVyIGN1c3RvbWVyIGFjY2Vz cyBsaW5lKS4NCg0KVGhhbmtzLA0KDQogIE1hcnRpbg0KDQo+IA0KPiBIZXJlIGFyZSBteSB0aG91 Z2h0cyBvbiBkeW5hbWljIGFkZHJlc3MgcmUtYWxsb2NhdGlvbi4NCj4gDQo+IElTUHMgcmVhbGxv Y2F0ZSBJUHY0IHN1Ym5ldHMgd2l0aGluIHRoZWlyIGluZnJhc3RydWN0dXJlIGZyb20gdGltZSB0 bw0KPiB0aW1lLCBwYXJ0bHkgdG8gZW5zdXJlIHRoZSBlZmZpY2llbnQgdXNhZ2Ugb2YgSVB2NCBh ZGRyZXNzZXMgKGEgc2NhcmNlDQo+IHJlc291cmNlKSwgYW5kIHBhcnRseSB0byBlbmFibGUgZWZm aWNpZW50IHJvdXRlIHRhYmxlcyB3aXRoaW4gdGhlaXINCj4gbmV0d29yayByb3V0ZXJzLiBUaGUg ZnJlcXVlbmN5IG9mIHRoZXNlICJyZW51bWJlcmluZyBldmVudHMiIGRlcGVuZCBvbg0KPiB0aGUg Z3Jvd3RoIGluIG51bWJlciBvZiBzdWJzY3JpYmVycyBhbmQgdGhlIGF2YWlsYWJpbGl0eSBvZiBh ZGRyZXNzDQo+IHNwYWNlIHdpdGhpbiB0aGUgSVNQLiBBcyBhIHJlc3VsdCwgYSBzdWJzY3JpYmVy J3MgaG91c2Vob2xkIGRldmljZQ0KPiBjb3VsZCByZXRhaW4gYW4gSVB2NCBhZGRyZXNzIGZvciBh cyBzaG9ydCBhcyBhIGZldyBtaW51dGVzLCBvciBmb3INCj4gbW9udGhzIGF0IGEgdGltZSBvciBl dmVuIGxvbmdlci4NCj4gDQo+IFNvbWUgZm9sa3MgaGF2ZSBzdWdnZXN0ZWQgdGhhdCBJU1BzIHBy b3ZpZGluZyBBTFRPIHNlcnZpY2VzIGNvdWxkIHN1Yi0NCj4gZGl2aWRlIHRoZWlyIHN1YnNjcmli ZXJzJyBkZXZpY2VzIGludG8gZGlmZmVyZW50IElQdjQgc3VibmV0cyAob3INCj4gY2VydGFpbiBJ UHY0IGFkZHJlc3MgcmFuZ2VzKSBiYXNlZCBvbiB0aGUgcHVyY2hhc2VkIHNlcnZpY2UgdGllciwg YXMNCj4gd2VsbCBhcyBiYXNlZCBvbiB0aGUgbG9jYXRpb24gaW4gdGhlIG5ldHdvcmsgdG9wb2xv Z3kuIFRoZSBwcm9ibGVtIGlzDQo+IHRoYXQgdGhpcyBzdWItYWxsb2NhdGlvbiBvZiBJUHY0IHN1 Ym5ldHMgdGVuZHMgdG8gZGVjcmVhc2UgdGhlDQo+IGVmZmljaWVuY3kgb2YgSVB2NCBhZGRyZXNz IGFsbG9jYXRpb24uIEEgZ3Jvd2luZyBJU1AgdGhhdCBuZWVkcyB0bw0KPiBtYWludGFpbiBoaWdo IGVmZmljaWVuY3kgb2YgSVB2NCBhZGRyZXNzIHV0aWxpemF0aW9uIG1heSBiZSByZWx1Y3RhbnQN Cj4gdG8gamVvcGFyZGl6ZSB0aGVpciBmdXR1cmUgYWNxdWlzaXRpb24gb2YgSVB2NCBhZGRyZXNz IHNwYWNlLg0KPiANCj4gVGhlcmVmb3JlLCBjb25zdW1lcnMgb2YgcGVyLXVzZXIgQUxUTyBpbmZv cm1hdGlvbiBzaG91bGQgYXNzdW1lIHRoYXQNCj4gc3Vic2NyaWJlcnMgcmV0YWluIElQdjQgYWRk cmVzc2VzIGZvciBvbmx5IGEgcmVsYXRpdmVseSBzaG9ydCBwZXJpb2Qgb2YNCj4gdGltZSwgZS5n LiBtaW51dGVzLCBhbmQgdGhhdCBzdWJzY3JpYmVycyBvZiBkaWZmZXJlbnQgc2VydmljZSB0aWVy cw0KPiB3aWxsIGNvLWV4aXN0IGluIHNvbWUgSVNQJ3MgSVB2NCBzdWJuZXRzLg0KPiANCj4gLS0g UmljaA0KDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMg RXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbg0KTkVDIEV1cm9wZSBMaW1pdGVkIHwg UmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMg NkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCg== From richard.alimi@gmail.com Thu Mar 18 06:06:50 2010 Return-Path: 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 3FA623A6B92 for ; Thu, 18 Mar 2010 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 kT0hDgTEsqki for ; Thu, 18 Mar 2010 06:06:49 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id EF3403A659A for ; Thu, 18 Mar 2010 06:06:48 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so233805qwd.31 for ; Thu, 18 Mar 2010 06:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=2oKBazgBl/yrXThT1ELaTWck8A3qbBPeo9b4s95wRso=; b=v61/EvTjN4gWYgqmRIHpamsT+GXvSjWGeyyQ/XgzL6BdU489VKZ/1HEd3aKvh473hI LL91ScDz2CcbIPHNbp9e8JJsLkhC50A2h8TstPsMVF8Ldgt+gUd3gRqTvSlSja/6szN1 lKZnSFZQeBCiZQr1DAqIVudGqv/SAOASZM/Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=ZO1OTtoYs/WoObo+bbWuLuPM1FZ7Js8XYy3fhG+TB50Hc2PuQN/m3cQyXgVAOJBZKD yYmpJ1UDzHVPeOhJDB6qfWRYEaKVMn4sZs8DUSVJM4N+1/Ec7BAzdyq41AgrUwlMKzJz J8tn39EUc50diqDTFrB0KupvIFSH2Y84q5Nvg= Received: by 10.224.58.195 with SMTP id i3mr735433qah.180.1268917614952; Thu, 18 Mar 2010 06:06:54 -0700 (PDT) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id 20sm5479805qyk.0.2010.03.18.06.06.54 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 06:06:54 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 09:06:53 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: <547F018265F92642B577B986577D671C012A301F@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C012A301F@VENUS.office> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003180906.53529.richard.alimi@yale.edu> Cc: Martin Stiemerling Subject: Re: [alto] Error handling in the ALTO protocol (-03) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:06:50 -0000 Hi Martin, On Thursday 18 March 2010 7:29:18 am Martin Stiemerling wrote: > Hi all, > > While reading draft-ietf-alto-protocol-03 is stumbled over the error > handling. > > It seems that the error handling of ALTO relies on the http error codes, > but does not provide its own error code or proceed. > > I see this a shortcoming of the current design and also as not favourably. > > This mixes transport related error messages (e.g., 404 not found, i.e., the > general alto resource your asking for isn't here) and errors related the > actual ALTO handling (e.g., asking guidance for private or reserved IP > addresses that cannot be rated by ALTO, syntax errors, or not understood > objects). > > My proposal: > - separate both levels clearly > - define an error object for cases where no or only a partial answer can be > given - define that the server can deliver some information he has > understood (e.g., some IP addresses) within the given semantics, as > defined in the draft as is. > > Martin > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto This makes sense, and I think it is reasonable to adopt for the next version of the document. It would be good to get opinions from others here as well. -- Richard Alimi Department of Computer Science Yale University From richard_woundy@cable.comcast.com Thu Mar 18 06:38:57 2010 Return-Path: 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 B76003A6AD5 for ; Thu, 18 Mar 2010 06:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[AWL=1.791, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 vgdJ8nH0vLUJ for ; Thu, 18 Mar 2010 06:38:56 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 874823A6A29 for ; Thu, 18 Mar 2010 06:38:56 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74621157; Thu, 18 Mar 2010 09:39:05 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 09:39:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 09:38:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error handling in the ALTO protocol (-03) Thread-Index: AcrGjj+EuqGXx59iTeWAsLMUBTt0fgAEgBiA From: "Woundy, Richard" To: , X-OriginalArrivalTime: 18 Mar 2010 13:39:06.0441 (UTC) FILETIME=[6162C390:01CAC6A0] Subject: Re: [alto] Error handling in the ALTO protocol (-03) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:38:57 -0000 TWFydGluLCBJIGFzc3VtZSBpbiB5b3VyIHByb3Bvc2FsIHRoYXQgQUxUTyB3b3VsZCBzdGlsbCBs ZXZlcmFnZSB0aGUgYXBwcm9wcmlhdGUgSFRUUCBlcnJvciBjb2RlcyBhcyB3ZWxsIGFzIGFkZCBB TFRPIGVycm9yIGNvZGVzIC8gaW5mb3JtYXRpb24/DQoNCkkgdGhpbmsgd2Ugd2FudCB0byBrZWVw IHRoZSBIVFRQIGVycm9yIGNvZGVzIHNvIHRoYXQgaW50ZXJtZWRpYXJpZXMgKGVnIGNhY2hlcykg aGFuZGxlIGVycm9ycyB0aGUgcmlnaHQgd2F5IGFzIHdlbGwuDQoNCi0tIFJpY2gNCg0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBhbHRvLWJvdW5jZXNAaWV0Zi5vcmcgPGFs dG8tYm91bmNlc0BpZXRmLm9yZz4NClRvOiBhbHRvQGlldGYub3JnIDxhbHRvQGlldGYub3JnPg0K U2VudDogVGh1IE1hciAxOCAwNzoyOToxOCAyMDEwDQpTdWJqZWN0OiBbYWx0b10gRXJyb3IgaGFu ZGxpbmcgaW4gdGhlIEFMVE8gcHJvdG9jb2wgKC0wMykNCg0KSGkgYWxsLA0KDQpXaGlsZSByZWFk aW5nIGRyYWZ0LWlldGYtYWx0by1wcm90b2NvbC0wMyBpcyBzdHVtYmxlZCBvdmVyIHRoZSBlcnJv ciBoYW5kbGluZy4gDQoNCkl0IHNlZW1zIHRoYXQgdGhlIGVycm9yIGhhbmRsaW5nIG9mIEFMVE8g cmVsaWVzIG9uIHRoZSBodHRwIGVycm9yIGNvZGVzLCBidXQgZG9lcyBub3QgcHJvdmlkZSBpdHMg b3duIGVycm9yIGNvZGUgb3IgcHJvY2VlZC4gDQoNCkkgc2VlIHRoaXMgYSBzaG9ydGNvbWluZyBv ZiB0aGUgY3VycmVudCBkZXNpZ24gYW5kIGFsc28gYXMgbm90IGZhdm91cmFibHkuDQoNClRoaXMg bWl4ZXMgdHJhbnNwb3J0IHJlbGF0ZWQgZXJyb3IgbWVzc2FnZXMgKGUuZy4sIDQwNCBub3QgZm91 bmQsIGkuZS4sIHRoZSBnZW5lcmFsIGFsdG8gcmVzb3VyY2UgeW91ciBhc2tpbmcgZm9yIGlzbid0 IGhlcmUpIGFuZCBlcnJvcnMgcmVsYXRlZCB0aGUgYWN0dWFsIEFMVE8gaGFuZGxpbmcgKGUuZy4s IGFza2luZyBndWlkYW5jZSBmb3IgcHJpdmF0ZSBvciByZXNlcnZlZCBJUCBhZGRyZXNzZXMgdGhh dCBjYW5ub3QgYmUgcmF0ZWQgYnkgQUxUTywgc3ludGF4IGVycm9ycywgb3Igbm90IHVuZGVyc3Rv b2Qgb2JqZWN0cykuIA0KDQpNeSBwcm9wb3NhbDoNCi0gc2VwYXJhdGUgYm90aCBsZXZlbHMgY2xl YXJseQ0KLSBkZWZpbmUgYW4gZXJyb3Igb2JqZWN0IGZvciBjYXNlcyB3aGVyZSBubyBvciBvbmx5 IGEgcGFydGlhbCBhbnN3ZXIgY2FuIGJlIGdpdmVuDQotIGRlZmluZSB0aGF0IHRoZSBzZXJ2ZXIg Y2FuIGRlbGl2ZXIgc29tZSBpbmZvcm1hdGlvbiBoZSBoYXMgdW5kZXJzdG9vZCAoZS5nLiwgc29t ZSBJUCBhZGRyZXNzZXMpIHdpdGhpbiB0aGUgZ2l2ZW4gc2VtYW50aWNzLCBhcyBkZWZpbmVkIGlu IHRoZSBkcmFmdCBhcyBpcy4gDQoNCiAgTWFydGluDQoNCm1hcnRpbi5zdGllbWVybGluZ0BuZWNs YWIuZXUNCg0KTkVDIExhYm9yYXRvcmllcyBFdXJvcGUgLSBOZXR3b3JrIFJlc2VhcmNoIERpdmlz aW9uDQpORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAx IFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgz MjAxNCANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KYWx0byBtYWlsaW5nIGxpc3QNCmFsdG9AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWx0bw0K From richard.alimi@gmail.com Thu Mar 18 06:50:17 2010 Return-Path: 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 D79A13A6A49 for ; Thu, 18 Mar 2010 06:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 OSQQJgpik8mJ for ; Thu, 18 Mar 2010 06:50:16 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 9D49B3A683A for ; Thu, 18 Mar 2010 06:50:16 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so242273qwd.31 for ; Thu, 18 Mar 2010 06:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=+46ZSWBZtFvtk2GWSjWwg5gxDkDiBvLlDpm6j3/Oz9o=; b=UB+IBV4rOc94iYGLYAXudmKPpMvXZOeBf/MNeDRN+mG35MpD4XQ1sFwIUi7nmZn0Sr kHEFOMLcvU56ubXhGEso4EOO/RU/vFCjL18idAUjSklB7kzwDeLKm5fN6aocQ9CMdHio F43s21v/eXbe9MfmtO4uxWK/ghYNxG8gzqi9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=rZ0RcWrZ/x63yS6ooES30KXy88MuozeWuGhbhj7g+svAHTSXubWE465L9/1Jsux9Ya DV3uM3HzAx3k2Z8FLJTmHCmK5FN6St0g6j9dRw3XPlJOFmzuTmYy1atGYUENTJCUn/DC 11dfELWVz9vqfa2oiPaWFvHzHLGxNmnVoXU7U= Received: by 10.229.191.18 with SMTP id dk18mr2185270qcb.9.1268920225056; Thu, 18 Mar 2010 06:50:25 -0700 (PDT) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id 23sm5467120qyk.15.2010.03.18.06.50.23 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 06:50:24 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: "Martin Stiemerling" Date: Thu, 18 Mar 2010 09:50:22 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: <201003111729.33544.richard.alimi@yale.edu> <547F018265F92642B577B986577D671C012A3023@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C012A3023@VENUS.office> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003180950.23175.richard.alimi@yale.edu> Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:50:18 -0000 Hi Martin, Thank you very much for the comments. Please see inline: On Thursday 18 March 2010 7:39:15 am Martin Stiemerling wrote: > Rich, > > a few comments inline: > > -----Original Message----- > > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of > > Richard Alimi > > Sent: Thursday, March 11, 2010 11:30 PM > > To: Jason Livingood > > Cc: alto@ietf.org > > Subject: Re: [alto] #1: Message format > > > > Hi Jason, > > > > Thank you very much for taking a look. Please see below: > > > > On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > > > You may want to make some of these tracker notes more verbose. > > > > At this point, since this is a first stab at fully specifying protocol > > details, my personal feeling is that we are still wide-open for > > discussion on > > the whole document. However, there on a few points that I think are > > particular > > important for this go-around: > > > > - IPv4/IPv6 needs much more thought before integrating it into > > > > the document. In particular, what are the right semantics for > > > > handling IPv4 > > > > and IPv6 with respect to indicating provider preferences? (Some > > > > initial > > > > questions are noted on Issue #9 for this)? > > A simple turn on this: limit a single query-object to an IP address family. > However, a query to the server can include multiple query-objects, i.e., > one each for an IP address family or whatever identifier comes up later on > (e.g. HIP IDs ;) Yes, this is one possibility. One limitation of this approach is that we could only convey a _global_ preference for IPv4, IPv6, etc. That is, a network provider could say "please prefer IPv6 regardless of who you are contacting." Another possible preference that one might want to convey is per-destination Network Location. For example, "please prefer IPv6 when contacting endpoints in ISP A, but please prefer IPv4 when contacting endpoints in ISP B." It would be good to hear some opinions (particularly from service providers) as to whether such preferences this would useful or necessary. If so, we can figure out a reasonable way to encode such preferences (one possibility may be a per-PID attribute). > > - With regard to messaging (including usage of HTTP URIs and the actual > > body > > > > encodings), can people think of issues that might cause problems for > > deployment in an operational network (e.g., load-balancing > > > > configuration)? > > > > Difficult or non-intuitive implementation (both server-side and > > client-side)? Are there any ambiguities you can see? > > I thinking through the current protocol details we have tried to > > > > address > > > > these, but input from others would be extremely helpful. > > I'm still browsing through this and how JSON works. Sounds good. > > - For Redistribution, this is a capability that seemed to get favorable > > > > feedback at IETF76. The current implementation uses HTTP > > > > headers/trailers to > > > > send the signatures, and a certificate is encoded in the Server > > > > Capability > > > > response. The idea is that an ALTO Client can locally cache the > > > > certificate > > > > and only contact the ALTO Server very infrequently even if it is > > > > gathering > > > > ALTO information (i.e., ALTOResponse structs) from other ALTO Clients > > instead of the ALTO Server itself. For this part, what do people > > > > think about > > > > how such redistribution information is encoded in the protocol? Is > > > > there a > > > > clean way to do this without requiring custom HTTP headers/trailers? > > > > Does > > > > the spec sufficiently convey when redistribution should or should not > > > > be > > > > used? > > I'm not sure that the spec is doing good in this respect. The emphasize is > on the security (i.e., using certificates), but an important point is > missing. The server should state in what area (i.e., IP prefix) this > information is allowed to be distributed. > > See draft-kiesel-alto-h12-02 under redistribution: > > The response contains also a resource consumer host location > attribute (rc_hla). This rc_hla echos partially the information from > the request, but gives actually guidance to the ALTO client in what > scope this information can be distributed amongst other peers. In > this response, the server allows the redistribution of the received > guidance to peers with the IP prefix 195.37.0.0/16. This is actually what the "server", "request_uri" and "request_body" attributes are for. As stated in the draft: ... This allows ALTO Clients to which the information is distributed to understand the context of the query and interpret the results. Here, the "context" basically means "the full set of input parameters that would have produced this response." Using this, ALTO Clients can determine the distribution scope. Put another way, if another ALTO Client executed the same query (to the same server) with this particular input, they'd get the same response. The only case where such a guarantee is not available is when other information beyond the URI or ALTO Request Body is used to generate the response. In the current protocol, such cases should not (as a side note, perhaps it should be changed to a MUST NOT..) be redistributed: Note that information about ALTO Client performing the Request and any HTTP Headers passed in the request are not included. If any such information or headers influence the response generated by the ALTO Server, the response SHOULD NOT be indicated as redistributable. Such a case *could* be handled as you mentioned by explicitly giving a scope for redistribution, but I'm wondering what particular queries you were thinking about here, and whether it makes sense to redistribute the responses to such queries. Another way to interpret your concern is from an access-control perspective. That is, using such a scope to indicate which other ALTO Clients have permission to receive this particular ALTO Response. If this is the intention (I'm not implying that you think it is, I'm just trying to cover all of the bases), then I don't think this is reasonable to put in the protocol, since ALTO Clients are in no way bound to follow this advice. > > As mentioned above, I would think that comments about the entire > > document are > > very useful, but the major changes in these couple of revisions have > > been to > > sections 6, 7, and 11 (so feel free to focus there). > > I'm still reading... Great :) Thanks again for the comments! -- Richard Alimi Department of Computer Science Yale University From trac@tools.ietf.org Thu Mar 18 07:11:06 2010 Return-Path: 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 DEA403A6A29 for ; Thu, 18 Mar 2010 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.919 X-Spam-Level: X-Spam-Status: No, score=-101.919 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 2T8-f+nBoIPC for ; Thu, 18 Mar 2010 07:11:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 37CF93A69D7 for ; Thu, 18 Mar 2010 07:11:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NsGRR-0000Pc-DA; Thu, 18 Mar 2010 07:11:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "alto issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.alimi@yale.edu X-Trac-Project: alto Date: Thu, 18 Mar 2010 14:11:17 -0000 X-URL: http://tools.ietf.org/alto/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/alto/trac/ticket/10 Message-ID: <061.177b931ac3f0a4580a64d49254da27b1@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.alimi@yale.edu, alto@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: alto@ietf.org Subject: [alto] #10: Error Codes X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:11:07 -0000 #10: Error Codes ------------------------------------+--------------------------------------- Reporter: richard.alimi@… | Owner: richard.alimi@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Currently, draft-ietf-alto-protocol-03 solely uses HTTP status codes. Martin has brought up concerns on the mailing list (see http://www.ietf.org/mail-archive/web/alto/current/msg00610.html). This ticket is being created to track the major discussion points and resolutions to them. -- Ticket URL: alto From richard.alimi@gmail.com Thu Mar 18 07:15:28 2010 Return-Path: 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 3A41C3A6BB3 for ; Thu, 18 Mar 2010 07:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 zovNT9Wn3cqV for ; Thu, 18 Mar 2010 07:15:27 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id E1E9A3A6BD7 for ; Thu, 18 Mar 2010 07:15:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so358448fga.13 for ; Thu, 18 Mar 2010 07:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=wnzeNSr1DYOa5V5/wXmhjpBBKlElSKVXYeFIPblMQMw=; b=jwzCwAS0emsqQh9nga14eVRYHXg00Idk/uoZ8YbaZ0Ail/8MMjjNNhIrz5rqlYFLuy fcVx33uKP9HZfxTJoO5m7qzMjHhUpNIsHLHpYXbxUte/oNu2XgIzaZTFT0vRwrGlzMje vECOWPKrvIudTAFW8cYEPjzRTkspD6TEJbP70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=ZQbijmESDkBWRnyu2ybW6D5gue43CI9WiwHUe1UFPL3/bmRI38dxHQFrGDKBQP0++G oA2LPIZXmuUfcJOM82TdvuLRbK3cOCK4qfVCMiGwbNpB35BV/piTdC2U2xPLfBgWuXzj 7APbWRJ/t7gcIxImSycwzod/A4C95iPPmoI9M= Received: by 10.87.72.8 with SMTP id z8mr15459361fgk.37.1268921729921; Thu, 18 Mar 2010 07:15:29 -0700 (PDT) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id d6sm60219fga.6.2010.03.18.07.15.28 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 07:15:28 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 10:15:26 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003181015.26869.richard.alimi@yale.edu> Cc: "Woundy, Richard" , Martin.Stiemerling@neclab.eu Subject: Re: [alto] Error handling in the ALTO protocol (-03) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:15:28 -0000 BTW, I've created a ticket in the Issue Tracker related to Error codes in the protocol to track this discussion. I agree that we still need to use HTTP status codes for exactly the reason you mentioned. -- Richard Alimi Department of Computer Science Yale University On Thursday 18 March 2010 9:38:10 am Woundy, Richard wrote: > Martin, I assume in your proposal that ALTO would still leverage the > appropriate HTTP error codes as well as add ALTO error codes / > information? > > I think we want to keep the HTTP error codes so that intermediaries (eg > caches) handle errors the right way as well. > > -- Rich > > > ----- Original Message ----- > From: alto-bounces@ietf.org > To: alto@ietf.org > Sent: Thu Mar 18 07:29:18 2010 > Subject: [alto] Error handling in the ALTO protocol (-03) > > Hi all, > > While reading draft-ietf-alto-protocol-03 is stumbled over the error > handling. > > It seems that the error handling of ALTO relies on the http error codes, > but does not provide its own error code or proceed. > > I see this a shortcoming of the current design and also as not favourably. > > This mixes transport related error messages (e.g., 404 not found, i.e., the > general alto resource your asking for isn't here) and errors related the > actual ALTO handling (e.g., asking guidance for private or reserved IP > addresses that cannot be rated by ALTO, syntax errors, or not understood > objects). > > My proposal: > - separate both levels clearly > - define an error object for cases where no or only a partial answer can be > given - define that the server can deliver some information he has > understood (e.g., some IP addresses) within the given semantics, as > defined in the draft as is. > > Martin > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From richard.alimi@gmail.com Thu Mar 18 07:43:57 2010 Return-Path: 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 408C13A6A46 for ; Thu, 18 Mar 2010 07:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 bNF9DUWsHe12 for ; Thu, 18 Mar 2010 07:43:56 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 3ECDD3A6860 for ; Thu, 18 Mar 2010 07:43:56 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so92788fgg.13 for ; Thu, 18 Mar 2010 07:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=+TiZiiWIxnsyzYW0j/msfYqTH5NfH8tlXC/cZYyhl3c=; b=s5dbKJzOS04Q7liwJtgImCmA0qMKHUkatSsn7pajE17BtL4UZyKFZiUggDpW7KJyr3 vv8QbGiZzFiQUm3UClIT/oL1Gz61uYVKajaA3q2FDsLRPfOg/y17QqzHcUr2V+I63q3B 5XTDv80kRnmUkClQNzklGDvb08yPLxxWvCX6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=wNl6xFNX3QiNZwKsfAleAEKX/7JyvKIfmTRrX/63J0USfNcpLFXIGDTCiIqXQ79v57 XCEFvFf/la02nzVi9ykv6Fc/yJBw8t1engqj1x2cOCFzaPsmok9yGYzmRspA3qI657/t yZZESm+3nRm7wsPIMO3lzgR716pkjBPfU1Dn8= Received: by 10.86.106.7 with SMTP id e7mr5883806fgc.1.1268923444206; Thu, 18 Mar 2010 07:44:04 -0700 (PDT) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id d6sm94310fga.16.2010.03.18.07.44.02 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 07:44:03 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 10:44:00 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201003181044.00987.richard.alimi@yale.edu> Subject: [alto] Redistribution Framework X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:43:57 -0000 Hi All, We are looking to get some feedback on the ALTO Information Redistribution draft. Note that we have changed the intended status to a BCP. The goal of the draft is three-fold: 1) Create a framework that illuminates the major considerations for both ALTO Service Providers enabling redistribution, and application developers who are looking to utilize redistribution. Note that the considerations here are distinct from the ones that would be discussed in the ALTO Protocol draft -- this draft encompasses considerations for naming, searching, and distributing ALTO info between ALTO clients, which are outside of the scope of the ALTO Protocol. 2) Illustrate how the framework relates to the functionality for redistribution provided in the ALTO Protocol. 3) Presents techniques for enabling redistribution in particular (widely-used) types of applications. In particular, it would be great to get feedback about the draft contents itself, such as: 1) Do you think that the framework and considerations encompass other redistribution schemes that you can think of? 2) Do you think there are other particular redistribution schemes (that could be widely-used) that should explicitly documented? It would also be great to get feedback on whether you think this document would be useful for the WG, and to eventually accompany other items produced by the WG. Thanks! -- Richard Alimi Department of Computer Science Yale University From rpenno@juniper.net Thu Mar 18 07:44:44 2010 Return-Path: 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 1ABD53A6C24 for ; Thu, 18 Mar 2010 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.434 X-Spam-Level: X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] 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 tDSfxtW+O1QJ for ; Thu, 18 Mar 2010 07:44:43 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 143DC3A6860 for ; Thu, 18 Mar 2010 07:44:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKS6I8V3SxzImft5WSmrBiRnQTXYwm2mdM@postini.com; Thu, 18 Mar 2010 07:44:47 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 18 Mar 2010 07:39:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 18 Mar 2010 10:39:42 -0400 From: Reinaldo Penno To: Martin Stiemerling , "Woundy, Richard" , "alto@ietf.org" Date: Thu, 18 Mar 2010 10:39:38 -0400 Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: Acqv6sxUpzWNxt3JTIKLENk1OXmYjQWetz2QAAcZlXAACbGWGw== Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C012A301B@VENUS.office> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:44:44 -0000 Hello, On 3/18/10 4:17 AM, "Martin Stiemerling" wrote: > Rich, >=20 > Here I go with my comments on the dynamic IP address re-allocation. >=20 > I commented on this during the IETF-76 on (taken from the minutes) > Martin: how static is a network map in reality? > and also by email: > http://www.ietf.org/mail-archive/web/alto/current/msg00519.html >=20 > My point was that the proposed network map/cost map in the ALTO protocol = would > be less beneficially, if the ISP are exactly doing what you have describe= d and > what I have commented on during the last IETF. >=20 > However, I've had the impression that most people in the room didn't agre= e to > this view: >=20 > The network maps (and the associated cost map) is fine as long as the IP > prefix allocation in an ISP's network is stable. Where stable means chang= es of > the IP prefix allocation are happening in the range of weeks. >=20 > Now the caveats of network maps: > It is up to the ISP to change the IP prefix allocation in its own network= at > anytime. Including using some dynamic re-allocation schemes, for instance= , > supported by using Cisco's ODAP feature, but also shuffling them manually= . If > now, a dynamic reallocation scheme is used (and I guess some ISP will nee= d to > do this soon, as there not too many free ISP prefix blocks left), the net= work > maps have to be updated in much shorter time frame than actually envision= ed by > the ALTO protocol. There is already plenty of data suggesting what ISPs will do when they run out of IPv4 addresses and I do not think what you suggest will happen in an= y significant way. ISPs will use 10/8 for their internal network (some alread= y do) in combination with NAT44/VRFs, or will use IPv6 and perform NAT64. The internal network addressing will be fairly stable. As far as what the external routing domain will see, this is something that might be interesting point. Sharing of IP addresses in a CGN will need special considerations within the ALTO protocol. >=20 > This takes away the advantage of having network maps and would clearly ar= gue > for enhanced oracle approach. >=20 >=20 I do not agree. But I would point out that in a NATed Internet the location of the ALTO server handling the requests in relation to the NAT boxes will play an important role. You cannot mix address family (as in private vs. public vs. IPv6) in a query and hope for it to work. > Coming now to provisioned bandwidth and dynamic IP address re-allocation: > I don't see a particular reason why the information gained from provision= ed > bandwidth is not subject to the same rules as topology information delive= red > for a peer's IP address. Sure, provisioned bandwidth could be included as an attribute of the endpoint service (or old ranking service) . I do not think the protocol put= s any limitation on it today. >=20 > Both are subject to change and have more less only a good meaning at the = time > of the query. With time evolving, the information where a peer is topolog= y > wise close or if the peer has a particular provisioned bandwidth will any= how > change (e.g., home gateway or cable modem is rebooting, causing to get a = new > IP address assigned and the old one being re-assigned to some other custo= mer > access line). >=20 > Thanks, >=20 > Martin >=20 >>=20 >> Here are my thoughts on dynamic address re-allocation. >>=20 >> ISPs reallocate IPv4 subnets within their infrastructure from time to >> time, partly to ensure the efficient usage of IPv4 addresses (a scarce >> resource), and partly to enable efficient route tables within their >> network routers. The frequency of these "renumbering events" depend on >> the growth in number of subscribers and the availability of address >> space within the ISP. As a result, a subscriber's household device >> could retain an IPv4 address for as short as a few minutes, or for >> months at a time or even longer. >>=20 >> Some folks have suggested that ISPs providing ALTO services could sub- >> divide their subscribers' devices into different IPv4 subnets (or >> certain IPv4 address ranges) based on the purchased service tier, as >> well as based on the location in the network topology. The problem is >> that this sub-allocation of IPv4 subnets tends to decrease the >> efficiency of IPv4 address allocation. A growing ISP that needs to >> maintain high efficiency of IPv4 address utilization may be reluctant >> to jeopardize their future acquisition of IPv4 address space. >>=20 >> Therefore, consumers of per-user ALTO information should assume that >> subscribers retain IPv4 addresses for only a relatively short period of >> time, e.g. minutes, and that subscribers of different service tiers >> will co-exist in some ISP's IPv4 subnets. >>=20 >> -- Rich >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 > 6BL | Registered in England 2832014 > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From sebi@smtp.ehlo.wurstkaes.de Thu Mar 18 14:42:03 2010 Return-Path: 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 18A023A6804 for ; Thu, 18 Mar 2010 14:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] 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 8ToPHFRv0bRT for ; Thu, 18 Mar 2010 14:42:02 -0700 (PDT) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id 1721C3A67DA for ; Thu, 18 Mar 2010 14:42:01 -0700 (PDT) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1NsNTm-0004S9-9q; Thu, 18 Mar 2010 22:42:10 +0100 Date: Thu, 18 Mar 2010 22:42:10 +0100 From: Sebastian Kiesel To: "Woundy, Richard" Message-ID: <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 21:42:03 -0000 Hi, a technical concern regarding the provisioned bandwidth attribute: If a P2P app uses this information for a peer selection strategy like "try the highest bandwidth tier peers first" or "try the highest bandwidth tier peers with higher probability", and if there is a swarm with many peers but very few of them are in the highest bandwidth tier, the user experience of these premium customers might be worse than for a customer with lower provisioned bandwidth (even if the P2P app uses flow control and congestion control, the initial syn packets alone could overwhelm the premium customer's links). So we should be very clear what we want to do with this kind of information in the application. Thinking about this for a while, this problem is not limited to the provisioned bandwidth. Maybe we need to distinguish between rating criteria that are commutative (i.e., peer B would be a "good" neighbor for peer A according to that criterion implies that A would be a "good" neighbor for B) and those criteria that are not. Using non-commutative rating criteria might be risky. -- Sebastian From richard_woundy@cable.comcast.com Thu Mar 18 14:48:23 2010 Return-Path: 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 F30663A69F4 for ; Thu, 18 Mar 2010 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-2.230, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 x4W-Of5QeGKi for ; Thu, 18 Mar 2010 14:48:22 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 112283A680B for ; Thu, 18 Mar 2010 14:48:21 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78821650; Thu, 18 Mar 2010 17:48:15 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 17:48:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 17:48:04 -0400 Message-ID: In-Reply-To: <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: AcrG4+McBqQ7tVOITvmkfQTvliVL5wAAFrwA References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> From: "Woundy, Richard" To: "Sebastian Kiesel" X-OriginalArrivalTime: 18 Mar 2010 21:48:16.0414 (UTC) FILETIME=[B7553BE0:01CAC6E4] Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 21:48:23 -0000 I agree. Here's a slightly different example. The common tier for ISP A may have provisioned bandwidth of 12 Mbps, and 10 Mbps for ISP B. Assuming that an application doesn't need 11 Mbps, it may make more sense for the app to pick an ISP A client 12 times out of 22 (55%), and an ISP B client 10 times out of 22 (45%), rather than an ISP A client 100% of the time. -- Rich -----Original Message----- From: Sebastian Kiesel [mailto:ietf-alto@skiesel.de]=20 Sent: Thursday, March 18, 2010 5:42 PM To: Woundy, Richard Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO Hi, a technical concern regarding the provisioned bandwidth attribute: If a P2P app uses this information for a peer selection strategy like "try the highest bandwidth tier peers first" or "try the highest bandwidth tier peers with higher probability", and if there is a swarm with many peers but very few of them are in the highest bandwidth tier, the user experience of these premium customers might be worse than for a customer with lower provisioned bandwidth (even if the P2P app uses flow control and congestion control, the initial syn packets alone could overwhelm the premium customer's links). So we should be very clear what we want to do with this kind of information in the application. Thinking about this for a while, this problem is not limited to the provisioned bandwidth. Maybe we need to distinguish between rating criteria that are commutative (i.e., peer B would be a "good" neighbor for peer A according to that criterion implies that A would be a "good" neighbor for B) and those criteria that are not. Using non-commutative rating criteria might be risky. -- Sebastian From richard.alimi@gmail.com Thu Mar 18 15:06:54 2010 Return-Path: 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 CF77F3A6BB8 for ; Thu, 18 Mar 2010 15:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 RZmAryZlcZb5 for ; Thu, 18 Mar 2010 15:06:54 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id BB7C63A6993 for ; Thu, 18 Mar 2010 15:06:53 -0700 (PDT) Received: by fxm5 with SMTP id 5so208944fxm.29 for ; Thu, 18 Mar 2010 15:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=ttRkgjXELvFVG3ZCyp+2sm3r02QE+quQ2/8DwLcjhBM=; b=wcYCvnKT6JPu5zZ3SjzczBA4hMdIJ5/9U5XkQGovn8LX7hQnS9pwduq/qcjC8WBZBv mWwTRANRAP3YVLJBJXVc5PwXKCi5p2OVySf0WI0uM7dRB5zzTWnMnLxLU/b38mhbrPfG 0QHmGOmFZqVnXIgsRqNeSeBU75isQ2E51Utao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=iKDB7oT6eisk4J4lB8SGiEz9C7dTEeu/SyGzi5Sg1mDDzELbyLPurrKOa3tn03ixTt M+wEeIL+powzG1jtxhs3+D4fVpKp4nzFWcYbf1iCLjkXvz4DnFFIOyuonGdZnbb2ANe0 4z94L2/ShXXJsahkXSL3QZ80MJPnYZMwxcRHk= Received: by 10.87.45.14 with SMTP id x14mr6661339fgj.54.1268950020961; Thu, 18 Mar 2010 15:07:00 -0700 (PDT) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id 4sm476871fge.28.2010.03.18.15.06.59 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 15:07:00 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 18:06:57 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r6; KDE/4.4.1; x86_64; ; ) References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> In-Reply-To: <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003181806.57742.richard.alimi@yale.edu> Cc: "Woundy, Richard" Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:06:55 -0000 Hi Sebastian, On Thursday 18 March 2010 5:42:10 pm Sebastian Kiesel wrote: > Hi, > > a technical concern regarding the provisioned bandwidth attribute: > > If a P2P app uses this information for a peer selection strategy like > "try the highest bandwidth tier peers first" or "try the highest > bandwidth tier peers with higher probability", and if there is a swarm > with many peers but very few of them are in the highest bandwidth tier, > the user experience of these premium customers might be worse than for a > customer with lower provisioned bandwidth (even if the P2P app uses flow > control and congestion control, the initial syn packets alone could > overwhelm the premium customer's links). > > So we should be very clear what we want to do with this kind of > information in the application. I think this is a very good point. My personal opinion is that it would be cleaner to avoid third-party inquiries for provisioned bandwidth. For example, this would permit a peer to locally make some estimation (perhaps its "spare" capacity), and advertise that instead. That said, avoiding third-party inquiries also has a couple of drawbacks: 1) In order for a third-party to determine "provisioned" bandwidth, there must be an ALTO Client running at the target IP address. Then, to distribute the provisioned bandwidth to another ALTO Client, it either must be delivered directly directly or through an intermediary using an application-specific protocol (e.g., a P2P tracker, peer exchange, or a DHT). 2) An ALTO Client can "lie" about its provisioned bandwidth. Actually, this could also be seen as an advantage, since it may not be "lying" for malicious reasons. Instead, it may be performing reasonable "adjustments" based on other applications that are also sucking up some of the bandwidth. Using the ALTO redistribution mechanism (where the value is signed by the ALTO Server) would avoid the possibility of lying, but it also means that no such "adjustments" would be possible. Of course, an ALTO Client still has the option to not redistribute its own provisioned bandwidth value in the first place. -- Richard Alimi Department of Computer Science Yale University From sebi@smtp.ehlo.wurstkaes.de Thu Mar 18 15:21:10 2010 Return-Path: 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 8B2383A6944 for ; Thu, 18 Mar 2010 15:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] 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 xsEcDLeZyqbP for ; Thu, 18 Mar 2010 15:21:09 -0700 (PDT) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id 031EC3A67CC for ; Thu, 18 Mar 2010 15:20:37 -0700 (PDT) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1NsO56-0004j6-Px; Thu, 18 Mar 2010 23:20:44 +0100 Date: Thu, 18 Mar 2010 23:20:44 +0100 From: Sebastian Kiesel To: "Woundy, Richard" Message-ID: <20100318222044.GE31395@nat01e.ehlo.wurstkaes.de> References: <070.26eb8a8341e6acbd930c7fda5946b910@tools.ietf.org> <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:21:10 -0000 Rich, On Thu, Mar 18, 2010 at 05:48:04PM -0400, Woundy, Richard wrote: > I agree. > > Here's a slightly different example. The common tier for ISP A may have > provisioned bandwidth of 12 Mbps, and 10 Mbps for ISP B. Assuming that > an application doesn't need 11 Mbps, it may make more sense for the app > to pick an ISP A client 12 times out of 22 (55%), and an ISP B client 10 > times out of 22 (45%), what you describe here sounds very reasonable. But how would you implement it as an algorithm that works for arbitrary BW distributions in the swarm? My first thought, (Probability of picking peer X) := (Prov.BW of peer X) / (Average prov.BW) would exactly cause the problem I described, if there were very many peers with a BW slightly below the average and very few ones with a BW far above the average. I'm not saying that the provisioned bandwidth attribute is useles, but I think we must be very careful in designing algorithms that make use of it. -- Sebastian From richard_woundy@cable.comcast.com Thu Mar 18 15:56:59 2010 Return-Path: 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 A5E913A6A4F for ; Thu, 18 Mar 2010 15:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=-2.099, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 I9ltqQH5H04g for ; Thu, 18 Mar 2010 15:56:58 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 8A0223A69FF for ; Thu, 18 Mar 2010 15:56:58 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78824120; Thu, 18 Mar 2010 18:56:48 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 18:56:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 18:54:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: AcrG6UW492e1mviCQh+1g1zZRHcvlAABKf3B From: "Woundy, Richard" To: X-OriginalArrivalTime: 18 Mar 2010 22:56:49.0884 (UTC) FILETIME=[4B26F1C0:01CAC6EE] Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:56:59 -0000 SG93IGFib3V0Og0KDQooUHJvYmFiaWxpdHkgb2YgcGlja2luZyBwZWVyIFgpIDo9IChQcm92LkJX IG9mIHBlZXIgWCkgLyAoU3VtIHByb3YuQlcpIA0KDQpPciBoZXJlJ3MgYSB0b3RhbGx5IGRpZmZl cmVudCBpZGVhLiBUaGUgY2xpZW50IHN0YXRlcyBhIGJhbmR3aWR0aCBmbG9vciBhbmQgdGhlIHNl cnZlci9zZXJ2aWNlIGVsaW1pbmF0ZXMgcGVlcnMgd2l0aG91dCBhdCBsZWFzdCB0aGF0IG11Y2gg cHJvdmlzaW9uZWQgYmFuZHdpZHRoPz8/IEFuZCBubyByZXNwb25zZSBmcm9tIHNlcnZlci9zZXJ2 aWNlIGlmIHRvbyBmZXcgcGVlcnM/DQoNCi0tIFJpY2gNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQpGcm9tOiBTZWJhc3RpYW4gS2llc2VsIDxpZXRmLWFsdG9Ac2tpZXNlbC5kZT4N ClRvOiBXb3VuZHksIFJpY2hhcmQNCkNjOiBTZWJhc3RpYW4gS2llc2VsIDxpZXRmLWFsdG9Ac2tp ZXNlbC5kZT47IGFsdG9AaWV0Zi5vcmcgPGFsdG9AaWV0Zi5vcmc+DQpTZW50OiBUaHUgTWFyIDE4 IDE4OjIwOjQ0IDIwMTANClN1YmplY3Q6IFJlOiBbYWx0b10gQ29tbWVudHMgb24gcHJvdmlzaW9u ZWQgYmFuZHdpZHRoIGFuZCBBTFRPDQoNClJpY2gsDQoNCk9uIFRodSwgTWFyIDE4LCAyMDEwIGF0 IDA1OjQ4OjA0UE0gLTA0MDAsIFdvdW5keSwgUmljaGFyZCB3cm90ZToNCj4gSSBhZ3JlZS4NCj4g DQo+IEhlcmUncyBhIHNsaWdodGx5IGRpZmZlcmVudCBleGFtcGxlLiBUaGUgY29tbW9uIHRpZXIg Zm9yIElTUCBBIG1heSBoYXZlDQo+IHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBvZiAxMiBNYnBzLCBh bmQgMTAgTWJwcyBmb3IgSVNQIEIuIEFzc3VtaW5nIHRoYXQNCj4gYW4gYXBwbGljYXRpb24gZG9l c24ndCBuZWVkIDExIE1icHMsIGl0IG1heSBtYWtlIG1vcmUgc2Vuc2UgZm9yIHRoZSBhcHANCj4g dG8gcGljayBhbiBJU1AgQSBjbGllbnQgMTIgdGltZXMgb3V0IG9mIDIyICg1NSUpLCBhbmQgYW4g SVNQIEIgY2xpZW50IDEwDQo+IHRpbWVzIG91dCBvZiAyMiAoNDUlKSwgDQoNCndoYXQgeW91IGRl c2NyaWJlIGhlcmUgc291bmRzIHZlcnkgcmVhc29uYWJsZS4gQnV0IGhvdyB3b3VsZCB5b3UNCmlt cGxlbWVudCBpdCBhcyBhbiBhbGdvcml0aG0gdGhhdCB3b3JrcyBmb3IgYXJiaXRyYXJ5IEJXIGRp c3RyaWJ1dGlvbnMNCmluIHRoZSBzd2FybT8NCg0KTXkgZmlyc3QgdGhvdWdodCwNCg0KKFByb2Jh YmlsaXR5IG9mIHBpY2tpbmcgcGVlciBYKSA6PSAoUHJvdi5CVyBvZiBwZWVyIFgpIC8gKEF2ZXJh Z2UgcHJvdi5CVykgDQoNCndvdWxkIGV4YWN0bHkgY2F1c2UgdGhlIHByb2JsZW0gSSBkZXNjcmli ZWQsIGlmIHRoZXJlIHdlcmUgdmVyeSBtYW55DQpwZWVycyB3aXRoIGEgQlcgc2xpZ2h0bHkgYmVs b3cgdGhlIGF2ZXJhZ2UgYW5kIHZlcnkgZmV3IG9uZXMgd2l0aCBhIEJXDQpmYXIgYWJvdmUgdGhl IGF2ZXJhZ2UuDQoNCg0KDQpJJ20gbm90IHNheWluZyB0aGF0IHRoZSBwcm92aXNpb25lZCBiYW5k d2lkdGggYXR0cmlidXRlIGlzIHVzZWxlcywNCmJ1dCBJIHRoaW5rIHdlIG11c3QgYmUgdmVyeSBj YXJlZnVsIGluIGRlc2lnbmluZyBhbGdvcml0aG1zIHRoYXQgbWFrZQ0KdXNlIG9mIGl0Lg0KDQoN Ci0tIFNlYmFzdGlhbg0K From rpenno@juniper.net Thu Mar 18 16:17:50 2010 Return-Path: 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 8675C3A69C9 for ; Thu, 18 Mar 2010 16:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.745 X-Spam-Level: X-Spam-Status: No, score=-3.745 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] 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 AUNcr1qWKAoc for ; Thu, 18 Mar 2010 16:17:47 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id AD2093A69C0 for ; Thu, 18 Mar 2010 16:17:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKS6K0mXhVs5hxCMKCpSP4cXKOH/fjyEab@postini.com; Thu, 18 Mar 2010 16:17:49 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 18 Mar 2010 16:14:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 18 Mar 2010 19:14:55 -0400 From: Reinaldo Penno To: Sebastian Kiesel , "Woundy, Richard" Date: Thu, 18 Mar 2010 19:14:53 -0400 Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: AcrG69PnCV2WT610RQOgpNof+doNIwABPzU2 Message-ID: In-Reply-To: <20100318214210.GD31395@nat01e.ehlo.wurstkaes.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "alto@ietf.org" Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:17:50 -0000 Trying (to get) the peers with the highest actual bandwidth is exactly what P2P protocols do today. The difference is that they take some time to selec= t the better peers through probing, optimistic unchoke, etc. Therefore I would think and agree that if bandwidth (specially provisioned bandwidth as opposed to actual) is part of the decision process, it can throw localization askew and create a security issue. But this is for P2P swarms client based. For CDN and caches this seems to have its uses but I would think that actual bandwidth (some kind of average= ) vs. provisioned would be more useful. Thanks, Reinaldo On 3/18/10 2:42 PM, "Sebastian Kiesel" wrote: > Hi, >=20 > a technical concern regarding the provisioned bandwidth attribute: >=20 > If a P2P app uses this information for a peer selection strategy like > "try the highest bandwidth tier peers first" or "try the highest > bandwidth tier peers with higher probability", and if there is a swarm > with many peers but very few of them are in the highest bandwidth tier, > the user experience of these premium customers might be worse than for a > customer with lower provisioned bandwidth (even if the P2P app uses flow > control and congestion control, the initial syn packets alone could > overwhelm the premium customer's links). >=20 > So we should be very clear what we want to do with this kind of > information in the application. >=20 >=20 > Thinking about this for a while, this problem is not limited to the > provisioned bandwidth. Maybe we need to distinguish between rating > criteria that are commutative (i.e., peer B would be a "good" neighbor > for peer A according to that criterion implies that A would be a "good" > neighbor for B) and those criteria that are not. Using non-commutative > rating criteria might be risky. >=20 > -- Sebastian > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From sebi@smtp.ehlo.wurstkaes.de Thu Mar 18 16:20:03 2010 Return-Path: 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 873F43A69F7 for ; Thu, 18 Mar 2010 16:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] 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 UvxtG2WeHpkG for ; Thu, 18 Mar 2010 16:20:00 -0700 (PDT) Received: from smtp.ehlo.wurstkaes.de (r01e.ehlo.wurstkaes.de [82.139.198.28]) by core3.amsl.com (Postfix) with ESMTP id 363573A69C9 for ; Thu, 18 Mar 2010 16:19:45 -0700 (PDT) Received: from sebi by smtp.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1NsP0K-0005da-Kd; Fri, 19 Mar 2010 00:19:52 +0100 Date: Fri, 19 Mar 2010 00:19:52 +0100 From: Sebastian Kiesel To: "Woundy, Richard" Message-ID: <20100318231952.GF31395@nat01e.ehlo.wurstkaes.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:20:03 -0000 On Thu, Mar 18, 2010 at 06:54:13PM -0400, Woundy, Richard wrote: > How about: > > (Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) better. :) though getting BW info for all peers might be unrealistic > Or here's a totally different idea. The client states a bandwidth > floor and the server/service eliminates peers without at least that > much provisioned bandwidth??? The ALTO reqs draft already says: 5.3. Performance-related rating criteria o The minimum achievable throughput between the resource consumer and the candidate resource provider, which is considered useful by the application (only in ALTO queries), or o An arbitrary upper bound for the throughput from/to the candidate resource provider (only in ALTO replies). This may be, but is not necessarily the provisioned access bandwidth of the candidate resource provider. ... The ALTO client MUST be aware, that with high probability, the actual performance values differ significantly from these upper and lower bounds. In particular, an ALTO client MUST NOT consider the "upper bound for throughput" parameter as a permission to send data at the indicated rate without using congestion control mechanisms. ... Nevertheless, these rating criteria may provide a useful shortcut for quickly excluding candidate resource providers from such probing, if it is known in advance that connectivity is in any case worse than what is considered the minimum useful value by the respective application. -- Sebastian From richard_woundy@cable.comcast.com Thu Mar 18 16:43:12 2010 Return-Path: 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 7B83E3A6BB9 for ; Thu, 18 Mar 2010 16:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 RKA461iP9b4e for ; Thu, 18 Mar 2010 16:43:11 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 4506D3A6BB2 for ; Thu, 18 Mar 2010 16:43:11 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78825305; Thu, 18 Mar 2010 19:43:09 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 19:43:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 18 Mar 2010 19:43:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Comments on provisioned bandwidth and ALTO Thread-Index: AcrG8YmfI1NtaGKTRnuX1R8eaaE4dgAAzdXO From: "Woundy, Richard" To: X-OriginalArrivalTime: 18 Mar 2010 23:43:09.0646 (UTC) FILETIME=[C404F6E0:01CAC6F4] Cc: alto@ietf.org Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:43:12 -0000 PlRoZSBBTFRPIHJlcXMgZHJhZnQgYWxyZWFkeSBzYXlzOg0KDQpPb3BzIEkgc2hvdWxkIGhhdmUg a25vd24gdGhhdC4gOigNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBT ZWJhc3RpYW4gS2llc2VsIDxpZXRmLWFsdG9Ac2tpZXNlbC5kZT4NClRvOiBXb3VuZHksIFJpY2hh cmQNCkNjOiBpZXRmLWFsdG9Ac2tpZXNlbC5kZSA8aWV0Zi1hbHRvQHNraWVzZWwuZGU+OyBhbHRv QGlldGYub3JnIDxhbHRvQGlldGYub3JnPg0KU2VudDogVGh1IE1hciAxOCAxOToxOTo1MiAyMDEw DQpTdWJqZWN0OiBSZTogW2FsdG9dIENvbW1lbnRzIG9uIHByb3Zpc2lvbmVkIGJhbmR3aWR0aCBh bmQgQUxUTw0KDQpPbiBUaHUsIE1hciAxOCwgMjAxMCBhdCAwNjo1NDoxM1BNIC0wNDAwLCBXb3Vu ZHksIFJpY2hhcmQgd3JvdGU6DQo+IEhvdyBhYm91dDoNCj4gDQo+IChQcm9iYWJpbGl0eSBvZiBw aWNraW5nIHBlZXIgWCkgOj0gKFByb3YuQlcgb2YgcGVlciBYKSAvIChTdW0gcHJvdi5CVykgDQoN CmJldHRlci4gOikgdGhvdWdoIGdldHRpbmcgQlcgaW5mbyBmb3IgYWxsIHBlZXJzIG1pZ2h0IGJl IHVucmVhbGlzdGljDQoNCj4gT3IgaGVyZSdzIGEgdG90YWxseSBkaWZmZXJlbnQgaWRlYS4gVGhl IGNsaWVudCBzdGF0ZXMgYSBiYW5kd2lkdGgNCj4gZmxvb3IgYW5kIHRoZSBzZXJ2ZXIvc2Vydmlj ZSBlbGltaW5hdGVzIHBlZXJzIHdpdGhvdXQgYXQgbGVhc3QgdGhhdA0KPiBtdWNoIHByb3Zpc2lv bmVkIGJhbmR3aWR0aD8/PyANCg0KVGhlIEFMVE8gcmVxcyBkcmFmdCBhbHJlYWR5IHNheXM6DQoN CjUuMy4gIFBlcmZvcm1hbmNlLXJlbGF0ZWQgcmF0aW5nIGNyaXRlcmlhDQoNCiAgIG8gIFRoZSBt aW5pbXVtIGFjaGlldmFibGUgdGhyb3VnaHB1dCBiZXR3ZWVuIHRoZSByZXNvdXJjZSBjb25zdW1l cg0KICAgICAgYW5kIHRoZSBjYW5kaWRhdGUgcmVzb3VyY2UgcHJvdmlkZXIsIHdoaWNoIGlzIGNv bnNpZGVyZWQgdXNlZnVsIGJ5DQogICAgICB0aGUgYXBwbGljYXRpb24gKG9ubHkgaW4gQUxUTyBx dWVyaWVzKSwgb3INCg0KICAgbyAgQW4gYXJiaXRyYXJ5IHVwcGVyIGJvdW5kIGZvciB0aGUgdGhy b3VnaHB1dCBmcm9tL3RvIHRoZSBjYW5kaWRhdGUNCiAgICAgIHJlc291cmNlIHByb3ZpZGVyIChv bmx5IGluIEFMVE8gcmVwbGllcykuICBUaGlzIG1heSBiZSwgYnV0IGlzIG5vdA0KICAgICAgbmVj ZXNzYXJpbHkgdGhlIHByb3Zpc2lvbmVkIGFjY2VzcyBiYW5kd2lkdGggb2YgdGhlIGNhbmRpZGF0 ZQ0KICAgICAgcmVzb3VyY2UgcHJvdmlkZXIuDQouLi4NCg0KICAgVGhlIEFMVE8gY2xpZW50IE1V U1QgYmUgYXdhcmUsIHRoYXQgd2l0aCBoaWdoIHByb2JhYmlsaXR5LCB0aGUgYWN0dWFsDQogICBw ZXJmb3JtYW5jZSB2YWx1ZXMgZGlmZmVyIHNpZ25pZmljYW50bHkgZnJvbSB0aGVzZSB1cHBlciBh bmQgbG93ZXINCiAgIGJvdW5kcy4gIEluIHBhcnRpY3VsYXIsIGFuIEFMVE8gY2xpZW50IE1VU1Qg Tk9UIGNvbnNpZGVyIHRoZSAidXBwZXINCiAgIGJvdW5kIGZvciB0aHJvdWdocHV0IiBwYXJhbWV0 ZXIgYXMgYSBwZXJtaXNzaW9uIHRvIHNlbmQgZGF0YSBhdCB0aGUNCiAgIGluZGljYXRlZCByYXRl IHdpdGhvdXQgdXNpbmcgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMuDQoNCi4uLg0KDQog ICBOZXZlcnRoZWxlc3MsIHRoZXNlIHJhdGluZw0KICAgY3JpdGVyaWEgbWF5IHByb3ZpZGUgYSB1 c2VmdWwgc2hvcnRjdXQgZm9yIHF1aWNrbHkgZXhjbHVkaW5nDQogICBjYW5kaWRhdGUgcmVzb3Vy Y2UgcHJvdmlkZXJzIGZyb20gc3VjaCBwcm9iaW5nLCBpZiBpdCBpcyBrbm93biBpbg0KICAgYWR2 YW5jZSB0aGF0IGNvbm5lY3Rpdml0eSBpcyBpbiBhbnkgY2FzZSB3b3JzZSB0aGFuIHdoYXQgaXMN CiAgIGNvbnNpZGVyZWQgdGhlIG1pbmltdW0gdXNlZnVsIHZhbHVlIGJ5IHRoZSByZXNwZWN0aXZl IGFwcGxpY2F0aW9uLg0KDQoNCg0KDQoNCi0tIFNlYmFzdGlhbg0K From richard.alimi@gmail.com Thu Mar 18 17:10:29 2010 Return-Path: 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 6AADC3A6A88 for ; Thu, 18 Mar 2010 17:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 H60Vy1izVD+K for ; Thu, 18 Mar 2010 17:10:27 -0700 (PDT) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id 9958D3A69E1 for ; Thu, 18 Mar 2010 17:10:27 -0700 (PDT) Received: by qyk7 with SMTP id 7so348691qyk.17 for ; Thu, 18 Mar 2010 17:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=5l0xdEqMCbhPem7azqTMn5MOwl2D5bgtNlG4LAIUUng=; b=TGw9XqQa+itpDYUhHPa/by+F4fKT8Om4LJuDEb//n4hfNts5ST9BK3so293CSav30X FoVYh2xXm1X/1w00bfrlXebvsgpTi453+icW5TxkxwRF18oIJtfum0nTT/RbQQmheL7g a+MYoM0SlYG1gC/EaImo5kky5xrAPV4KsPdvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=HH2VlPbYQyiON/I0kYlqKDG1OK5L4Ci8kAPIjSFpVY43hQKej1dXpg3CXpQupIzI5Q BCYZJ9mmPfTqv8eyiCEGeKJRNBCneCGQGg7WItIaTkzGFiW8VWQpYKX1PvIW3iAjspkq aZrV/yyOYCqChmBZzghYkcY3HALSK+CQHXkAU= Received: by 10.229.45.80 with SMTP id d16mr2962037qcf.69.1268957436800; Thu, 18 Mar 2010 17:10:36 -0700 (PDT) Received: from laptop.localnet (adsl-75-43-130-73.dsl.wlfrct.sbcglobal.net [75.43.130.73]) by mx.google.com with ESMTPS id 21sm332228qyk.13.2010.03.18.17.10.35 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 17:10:35 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 20:10:33 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r10; KDE/4.4.1; x86_64; ; ) References: <20100318231952.GF31395@nat01e.ehlo.wurstkaes.de> In-Reply-To: <20100318231952.GF31395@nat01e.ehlo.wurstkaes.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003182010.33799.richard.alimi@yale.edu> Cc: "Woundy, Richard" Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 00:10:29 -0000 Another method for doing peer selection utilizing some measure of provisioned bandwidth is the optimization that we used in the P4P trials. In particular, we used peer selection guided by a technique called bandwidth matching. For details, see the section titled "Application with Upload/Download Matching" on Page 4 (labeled page 354) of the Sigcomm 2008 paper: http://ccr.sigcomm.org/online/?q=node/402 Related to Reinaldo's comment about the interaction with localization, we took the approach that the application would first try to maximize its objective (e.g., maximize the total matched bandwidth). Then, we recompute peering guidance to optimize for network efficiency (i.e., minimize ALTO costs) under the constraint that the total matched bandwidth is at least a certain percentage (e.g., 80%) of the optimal value. Put another way, the application sacrifices up to a certain (application-configured) percentage in favor of network efficiency. Nevertheless, in the trials, we did see increased application performance (in addition to increased network efficiency). There are a couple of things to note about the the technique applied here: 1) This optimization was done by the tracker when doing peer selection for newly-joined peers (and peers getting new peer lists from the tracker), and not locally by the peers themselves. 2) Aggregation was applied at the PID level for scalability purposes. The formulation described here can face scalability problems when done swarm- wide without such aggregation, but I mention it here as another possibility for computing peering weights that utilizes bandwidth jointly with localization. -- Richard Alimi Department of Computer Science Yale University On Thursday 18 March 2010 7:19:52 pm Sebastian Kiesel wrote: > On Thu, Mar 18, 2010 at 06:54:13PM -0400, Woundy, Richard wrote: > > How about: > > > > (Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) > > better. :) though getting BW info for all peers might be unrealistic > > > Or here's a totally different idea. The client states a bandwidth > > floor and the server/service eliminates peers without at least that > > much provisioned bandwidth??? > > The ALTO reqs draft already says: > > 5.3. Performance-related rating criteria > > o The minimum achievable throughput between the resource consumer > and the candidate resource provider, which is considered useful by > the application (only in ALTO queries), or > > o An arbitrary upper bound for the throughput from/to the candidate > resource provider (only in ALTO replies). This may be, but is not > necessarily the provisioned access bandwidth of the candidate > resource provider. > ... > > The ALTO client MUST be aware, that with high probability, the actual > performance values differ significantly from these upper and lower > bounds. In particular, an ALTO client MUST NOT consider the "upper > bound for throughput" parameter as a permission to send data at the > indicated rate without using congestion control mechanisms. > > ... > > Nevertheless, these rating > criteria may provide a useful shortcut for quickly excluding > candidate resource providers from such probing, if it is known in > advance that connectivity is in any case worse than what is > considered the minimum useful value by the respective application. > > > > > > -- Sebastian > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From richard.alimi@gmail.com Thu Mar 18 17:17:53 2010 Return-Path: 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 6CE853A6BD6 for ; Thu, 18 Mar 2010 17:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 qoQBkV69Ct8g for ; Thu, 18 Mar 2010 17:17:52 -0700 (PDT) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id 86DD43A6BDE for ; Thu, 18 Mar 2010 17:17:52 -0700 (PDT) Received: by qyk7 with SMTP id 7so353554qyk.17 for ; Thu, 18 Mar 2010 17:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=/R+oeMshQlZmYoNFpPXTUZFJSTj7EFGuZKc40IA+Lp4=; b=PpWX4O96+aFIHU00lkQsN35FYoszizrBqtsZOr/vpjqphrsKuntlJhbhWQqqQrtwih XEcfFa16KKh1tWyCqQx19//jSnmMAhbsC1n/KeBfUGlY1aMIpTjnIjRwUWbe7vtaI4yQ XwzlUoOq5YhdoVwVrGuxk6cmDnt+PkhhYIhVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=BElAhQSLLLD32uO7VPBDwqSfNyGN20AVDcDBR0kuu9UZwzeMQLd1iny0bCdBKHoUtZ +GHB6n9X6xFiAJaaRbv0QnJzudeDt6NyvaQ7Ch7RKrLFn+9BsVReOgcFNhXqVbNtLhoq 5NQ8oeusMG//pB+4PAI7sH2FmhsHViCPTwevY= Received: by 10.224.84.194 with SMTP id k2mr422018qal.190.1268957881194; Thu, 18 Mar 2010 17:18:01 -0700 (PDT) Received: from laptop.localnet (adsl-75-43-130-73.dsl.wlfrct.sbcglobal.net [75.43.130.73]) by mx.google.com with ESMTPS id 21sm337100qyk.9.2010.03.18.17.18.00 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 17:18:00 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Thu, 18 Mar 2010 20:17:58 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r10; KDE/4.4.1; x86_64; ; ) References: <20100318231952.GF31395@nat01e.ehlo.wurstkaes.de> <201003182010.33799.richard.alimi@yale.edu> In-Reply-To: <201003182010.33799.richard.alimi@yale.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003182017.59066.richard.alimi@yale.edu> Cc: "Woundy, Richard" Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 00:17:53 -0000 On Thursday 18 March 2010 8:10:33 pm Richard Alimi wrote: [ .. snip .. ] > There are a couple of things to note about the the technique applied here: > 1) This optimization was done by the tracker when doing peer selection for > newly-joined peers (and peers getting new peer lists from the tracker), > and not locally by the peers themselves. > 2) Aggregation was applied at the PID level for scalability purposes. I should also note one other thing: the bandwidth matching technique was formulated for, and applied to filesharing. -- Richard Alimi Department of Computer Science Yale University From enrico.marocco@telecomitalia.it Thu Mar 18 23:29:30 2010 Return-Path: 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 50A1B3A66B4 for ; Thu, 18 Mar 2010 23:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.286 X-Spam-Level: ** X-Spam-Status: No, score=2.286 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 jGWKKn0NwuKa for ; Thu, 18 Mar 2010 23:29:29 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 5985E3A67FF for ; Thu, 18 Mar 2010 23:29:28 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 19 Mar 2010 07:29:37 +0100 Received: from [172.16.82.18] (163.162.180.246) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 19 Mar 2010 07:29:36 +0100 Message-ID: <4BA319CA.3000006@telecomitalia.it> Date: Fri, 19 Mar 2010 07:29:30 +0100 From: Enrico Marocco User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Woundy, Richard" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010608000306090600080000" Cc: "alto@ietf.org" , "Martin.Stiemerling@neclab.eu" Subject: Re: [alto] Comments on provisioned bandwidth and ALTO X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 06:29:30 -0000 --------------ms010608000306090600080000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Woundy, Richard wrote: >> The network maps (and the associated cost map) is fine as long as >> the IP prefix allocation in an ISP's network is stable. Where >> stable means changes of the IP prefix allocation are happening in >> the range of weeks. > > In the networks I am familiar with (cable), most of the time the IP > address is fairly stable, with DHCP lease times on the order of > several days or a week. And the same lease is often renewed to the > same DHCP client (even on a modem reboot), so a DHCP client could > maintain the same IP address for months at a time. So most of the > time, most of the information in a network map will be fairly stable. > > > (On non-cable networks, your mileage may vary.) On a non-cable network I'm somewhat familiar with, we have observed that about 60% of the residential access lines change address in 24h, while the remaining ~40% remains fairly stable for several days (i.e. in 2 days 40% of the lines maintain the same address, in 7 days 38%). This is of course a very particular case, and the numbers are likely to vary whenever address pools got reallocated -- i.e. quite often, in nationwide ISPs. -- Ciao, Enrico --------------ms010608000306090600080000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTAwMzE5MDYyOTMwWjAjBgkqhkiG9w0BCQQxFgQU1Um39pwxcY1Q9prG +xW8VxXB1E8wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQAjZJAZ10efPSyCD8mveN7gwzWn5qHhWcKM8cLTS7ZnS8vk 478koMQJu/9noxEZc6EFcXGp5D5kbJe9Vrhirif8l+yC/w3L0tzMli7m4F8HWHJTnzU5C5eN pF/Jz6XoePwhI9Drb5bAStxDgaRRCuwy+RboNISyI/c8HX1HFe09NDqqYpnVYxLdOxAyRX6r 99TShPrCbtcAcxrdGERkFwtKu+fkVtMnOdkp8GBCdfbwPX1ys32oXfiOT//VVfsSh1Mmaps3 o/8xyi1PUsd+aTv5/LiVF1u6I6RWLI4xDNThum64Fd5Y6B43EhTKkRWImasH0ICkZ3f4iYJa F3LJW387AAAAAAAA --------------ms010608000306090600080000-- From Martin.Thomson@andrew.com Mon Mar 22 18:57:30 2010 Return-Path: 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 9E35A3A68CD for ; Mon, 22 Mar 2010 18:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=-1.459, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 M58pt9sO8T1K for ; Mon, 22 Mar 2010 18:57:29 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id D6C823A680C for ; Mon, 22 Mar 2010 18:57:29 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:40258 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S14976075Ab0CWB5r convert rfc822-to-8bit (ORCPT ); Mon, 22 Mar 2010 20:57:47 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 22 Mar 2010 20:57:47 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 23 Mar 2010 09:57:45 +0800 From: "Thomson, Martin" To: "alto@ietf.org" Date: Tue, 23 Mar 2010 09:57:44 +0800 Thread-Topic: alto-protocol, REST and protocol design Thread-Index: AQHKyiw66uisQn7FiEykxibQIJR07Q== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24FBECA@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [alto] alto-protocol, REST and protocol design X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 01:57:30 -0000 Taking Lisa's mic comments a little further, I'd like to point out that what is in this draft isn't a particularly faithful embodiment of a RESTful service. In my opinion, a RESTful service would have more resources than are identified in the protocol. Of course, the degree to which anything can be considered "RESTful" seems to be highly subjective. To me, this seems more like XXX over HTTP than a use of HTTP that follows the REST axioms. The question is, whether you are able to model your application (i.e. ALTO) with resources. I'm not sure how that can be done within the constraints that you have, but it seems that more could be done. For instance, included amoung those resources would be indexes, which might solve your capabilities/multiple server problem. That makes the server capabilities discoverable. There might be a combinatorial explosion if you allow for freedom on many axes, but I don't actually think that this is a high risk, given my limited understanding of the current solution. However, if clients are given the ability, as the draft describes, to specify multiple input values to query the database, as is the case with map filtering, then REST is less applicable. Such aspects of the protocol might be hard to fit into a pure resource model. The risk here is that the protocol reinforces client-server dependencies. One potential thing to look at is URI templates, which constrain the form of URIs based on server preferences (rather than client). While it still gives the client greater control over the server than might be ideal, it at least reduces some of the degrees of freedom and (slightly) loosens the coupling. I recommend a little more background reading on REST- you may come to the conclusion that ALTO over HTTP is preferable, or you might find a subset of REST-like capabilities that best fit this. --Martin ...and while I'm at it... I also have to support Lisa's suggestion on content negotiation (on media type) for version negotiation. That works very well, in my experience. It is revealing when you talk about "persisting" responses. That's a caching function and there's good support for that in HTTP. Comments on the mic about JSON and XML and validation were particularly good. The "schema" definition in the document is nice, but hard to use in tools. XML schema has good tool support, which is not necessarily true for the JSON stuff. I'm not up to date on the mapping status between XML and JSON, but I do know that Jersey and JAXB provide these functions. From richard.alimi@gmail.com Tue Mar 23 08:29:56 2010 Return-Path: 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 D827E3A6C02 for ; Tue, 23 Mar 2010 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 pA2-zfthAX6p for ; Tue, 23 Mar 2010 08:29:55 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 5A31E3A6358 for ; Tue, 23 Mar 2010 08:29:53 -0700 (PDT) Received: by ewy8 with SMTP id 8so550636ewy.28 for ; Tue, 23 Mar 2010 08:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=X/ccAJfw1/hWi4FhQuy4IH6yGwDWZCcWm9qB33S8pvM=; b=K37G8HssSH8+PJw4RMtnqnDhQzyfzV0HLD80lPooD/Ve+WlZNkTgbARZnEjj9JDdo1 dBC7ptR/PgO+xR1urSLiGdpiATz6bSd0ZDooC84TOYFTCeeDXPsMesmeKNuUrYoNUOxs L1yShmUYHDggsx8H/o5bgJFiZzhJLKtBVYdZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=xj+Tb8+ENFoDdlfrdv9Zlk6lcssNJeaYRNWr+qY6Fu6XB5kExC3vrAN5oSUJC+uVTf Vstm9/uVV/1ZYW0P9ZhyWcqDZJQQlT67wOEPcdZQvAmKk1d3QMTcxBOq8EThSUL8vZo9 CUyHAY3MCqPsVOpdLQa8js3aUBWSGAjoeA0AI= Received: by 10.213.1.132 with SMTP id 4mr1028339ebf.40.1269358206125; Tue, 23 Mar 2010 08:30:06 -0700 (PDT) Received: from laptop.localnet ([130.129.30.227]) by mx.google.com with ESMTPS id 14sm2942455ewy.14.2010.03.23.08.30.03 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 08:30:04 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: alto@ietf.org Date: Tue, 23 Mar 2010 11:28:31 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r10; KDE/4.4.1; x86_64; ; ) References: <8B0A9FCBB9832F43971E38010638454F03E24FBECA@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24FBECA@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003231128.32126.richard.alimi@yale.edu> Subject: Re: [alto] alto-protocol, REST and protocol design X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 15:29:56 -0000 Hi Martin, Thank you for the feedback and your comments during the session. I agree there is a tradeoff between how REST-ful we really want to make this, and this is exactly the discussion we were hoping to get from the WG to get a good, clean specification. Please see below for some specific comments: On Monday 22 March 2010 9:57:44 pm Thomson, Martin wrote: > Taking Lisa's mic comments a little further, I'd like to point out that > what is in this draft isn't a particularly faithful embodiment of a > RESTful service. I'd agree with this, but as is mentioned below, we may not actually want something REST-ful to the extent that _everything_ is a resource. > In my opinion, a RESTful service would have more resources than are > identified in the protocol. Of course, the degree to which anything can > be considered "RESTful" seems to be highly subjective. To me, this seems > more like XXX over HTTP than a use of HTTP that follows the REST axioms. > > The question is, whether you are able to model your application (i.e. ALTO) > with resources. I'm not sure how that can be done within the constraints > that you have, but it seems that more could be done. For certain services, such as the Map service, this is already using resources. However, a couple of other current limitations in the Map service (that might be exposed by providing more Resources) are: 1) It only provides maps for the default cost type: This might be rectified by having an interface such as: /map/core/pid/cost/routingcost /map/core/pid/cost/hopcount /map/core/pid/cost/ where each resource is a map of a different cost type. 2) Depending on how we handle IPv4/v6, we might also parametrize maps by the address family provided in them. (However, given the WG discussion on Monday, we still have some work to do in figuring out the use cases and what types of preferences need to be conveyed before working to specify anything.) Currently we have taken the approach to just make the Network Maps and the Cost Maps as the resources exposed by the server (with the simplification that the Map Service provides a view of the Cost Map with only the default cost type.) To go a bit further, perhaps we can identify other ways to define the ALTO Server's resources that are exposed (or alternatively, which parameters make the most sense to put in the path instead of the query-string or body). One way is like I described it above, where there is a single Network Map resource, and multiple Cost Map resources (one for each cost type defined by the ALTO Server). > For instance, included amoung those resources would be indexes, which might > solve your capabilities/multiple server problem. That makes the server > capabilities discoverable. There might be a combinatorial explosion if > you allow for freedom on many axes, but I don't actually think that this > is a high risk, given my limited understanding of the current solution. This is certainly something that we can think about here. Related to this point, another thing that we were trying to do in the design (adopted from the Infoexport proposal) was to make deployment of the required ALTO interfaces as simple as distributing a few static files from a web server. Personally, I see this as appealing since it can lower the barrier towards deploying an ALTO Server for an ISP, since all that would need to be done is encode the ALTO information in a particular format and post it to a web server. To get certain added functionality, another solution might be needed, but at least the required parts would be extremely simple. > However, if clients are given the ability, as the draft describes, to > specify multiple input values to query the database, as is the case with > map filtering, then REST is less applicable. Such aspects of the protocol > might be hard to fit into a pure resource model. > > The risk here is that the protocol reinforces client-server dependencies. Agreed, but I also agree with you and Lisa that we may want to extend the Resource model and look at putting some of the parameters in the path instead. > One potential thing to look at is URI templates, which constrain the form > of URIs based on server preferences (rather than client). While it still > gives the client greater control over the server than might be ideal, it > at least reduces some of the degrees of freedom and (slightly) loosens the > coupling. Thanks for the suggestion here. This is something that we can at least explore. > I recommend a little more background reading on REST- you may come to the > conclusion that ALTO over HTTP is preferable, or you might find a subset > of REST-like capabilities that best fit this. The idea in the design thus far was to go down the REST route, and see how far it made sense to go. It seemed clear (to me at least) that we had a number of cases where either (1) there were quite a few parameters that needed to be passed, (2) an arbitrary-length list of values needed to be passed, or (3) the data being passed to the ALTO Server actually had some structure to it. In that sense, forcing the design into a pure REST interface appeared to be too limiting for our needs. > > --Martin > > ...and while I'm at it... > > I also have to support Lisa's suggestion on content negotiation (on media > type) for version negotiation. That works very well, in my experience. I would tend to agree as well. The tradeoff here is that an implementation may no longer be as simple as "copy a few files to a web server". While I find it attractive to do that way, I also realize that a good, clean design may be contrary to that implementation. > It is revealing when you talk about "persisting" responses. That's a > caching function and there's good support for that in HTTP. > > Comments on the mic about JSON and XML and validation were particularly > good. The "schema" definition in the document is nice, but hard to use in > tools. XML schema has good tool support, which is not necessarily true > for the JSON stuff. I'm not up to date on the mapping status between XML > and JSON, but I do know that Jersey and JAXB provide these functions. Yes, certainly. I would personally be a bit hesitant to constrain ourselves to using a particular tool where there is no standard. In particular, I think it would be dangerous to go the route of defining an XML schema, and then using a particular (non-standardized) tool to convert it to JSON. Such an approach means that we are at the mercy of the particular translation that would be done, both in terms of whether it is "clean" and also updates to the tool that might affect the translation. -- Richard Alimi Department of Computer Science Yale University From Martin.Thomson@andrew.com Tue Mar 23 09:43:03 2010 Return-Path: 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 95C9A3A6975 for ; Tue, 23 Mar 2010 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 DlYjWmX8fkXo for ; Tue, 23 Mar 2010 09:43:02 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 5E2843A68C0 for ; Tue, 23 Mar 2010 09:43:02 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:12379 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S198281Ab0CWQnV convert rfc822-to-8bit (ORCPT ); Tue, 23 Mar 2010 11:43:21 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 11:43:21 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 24 Mar 2010 00:43:17 +0800 From: "Thomson, Martin" To: Richard Alimi , "alto@ietf.org" Date: Wed, 24 Mar 2010 00:43:16 +0800 Thread-Topic: [alto] alto-protocol, REST and protocol design Thread-Index: AcrKnbuhfuk/WpsWQVmlfFpug+Kp2gAA3Irw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24FBECD@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24FBECA@SISPE7MB1.commscope.com>, <201003231128.32126.richard.alimi@yale.edu> In-Reply-To: <201003231128.32126.richard.alimi@yale.edu> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [alto] alto-protocol, REST and protocol design X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:43:03 -0000 Hi Richard, A few minor additions and suggestions, but I think that you have the right idea :) >For certain services, such as the Map service, this is already using >resources. However, a couple of other current limitations in the Map service >(that might be exposed by providing more Resources) are: >1) It only provides maps for the default cost type: > This might be rectified by having an interface such as: > /map/core/pid/cost/routingcost > /map/core/pid/cost/hopcount > /map/core/pid/cost/ > where each resource is a map of a different cost type. Might I suggest that you stop using these sorts of names, and start talking about the document formats that you intend to create? The actual URL used for any particular resource is unimportant - the data is the important thing. With hyperlinking, the server is able to choose how to name resources. For all these "cost" resources, they might share a common format, but the context that hyperlinks to these resources might include additional supporting data that identifies the resource, e.g. { "costmaps" : [ { "url" : "/this/is/not/important/", "type" : "routingcost" }, { "url" : "whatever", "type" : "hopcount" }, ... ] } > 2) Depending on how we handle IPv4/v6, we might also parametrize maps by the > address family provided in them. (However, given the WG discussion on > Monday, we still have some work to do in figuring out the use cases and > what types of preferences need to be conveyed before working to specify > anything.) That leads to more permutations, more resources. The only risk you run is combinatorial explosion. That's where the templating thing might help. (I'm not a big fan of URI templating, it's only a marginal improvement over query parameters.) >Currently we have taken the approach to just make the Network Maps and the >Cost Maps as the resources exposed by the server (with the simplification that >the Map Service provides a view of the Cost Map with only the default cost >type.) These sorts of constraints can help resource proliferation. >To go a bit further, perhaps we can identify other ways to define the ALTO >Server's resources that are exposed (or alternatively, which parameters make >the most sense to put in the path instead of the query-string or body). The way that the current draft describes the use of request bodies is worrisome. Bodies in GET requests, which is almost implied, are inadvisable. For your more complicated requests, it's possible that you want a way to create a filtered resource, using POST is probably necessary. >> For instance, included amoung those resources would be indexes, which might >> solve your capabilities/multiple server problem. That makes the server >> capabilities discoverable. There might be a combinatorial explosion if >> you allow for freedom on many axes, but I don't actually think that this >> is a high risk, given my limited understanding of the current solution. > >This is certainly something that we can think about here. Related to this >point, another thing that we were trying to do in the design (adopted from the >Infoexport proposal) was to make deployment of the required ALTO interfaces as >simple as distributing a few static files from a web server. Personally, I >see this as appealing since it can lower the barrier towards deploying an ALTO >Server for an ISP, since all that would need to be done is encode the ALTO >information in a particular format and post it to a web server. To get >certain added functionality, another solution might be needed, but at least >the required parts would be extremely simple. See the above example JSON for a concrete instance of what an index might look like. This doesn't preclude deployment of static documents, it actually makes it easier in some sense, because you can put files where it is convenient. An index solves all your deployment problems. That also obviates all the "here's another server" and the "and here are my capabilities" functions. You provide a URL, describe its characteristics and it doesn't matter where that URL is hosted. >> The risk here is that the protocol reinforces client-server dependencies. > >Agreed, but I also agree with you and Lisa that we may want to extend the >Resource model and look at putting some of the parameters in the path instead. It helps if you don't think of it like this. "Parameters in the path" leads to the coupling I'm talking about. Think of it more in terms of resources that each have various characteristics. An _implementation_ might use path components or even query strings, but that's a server and implementation choice. >The idea in the design thus far was to go down the REST route, and see how far >it made sense to go. It seemed clear (to me at least) that we had a number of >cases where either (1) there were quite a few parameters that needed to be >passed, (2) an arbitrary-length list of values needed to be passed, or (3) the >data being passed to the ALTO Server actually had some structure to it. In >that sense, forcing the design into a pure REST interface appeared to be too >limiting for our needs. And that's where you might come to the conclusion that REST doesn't work for you. But it's not necessarily doomed. One potential pattern for dealing with arbitrary request complexity for an application like this is: - Send a POST request with a body that has the complex document; the response identifies 303 (See Other) with a Location URI - Client sends a GET to the identified resource to retrieve data This adds a round-trip, but not necessarily, but it's possible that the 303 body could include the desired data. This leaves the server with control over the resources and how they are identified. It also means that the client can repeat the request without the POST. The response is cacheable. >> I also have to support Lisa's suggestion on content negotiation (on media >> type) for version negotiation. That works very well, in my experience. > >I would tend to agree as well. The tradeoff here is that an implementation >may no longer be as simple as "copy a few files to a web server". While I >find it attractive to do that way, I also realize that a good, clean design >may be contrary to that implementation. Version negotiation is going to require some work. That's probably unavoidable. If you need static files, then you can deal with the content negotiation with redirection that points at the static files. > I would personally be a bit hesitant to constrain ourselves to using a particular tool where there is no standard. In particular, I think it would be dangerous to go the route of defining an XML schema, and then using a particular (non-standardized) tool to convert it to JSON. Oh no, you would never want to do that; that was merely an existence proof. You would have to define (or steal) a mapping. It's actually relatively straightforward - the JAXB JSR (I forget the number) effectively defines this mapping and it's not that big. --Martin >-- >Richard Alimi >Department of Computer Science >Yale University From richard.alimi@gmail.com Tue Mar 23 11:53:00 2010 Return-Path: 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 87C273A6A20 for ; Tue, 23 Mar 2010 11:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 2HMaUFXiHnH7 for ; Tue, 23 Mar 2010 11:52:59 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id B8C4A3A69D5 for ; Tue, 23 Mar 2010 11:52:58 -0700 (PDT) Received: by fxm26 with SMTP id 26so4373462fxm.15 for ; Tue, 23 Mar 2010 11:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=+CvhdjQ4Wqgy6qnhhrNJNXjN4slol8klBl82n/ssVSE=; b=L/pzozDHTWyP8WhMQyFwfkq4dIxV2qbx2H10MHpDno8nAPy666pALxm8hQyZLlBcC0 gX8tbuQ9NGL1SDarXhSmgKd+CIS0zUtqTX+GqTAJjtDSPNa9HIaYYFk9BUosHPCqQJ9D /qa5PcdcX6DFuVxmO592XgB/lPOyH3IRBB2wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=CxC2Pr3nLn4D3YVYktgIVS95cYFhSzqAiU4TkjEfmFAFfKTs/+smplyUDwyVmGyTXx ptWJPsoBKL7BficotibyobvCbYk4BnbuX3RTXdH7FrciU36evYN4dBepvu9kMWQ8Iqw2 VxNf6Z0TeFLf6jDL4cB0rWiREgHHWG3TRu7Xw= Received: by 10.223.58.71 with SMTP id f7mr3176654fah.45.1269370394699; Tue, 23 Mar 2010 11:53:14 -0700 (PDT) Received: from laptop.localnet ([130.129.30.227]) by mx.google.com with ESMTPS id 35sm2958076fkt.37.2010.03.23.11.53.12 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 11:53:13 -0700 (PDT) Sender: Richard Alimi From: Richard Alimi To: "Thomson, Martin" Date: Tue, 23 Mar 2010 14:49:15 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.31-gentoo-r10; KDE/4.4.1; x86_64; ; ) References: <8B0A9FCBB9832F43971E38010638454F03E24FBECA@SISPE7MB1.commscope.com> <201003231128.32126.richard.alimi@yale.edu> <8B0A9FCBB9832F43971E38010638454F03E24FBECD@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24FBECD@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003231449.15447.richard.alimi@yale.edu> Cc: "alto@ietf.org" Subject: Re: [alto] alto-protocol, REST and protocol design X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:53:00 -0000 Hi Martin, Thank you again for the comments. I think we do have more work to do in terms of evaluating the design decisions, but I will simply mention here that in one of the earlier drafts (before this was a WG document), we had taken the route of providing an index to the available services. See: http://tools.ietf.org/html/draft-penno-alto-protocol-01#section-5.1 Of course, what is described there is still more limited than what you describe below. However, one of the arguments against this particular interface was that the afforded flexibility was too complex for our particular scenario. -- Richard Alimi Department of Computer Science Yale University On Tuesday 23 March 2010 12:43:16 pm Thomson, Martin wrote: > Hi Richard, > > A few minor additions and suggestions, but I think that you have the right > idea :) > > >For certain services, such as the Map service, this is already using > >resources. However, a couple of other current limitations in the Map > >service (that might be exposed by providing more Resources) are: > > > >1) It only provides maps for the default cost type: > > This might be rectified by having an interface such as: > > /map/core/pid/cost/routingcost > > /map/core/pid/cost/hopcount > > /map/core/pid/cost/ > > > > where each resource is a map of a different cost type. > > Might I suggest that you stop using these sorts of names, and start talking > about the document formats that you intend to create? The actual URL used > for any particular resource is unimportant - the data is the important > thing. With hyperlinking, the server is able to choose how to name > resources. > > For all these "cost" resources, they might share a common format, but the > context that hyperlinks to these resources might include additional > supporting data that identifies the resource, e.g. > > { "costmaps" : [ { "url" : "/this/is/not/important/", "type" : > "routingcost" }, { "url" : "whatever", "type" : "hopcount" }, ... ] } > > > 2) Depending on how we handle IPv4/v6, we might also parametrize maps by > > the > > > > address family provided in them. (However, given the WG discussion on > > Monday, we still have some work to do in figuring out the use cases and > > what types of preferences need to be conveyed before working to specify > > anything.) > > That leads to more permutations, more resources. The only risk you run is > combinatorial explosion. That's where the templating thing might help. > (I'm not a big fan of URI templating, it's only a marginal improvement > over query parameters.) > > >Currently we have taken the approach to just make the Network Maps and the > >Cost Maps as the resources exposed by the server (with the simplification > >that the Map Service provides a view of the Cost Map with only the > >default cost type.) > > These sorts of constraints can help resource proliferation. > > >To go a bit further, perhaps we can identify other ways to define the ALTO > >Server's resources that are exposed (or alternatively, which parameters > >make the most sense to put in the path instead of the query-string or > >body). > > The way that the current draft describes the use of request bodies is > worrisome. Bodies in GET requests, which is almost implied, are > inadvisable. For your more complicated requests, it's possible that you > want a way to create a filtered resource, using POST is probably > necessary. > > >> For instance, included amoung those resources would be indexes, which > >> might solve your capabilities/multiple server problem. That makes the > >> server capabilities discoverable. There might be a combinatorial > >> explosion if you allow for freedom on many axes, but I don't actually > >> think that this is a high risk, given my limited understanding of the > >> current solution. > > > >This is certainly something that we can think about here. Related to this > >point, another thing that we were trying to do in the design (adopted from > >the Infoexport proposal) was to make deployment of the required ALTO > >interfaces as simple as distributing a few static files from a web > >server. Personally, I see this as appealing since it can lower the > >barrier towards deploying an ALTO Server for an ISP, since all that would > >need to be done is encode the ALTO information in a particular format and > >post it to a web server. To get certain added functionality, another > >solution might be needed, but at least the required parts would be > >extremely simple. > > See the above example JSON for a concrete instance of what an index might > look like. This doesn't preclude deployment of static documents, it > actually makes it easier in some sense, because you can put files where it > is convenient. An index solves all your deployment problems. > > That also obviates all the "here's another server" and the "and here are my > capabilities" functions. You provide a URL, describe its characteristics > and it doesn't matter where that URL is hosted. > > >> The risk here is that the protocol reinforces client-server > >> dependencies. > > > >Agreed, but I also agree with you and Lisa that we may want to extend the > >Resource model and look at putting some of the parameters in the path > >instead. > > It helps if you don't think of it like this. "Parameters in the path" leads > to the coupling I'm talking about. Think of it more in terms of resources > that each have various characteristics. An _implementation_ might use > path components or even query strings, but that's a server and > implementation choice. > > >The idea in the design thus far was to go down the REST route, and see how > >far it made sense to go. It seemed clear (to me at least) that we had a > >number of cases where either (1) there were quite a few parameters that > >needed to be passed, (2) an arbitrary-length list of values needed to be > >passed, or (3) the data being passed to the ALTO Server actually had some > >structure to it. In that sense, forcing the design into a pure REST > >interface appeared to be too limiting for our needs. > > And that's where you might come to the conclusion that REST doesn't work > for you. But it's not necessarily doomed. > > One potential pattern for dealing with arbitrary request complexity for an > application like this is: > > - Send a POST request with a body that has the complex document; the > response identifies 303 (See Other) with a Location URI - Client sends a > GET to the identified resource to retrieve data > > This adds a round-trip, but not necessarily, but it's possible that the 303 > body could include the desired data. > > This leaves the server with control over the resources and how they are > identified. It also means that the client can repeat the request without > the POST. The response is cacheable. > > >> I also have to support Lisa's suggestion on content negotiation (on > >> media type) for version negotiation. That works very well, in my > >> experience. > > > >I would tend to agree as well. The tradeoff here is that an > >implementation may no longer be as simple as "copy a few files to a web > >server". While I find it attractive to do that way, I also realize that > >a good, clean design may be contrary to that implementation. > > Version negotiation is going to require some work. That's probably > unavoidable. If you need static files, then you can deal with the content > negotiation with redirection that points at the static files. > > > I would personally be a bit hesitant to constrain ourselves > > to using a particular tool where there is no standard. In particular, I > think it would be dangerous to go the route of defining an XML schema, and > then using a particular (non-standardized) tool to convert it to JSON. > > Oh no, you would never want to do that; that was merely an existence proof. > You would have to define (or steal) a mapping. It's actually relatively > straightforward - the JAXB JSR (I forget the number) effectively defines > this mapping and it's not that big. > > --Martin > > >-- > >Richard Alimi > >Department of Computer Science > >Yale University From melodysong@huawei.com Wed Mar 24 18:28:34 2010 Return-Path: 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 56E7D3A697F for ; Wed, 24 Mar 2010 18:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.331 X-Spam-Level: ** X-Spam-Status: No, score=2.331 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6] 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 ZL9+hla+rsuo for ; Wed, 24 Mar 2010 18:28:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6234D3A695C for ; Wed, 24 Mar 2010 18:28:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZT00K1ODG5ZT@szxga03-in.huawei.com> for alto@ietf.org; Thu, 25 Mar 2010 09:28:53 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZT002KHDG5O4@szxga03-in.huawei.com> for alto@ietf.org; Thu, 25 Mar 2010 09:28:53 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.28.136]) by szxmc03-in.huawei.com (mshttpd); Thu, 25 Mar 2010 09:28:53 +0800 Date: Thu, 25 Mar 2010 09:28:53 +0800 From: songhaibin 64081 To: alto@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [alto] A comment to H12 protocol X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 01:28:34 -0000 Hi, My feeling after this presentation is that, if we replace the PID with explicit IP prefix in the cost map of the current ALTO protocol draft(may need additional filtering function defined in the new version), we can get the similar result with H12 protocol. The difference is that in H12, the server ranks the IP prefixes for the requester, while in ALTO protocol draft, it gives the "cost" between them. Are there any other differences I missed? Does H12 need to consider NAT(esp. carrier grade NAT) problem? I just try to understand more about it. Thanks, Haibin From melodysong@huawei.com Wed Mar 24 18:46:33 2010 Return-Path: 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 3D2483A6850 for ; Wed, 24 Mar 2010 18:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.783 X-Spam-Level: ** X-Spam-Status: No, score=2.783 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 XEt9iF9zXL9f for ; Wed, 24 Mar 2010 18:46:32 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 37AED3A680D for ; Wed, 24 Mar 2010 18:46:32 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZT00GEYE9UBI@szxga01-in.huawei.com> for alto@ietf.org; Thu, 25 Mar 2010 09:46:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZT00ILGE9UJI@szxga01-in.huawei.com> for alto@ietf.org; Thu, 25 Mar 2010 09:46:42 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.28.136]) by szxmc03-in.huawei.com (mshttpd); Thu, 25 Mar 2010 09:46:42 +0800 Date: Thu, 25 Mar 2010 09:46:42 +0800 From: songhaibin 64081 To: alto@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [alto] ALTO privacy again X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 01:46:33 -0000 Hi, Just want to get some feedback from the network operators, if the network map which discloses the IP prefixes under each PID defined in the ALTO protocol base draft okay with them, or if they are willing to avoid this. Thanks, Haibin From richard_woundy@cable.comcast.com Wed Mar 24 20:09:02 2010 Return-Path: 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 7EC2C3A6832 for ; Wed, 24 Mar 2010 20:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.267 X-Spam-Level: *** X-Spam-Status: No, score=3.267 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 IWNNYPOa-3Fe for ; Wed, 24 Mar 2010 20:09:01 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 883E53A6784 for ; Wed, 24 Mar 2010 20:09:01 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.79085410; Wed, 24 Mar 2010 23:09:02 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 23:09:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 23:08:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] ALTO privacy again Thread-Index: AcrLvQ9Op00RFGmjQJi1OHhw9MibuwAB0a+Q References: From: "Woundy, Richard" To: "songhaibin 64081" , X-OriginalArrivalTime: 25 Mar 2010 03:09:01.0871 (UTC) FILETIME=[84FF6BF0:01CACBC8] Subject: Re: [alto] ALTO privacy again X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 03:09:02 -0000 Before I answer, let me distinguish 'privacy' from 'confidentiality'. I would lump issues concerning disclosure of subscriber information under 'privacy', and issues concerning disclosure of network topology etc under 'confidentiality'. > if the network map which discloses the IP prefixes under each PID defined in the ALTO protocol base draft okay with them The sensitivity of the information may depend on the size and scope of the PID. If the PID encompasses all of the ISP's prefixes, that information may be available from sources other than ALTO. For example, someone may use 'whois' information (e.g. https://ws.arin.net/whois) or a BGP looking glass (e.g. http://www.bgp4.as/looking-glasses or http://www.ris.ripe.net/cgi-bin/lg/index.cgi) to obtain ISP prefix information. If the PID is limited to prefixes in a particular metropolitan area, that information might not be easily gleaned from public data sources and might be considered confidential by the ISP. If the PID represents prefixes associated with customers having a particular service tier, then there may or may not be privacy implications about revealing this information. Hope this helps. -- Rich -----Original Message----- From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of songhaibin 64081 Sent: Wednesday, March 24, 2010 6:47 PM To: alto@ietf.org Subject: [alto] ALTO privacy again Hi, Just want to get some feedback from the network operators, if the network map which discloses the IP prefixes under each PID defined in the ALTO protocol base draft okay with them, or if they are willing to avoid this. Thanks, Haibin =20 _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto From melodysong@huawei.com Thu Mar 25 10:43:33 2010 Return-Path: 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 B55F73A6D19 for ; Thu, 25 Mar 2010 10:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.378 X-Spam-Level: *** X-Spam-Status: No, score=3.378 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1] 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 1YuEEDm0JpU9 for ; Thu, 25 Mar 2010 10:43:32 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8B7FA3A6800 for ; Thu, 25 Mar 2010 10:41:19 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZU000P1MH75F@szxga03-in.huawei.com> for alto@ietf.org; Fri, 26 Mar 2010 01:41:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZU00AA2MH7B5@szxga03-in.huawei.com> for alto@ietf.org; Fri, 26 Mar 2010 01:41:31 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.28.136]) by szxmc03-in.huawei.com (mshttpd); Fri, 26 Mar 2010 01:41:31 +0800 Date: Fri, 26 Mar 2010 01:41:31 +0800 From: songhaibin 64081 In-reply-to: To: "Woundy, Richard" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Cc: alto@ietf.org Subject: Re: [alto] network topology confidentiality X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:43:33 -0000 Hi Rich, Thanks for your response. I changed the title to "network topology confidentiality" according to you explanation. See inline. From: "Woundy, Richard" > Before I answer, let me distinguish 'privacy' from > 'confidentiality'. I > would lump issues concerning disclosure of subscriber information > under'privacy', and issues concerning disclosure of network > topology etc > under 'confidentiality'. > Thank you again for the detailed explanation. > > if the network map which discloses the IP prefixes under each PID > defined in the ALTO protocol base draft okay with them > > The sensitivity of the information may depend on the size and > scope of > the PID. > > If the PID encompasses all of the ISP's prefixes, that information may > be available from sources other than ALTO. For example, someone > may use > 'whois' information (e.g. https://ws.arin.net/whois) or a BGP looking > glass (e.g. http://www.bgp4.as/looking-glasses or > http://www.ris.ripe.net/cgi-bin/lg/index.cgi) to obtain ISP prefix > information. > Right. I agree. This kind of high level information can be easily got from these sources. > If the PID is limited to prefixes in a particular metropolitan area, > that information might not be easily gleaned from public data sources > and might be considered confidential by the ISP. > This is really what I concern about. Some ISPs have large network, which covers at least several metropolitan areas. The intro-domain traffic optimizatio is needed. We actually need that level of PIDs. But disclosure of the IP prefixes under these PIDs might be a concern then. > If the PID represents prefixes associated with customers having a > particular service tier, then there may or may not be privacy > implications about revealing this information. > > Hope this helps. It really helps :) BR, Haibin > > -- Rich > > -----Original Message----- > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On > Behalf Of > songhaibin 64081 > Sent: Wednesday, March 24, 2010 6:47 PM > To: alto@ietf.org > Subject: [alto] ALTO privacy again > > Hi, > > Just want to get some feedback from the network operators, if the > network map which discloses the IP prefixes under each PID defined in > the ALTO protocol base draft okay with them, or if they are > willing to > avoid this. > > Thanks, > Haibin > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > From Martin.Stiemerling@neclab.eu Sat Mar 27 03:53:55 2010 Return-Path: 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 783553A6988 for ; Sat, 27 Mar 2010 03:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.078 X-Spam-Level: * X-Spam-Status: No, score=1.078 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 sHfkQYp0gKii for ; Sat, 27 Mar 2010 03:53:54 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 51F283A6995 for ; Sat, 27 Mar 2010 03:53:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1B0522C000C17; Sat, 27 Mar 2010 11:54:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxUjCVJF9+qi; Sat, 27 Mar 2010 11:54:18 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id EDA7F2C000C13; Sat, 27 Mar 2010 11:54:07 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Mar 2010 11:54:07 +0100 Message-ID: <547F018265F92642B577B986577D671C013058B1@VENUS.office> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] Error handling in the ALTO protocol (-03) Thread-Index: AcrGjj+EuqGXx59iTeWAsLMUBTt0fgAEgBiAAaRMYlA= References: From: "Martin Stiemerling" To: "Woundy, Richard" , Subject: Re: [alto] Error handling in the ALTO protocol (-03) X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 10:53:55 -0000 Hi Rich, Yes, you're understanding is right. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf = Of > Woundy, Richard > Sent: Thursday, March 18, 2010 2:38 PM > To: Martin Stiemerling; alto@ietf.org > Subject: Re: [alto] Error handling in the ALTO protocol (-03) >=20 > Martin, I assume in your proposal that ALTO would still leverage the > appropriate HTTP error codes as well as add ALTO error codes / > information? >=20 > I think we want to keep the HTTP error codes so that intermediaries = (eg > caches) handle errors the right way as well. >=20 > -- Rich >=20 >=20 > ----- Original Message ----- > From: alto-bounces@ietf.org > To: alto@ietf.org > Sent: Thu Mar 18 07:29:18 2010 > Subject: [alto] Error handling in the ALTO protocol (-03) >=20 > Hi all, >=20 > While reading draft-ietf-alto-protocol-03 is stumbled over the error > handling. >=20 > It seems that the error handling of ALTO relies on the http error > codes, but does not provide its own error code or proceed. >=20 > I see this a shortcoming of the current design and also as not > favourably. >=20 > This mixes transport related error messages (e.g., 404 not found, = i.e., > the general alto resource your asking for isn't here) and errors > related the actual ALTO handling (e.g., asking guidance for private or > reserved IP addresses that cannot be rated by ALTO, syntax errors, or > not understood objects). >=20 > My proposal: > - separate both levels clearly > - define an error object for cases where no or only a partial answer > can be given > - define that the server can deliver some information he has = understood > (e.g., some IP addresses) within the given semantics, as defined in = the > draft as is. >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From Martin.Stiemerling@neclab.eu Sat Mar 27 03:57:02 2010 Return-Path: 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 139043A6995 for ; Sat, 27 Mar 2010 03:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.085 X-Spam-Level: * X-Spam-Status: No, score=1.085 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 3hGjL8MsTJP4 for ; Sat, 27 Mar 2010 03:57:01 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0223C3A69A6 for ; Sat, 27 Mar 2010 03:56:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 807BE2C000C17; Sat, 27 Mar 2010 11:57:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtGUfTUxPbBw; Sat, 27 Mar 2010 11:57:15 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 5DE182C000C13; Sat, 27 Mar 2010 11:57:05 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Mar 2010 11:57:01 +0100 Message-ID: <547F018265F92642B577B986577D671C013058B2@VENUS.office> In-reply-to: <201003180950.23175.richard.alimi@yale.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alto] #1: Message format Thread-Index: AcrGofr5PVvuVCx2R8aqgbumxhQzlwG+eAIA References: <201003111729.33544.richard.alimi@yale.edu> <547F018265F92642B577B986577D671C012A3023@VENUS.office> <201003180950.23175.richard.alimi@yale.edu> From: "Martin Stiemerling" To: "Richard Alimi" Cc: alto@ietf.org Subject: Re: [alto] #1: Message format X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 10:57:02 -0000 Hi Rich,=20 For the IPv6/IPv4 part: I would give it an easy start and to simply = return two lists (if asked for), one for IPv4 and one for IPv6. = Expressing relationships or dependencies between them would go too far = (it's not about us to solve the IP4/IPv6 transistion) and would also = increase the complexity in the protocol and also the implementation.=20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Richard Alimi [mailto:richard.alimi@gmail.com] On Behalf Of > Richard Alimi > Sent: Thursday, March 18, 2010 2:50 PM > To: Martin Stiemerling > Cc: alto@ietf.org > Subject: Re: [alto] #1: Message format >=20 > Hi Martin, >=20 > Thank you very much for the comments. Please see inline: >=20 > On Thursday 18 March 2010 7:39:15 am Martin Stiemerling wrote: > > Rich, > > > > a few comments inline: > > > -----Original Message----- > > > From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On > Behalf Of > > > Richard Alimi > > > Sent: Thursday, March 11, 2010 11:30 PM > > > To: Jason Livingood > > > Cc: alto@ietf.org > > > Subject: Re: [alto] #1: Message format > > > > > > Hi Jason, > > > > > > Thank you very much for taking a look. Please see below: > > > > > > On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > > > > You may want to make some of these tracker notes more verbose. > > > > > > At this point, since this is a first stab at fully specifying > protocol > > > details, my personal feeling is that we are still wide-open for > > > discussion on > > > the whole document. However, there on a few points that I think = are > > > particular > > > important for this go-around: > > > > > > - IPv4/IPv6 needs much more thought before integrating it into > > > > > > the document. In particular, what are the right semantics for > > > > > > handling IPv4 > > > > > > and IPv6 with respect to indicating provider preferences? (Some > > > > > > initial > > > > > > questions are noted on Issue #9 for this)? > > > > A simple turn on this: limit a single query-object to an IP address > family. > > However, a query to the server can include multiple query-objects, > i.e., > > one each for an IP address family or whatever identifier comes up > later on > > (e.g. HIP IDs ;) >=20 > Yes, this is one possibility. One limitation of this approach is that > we > could only convey a _global_ preference for IPv4, IPv6, etc. That is, > a > network provider could say "please prefer IPv6 regardless of who you > are > contacting." >=20 > Another possible preference that one might want to convey is per- > destination > Network Location. For example, "please prefer IPv6 when contacting > endpoints > in ISP A, but please prefer IPv4 when contacting endpoints in ISP B." > It > would be good to hear some opinions (particularly from service > providers) as > to whether such preferences this would useful or necessary. If so, we > can > figure out a reasonable way to encode such preferences (one = possibility > may be > a per-PID attribute). >=20 > > > - With regard to messaging (including usage of HTTP URIs and the > actual > > > body > > > > > > encodings), can people think of issues that might cause problems > for > > > deployment in an operational network (e.g., load-balancing > > > > > > configuration)? > > > > > > Difficult or non-intuitive implementation (both server-side and > > > client-side)? Are there any ambiguities you can see? > > > I thinking through the current protocol details we have tried to > > > > > > address > > > > > > these, but input from others would be extremely helpful. > > > > I'm still browsing through this and how JSON works. >=20 > Sounds good. >=20 > > > - For Redistribution, this is a capability that seemed to get > favorable > > > > > > feedback at IETF76. The current implementation uses HTTP > > > > > > headers/trailers to > > > > > > send the signatures, and a certificate is encoded in the Server > > > > > > Capability > > > > > > response. The idea is that an ALTO Client can locally cache the > > > > > > certificate > > > > > > and only contact the ALTO Server very infrequently even if it is > > > > > > gathering > > > > > > ALTO information (i.e., ALTOResponse structs) from other ALTO > Clients > > > instead of the ALTO Server itself. For this part, what do people > > > > > > think about > > > > > > how such redistribution information is encoded in the protocol? > Is > > > > > > there a > > > > > > clean way to do this without requiring custom HTTP > headers/trailers? > > > > > > Does > > > > > > the spec sufficiently convey when redistribution should or = should > not > > > > > > be > > > > > > used? > > > > I'm not sure that the spec is doing good in this respect. The > emphasize is > > on the security (i.e., using certificates), but an important point = is > > missing. The server should state in what area (i.e., IP prefix) this > > information is allowed to be distributed. > > > > See draft-kiesel-alto-h12-02 under redistribution: > > > > The response contains also a resource consumer host location > > attribute (rc_hla). This rc_hla echos partially the information > from > > the request, but gives actually guidance to the ALTO client in > what > > scope this information can be distributed amongst other peers. = In > > this response, the server allows the redistribution of the > received > > guidance to peers with the IP prefix 195.37.0.0/16. >=20 > This is actually what the "server", "request_uri" and "request_body" > attributes are for. As stated in the draft: >=20 > ... This allows ALTO Clients to which the information is = distributed > to > understand the context of the query and interpret the results. >=20 > Here, the "context" basically means "the full set of input parameters > that > would have produced this response." Using this, ALTO Clients can > determine > the distribution scope. Put another way, if another ALTO Client > executed the > same query (to the same server) with this particular input, they'd get > the > same response. >=20 > The only case where such a guarantee is not available is when other > information beyond the URI or ALTO Request Body is used to generate = the > response. In the current protocol, such cases should not (as a side > note, > perhaps it should be changed to a MUST NOT..) be redistributed: >=20 > Note that information about ALTO Client performing the Request and > any HTTP Headers passed in the request are not included. If any > such > information or headers influence the response generated by the ALTO > Server, the response SHOULD NOT be indicated as redistributable. >=20 > Such a case *could* be handled as you mentioned by explicitly giving a > scope > for redistribution, but I'm wondering what particular queries you were > thinking about here, and whether it makes sense to redistribute the > responses > to such queries. >=20 > Another way to interpret your concern is from an access-control > perspective. > That is, using such a scope to indicate which other ALTO Clients have > permission to receive this particular ALTO Response. If this is the > intention > (I'm not implying that you think it is, I'm just trying to cover all = of > the > bases), then I don't think this is reasonable to put in the protocol, > since > ALTO Clients are in no way bound to follow this advice. >=20 > > > As mentioned above, I would think that comments about the entire > > > document are > > > very useful, but the major changes in these couple of revisions > have > > > been to > > > sections 6, 7, and 11 (so feel free to focus there). > > > > I'm still reading... >=20 > Great :) >=20 > Thanks again for the comments! >=20 > -- > Richard Alimi > Department of Computer Science > Yale University