From p2pi-bounces@ietf.org Wed Oct 1 05:48:24 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BD53A6A3B; Wed, 1 Oct 2008 05:48:23 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B573A680A for ; Wed, 1 Oct 2008 05:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 2+v30G7cAWsn for ; Wed, 1 Oct 2008 05:48:20 -0700 (PDT) Received: from mailgate02.crc.ca (mailgate02.crc.ca [142.92.160.37]) by core3.amsl.com (Postfix) with ESMTP id 9DB853A6A3B for ; Wed, 1 Oct 2008 05:48:20 -0700 (PDT) Received: from mail.crc.ca (mail.crc.ca [142.92.39.129]) by mailgate02.crc.ca (8.14.0/8.14.0) with ESMTP id m91Cmf6L011684 for ; Wed, 1 Oct 2008 08:48:41 -0400 Received: from [142.92.38.14] (roger.dgrc.crc.ca [142.92.38.14]) by mail.crc.ca (8.12.11.20060308/8.12.11) with ESMTP id m91CmYib016699 for ; Wed, 1 Oct 2008 08:48:34 -0400 Message-ID: <48E371A6.6040500@crc.ca> Date: Wed, 01 Oct 2008 08:48:38 -0400 From: Li Li User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: p2pi@ietf.org Content-Disposition: inline X-Scanned-By: MIMEDefang 2.57 on 142.92.160.37 X-Scanned-By: MIMEDefang 2.57 on 142.92.39.129 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-3.0 (mailgate02.crc.ca [142.92.160.37]); Wed, 01 Oct 2008 08:48:41 -0400 (EDT) Subject: [p2pi] MP2P'09 X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org ---------------------------------------------------------------- CALL FOR PAPERS: Paper Submission Deadline Extended to Oct. 15th 2008 6th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'09) http://www.samrg.org/mp2p/2009 Dallas, Texas, USA, March 16-20, 2009 In conjunction with the 7th IEEE International Conference on Pervasive Computing and Communications (PerCom'09) http://www.percom.org/ Technical funding by EuroNGI (*): http://www.eurongi.org/ (*) Final approval pending Important Dates: ---------------- Papers due: October 15, 2008 *** NEW = DATE **** Notification of acceptance November 18, 2008 Camera-ready papers due December 15, 2008 ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile users, extend the arena of P2P computing to encompass mobile devices and wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, resource contraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P communication and computing. MP2P'09 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile P2P computing and communications. It will address the challenges, technologies, and architectures leading to real-world solutions that provide users with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P'09 is the peer-to-peer paradigm as used in mobile ad hoc networks (MANETS), sensor networks, and large-scale heterogeneous overlays. Topics of particular interest include, but are not limited to: - Peer-to-peer overlays for MANETs and sensor networks - Hybrid P2P architectures for integrated MANETs and wide-area networks - Large-scale heterogeneous P2P systems - Mobility in federated overlay architectures - Impact of network mobility on P2P systems and services (mobile IP / MANET) - P2P-based information sensing and fusion - MP2P performance & measurement studies - Semantic routing & overlay routing in MP2P - Delay tolerant MP2P systems - Resource and service discovery in MP2P - Resource exchange mechanisms in MP2P - Peer access and control in mobile environment - Data exchange and rendering techniques for mobile P2P devices - Secure communication protocols for MP2P - Nature-inspired algorithms for MP2P - Novel MP2P applications & services - Theoretical issues on mobile information diffusion - MP2P SIP - MP2P messaging systems, monitoring systems, searching systems, games, etc. - Location dependent MP2P services - MP2P over different bearer services: 2.5/3G (GPRS/UMTS) / 802.11 (WLAN) - MP2P & operator/provider requirements - Reliability and carrier-grade performance of MP2P services Paper Submission: ----------------- Papers must be written in English and should not exceed 5 pages in IEEE proceedings style. Authors MUST submit their papers through the = EASYCHAIR web site ( http://www.easychair.org/conferences/?conf=3Dmp2p09 ) in three steps: * Creation of a personal account on EASYCHAIR (if the author does not already have one) * Registration of the paper (requiring a short abstract of up to 150 = words) * Upload of the paper. Only in pdf format Submission implies the willingness of at least one of the authors to register and present the paper. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must be presented at the = workshop and will appear in a combined PerCom 2009 workshop proceedings = published by IEEE Computer Society Press. Paper must not be submitted elsewhere. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Organizing Committee, Program Co-chairs: --------------------------------------------------------------- John Buford, Avaya Labs, USA. Li Li, Communications Research Center Canada, Canada. Kurt Tutschku, Department of Computer Science, University of Vienna, = Austria Steering Board ----------------------- - Frank-Uwe Andersen, Siemens Communications, Berlin, Germany. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Cecilia Mascolo, Department of Computer Science, University College London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill Publicity Chair --------------------- Li Li, Communications Research Center Canada, Canada. Program Committee Members (Pending Approval) -------------------------------------------------------------------------- - John Buford, Avaya Labs, USA. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University - Hermann de Meer, Department of Computer Networks & Computer Communications, University of Passau, Germany. - Krishna Kishore Dhara, Avaya Labs Research, Lincroft, NJ, USA. - Babak Esfandiari, Carleton University, Canada. - Stephen Hailes, Department of Computer Science, University College of London, UK - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University. - Norihiro Ishikawa, NTT Docomo, Japan. - Valerie Issarny, INRIA, France - Wolfgang Kellerer, DoCoMo DoCoMo Communications Laboratories Europe, Germany. - Mario Kolberg, University of Sterling, UK. - Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton = University, Canada. - Li Li, Communication Research Center Canada, Canada - Christoph Lindemann, University of Leipzig, Germany. - George Roussos, School of Computer Science and Information Systems, Birkbeck College, University of London, UK. - Jochen Schiller, Institute of Computer Science, FU Berlin, Germany. - Hans-Peter Schwefel, Department of Communication Technology, Aalborg University, Denmark. - Shervin Shirmohammadi, School of Information Technology and Engineering (SITE), University of Ottawa, Canada. - Kurt Tutschku, Department of Distributed Systems, University of = W=FCrzburg, Germany. - Klaus Wehrle, Distributed Systems Group, RWTH Aachen, Germany. - Chansu Yu, Dept. Of Electrical and Computer Engineering, Cleveland State University, Cleveland, OH, USA. - Karin Hummel, University of Vienna, Austria - Gabriele Kotsis, Johannes Kepler University of Linz - Dario Rossi, ENST Telecom Paris - Adrian Popescu, Blekinge Institute of Technology, Sweden - Michaela Meo, Politiecnico di Torino, Italy _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 12:24:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535143A68DC; Thu, 9 Oct 2008 12:24:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1963A6899 for ; Thu, 9 Oct 2008 12:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 JkQ8DFqbpa31 for ; Thu, 9 Oct 2008 12:24:28 -0700 (PDT) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) by core3.amsl.com (Postfix) with ESMTP id C66EE3A68DC for ; Thu, 9 Oct 2008 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univie.ac.at; s=rev1; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date; bh=vyJPvoZT 7k1NdgfTTZTJlj4QCs1JQvYhwxvFVpZMhsM=; b=t8BcLbuJW0yDaYJxTdISfDHR F+0t+ay/MhOd4JWeZm6bwPQ7qR9HLvT7Kf0Upw/7PjNG9ot042PbJPlab3ooy+7q iiEewKgDUlHaNYaSVFGaWbf+jgVWL2GaPgTpFigFVf/4xpPAvolKmbCDgYESA98p cdkQCE0mEFbjXKJ/Eio= Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1Ko18I-0005mX-C2 for p2pi@ietf.org; Thu, 09 Oct 2008 21:25:10 +0200 Received: from styx.pri.univie.ac.at ([131.130.37.129] helo=[172.24.66.45]) by justin.univie.ac.at with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Ko18I-0006wi-9V for p2pi@ietf.org; Thu, 09 Oct 2008 21:25:10 +0200 Message-Id: <5A25C62D-672A-4DE4-9F25-95F8103B198C@univie.ac.at> From: Kurt Tutschku To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 21:25:09 +0200 X-Mailer: Apple Mail (2.929.2) Subject: [p2pi] 20th ITC Specialist Seminar on Network Virtualization X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org ***************************************************************************= ******* 20th ITC Specialist Seminar on NETWORK VIRTUALIZATION =96 Concepts and Performance Aspects http://www.itcspecialistseminar.com/itcss20/ 18.-20. Mai 2009 Swiss-Belhotel Golden Sand Resort, Hoi An, Viet Nam ***************************************************************************= ******* AIMS AND TOPICS Network virtualization is the technology that allows the simultaneous = operation of multiple logical networks (also known as overlays) on a = single physical platform. Network virtualization permits distributed = participants to create almost instantly their own network with = application-specific naming, routing, and resource management = mechanisms. For instance, server virtualization enables users to use = parts of a computing center as their own personal computer. Recently, = network virtualization received tremendous attention since it is = expected to be one of the major paradigms for the future Internet as = proposed by numerous international initiatives on future networks, = e.g. PlanetLab (USA, International), GENI (USA), AKARI (JAPAN), = OneLab2 (Europe), and G-Lab (Germany). A major objective of this ITC Specialist Seminar is to early identify = future performance issues and to provide methodologies and mechanisms = to address the various performance problems in network = virtualization. The seminar is intended as a forum for scientists and = engineers in academia and industry to exchange and discuss their = latest experiences and research results. It will address techniques, = architectures, performance models, and performance engineering methods = leading to real world network virtualization solutions that provide = users with efficient techniques for creating and operating their own = high performance virtual network. Topics of interest are amongst others, but not limited to: o Performance issues of virtualization techniques on routers and end = hosts o Performance issues of bandwidth and resource virtualization techniques o Performance issues of overlays for future network architectures o Performance of virtualized transport mechanisms o Performance of virtualized services and virtualized applications o Virtual test labs and network federation IMPORTANT DATES Submission deadline: December 15, 2008 Acceptance notification: January 31, 2008 Camera ready: February 20, 2008 GENERAL CHAIR o Phuoc Tran-Gia, University of Wuerzburg, Germany GENERAL CO-CHAIR o Prosper Chemouil, Orange Labs, France TPC CHAIRS o Kurt Tutschku, University of Vienna, Austria o Paul Mueller, University of Kaiserslautern, Germany o Frederic Dang Tran, France Telecom Orange Group, France PUBLICITY CHAIR o Rastin Pries, University of Wuerzburg, Germany TPC o Andy Bavier, Princeton University, USA o Hans van den Berg, TNO and Twente University, Netherlands o Marcus Brunner, NEC, Germany o Joachim Charzinski, Nokia Siemens Networks, Munich, Germany o Serge Fdida, Universite Pierre & Marie Curie, Paris, France o Markus Fiedler, Blekinge Tekniska H=F6gskola, Karlskrona, Sweden o Carmelita Goerg, University of Bremen, Germany o JongWon Kim, Gwangju Institute of Science and Technology, Gwangju, = Korea o Ulf Koerner, Lund University, Sweden o Paul Kuehn, University of Stuttgart, Germany o Kenji Leibnitz, Osaka University, Osaka, Japan o Michael Menth, University of Wuerzburg, Germany o Masayuki Murata, Osaka University, Osaka, Japan o Akihiro Nakao, The University of Tokyo/NICT, Tokyo, Japan o Guy Pujolle, LIP6, France o Dario Rossi, ENST Telecom Paris, France o Hiroshi Saito, NTT, Tokyo, Japan o Moshe Sidi, Technion, Haifa, Israel o Ralf Steinmetz, University of Darmstadt, Germany o Martin Stiemerling, NEC, Heidelberg, Germany o Pascale Vicat-Blanc Primet, Inria, France LOCAL ORGANIZATION CHAIR o Nguyen Tien Dzung, Ha Noi University of Technology, Ha Noi, Viet Nam o Nguyen Huu Thanh, Ha Noi University of Technology, Ha Noi, Viet Nam o Vu Duy Loi, College of Technology, Ha Noi, Viet Nam o Nguyen Ngoc Hien, College of Technology, Ha Noi National Unversity, = Viet Nam o Nguyen Dinh Viet, College of Technology, Ha Noi National Unversity, = Viet Nam o Doan Minh Phuong, College of Technology, Ha Noi National Unversity, = Viet Nam o Nguyen Minh Tri, College of Technology, Ha Noi National Unversity, = Viet Nam o Duong Ba Hong Thuan, Ha Noi University of Technology, Viet Nam o Nguyen Huyen Trang, Ha Noi University of Technology, Viet Nam --- Prof. Dr. Kurt Tutschku Chair of Future Communication (Endowed by Telekom Austria) Institute of Distributed and Multimedia Systems, Faculty of Computer = Science University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria. Tel: +43/1/4277-39611 mailto:kurt.tutschku@univie.ac.at or mailto:kurttutschku@gmail.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 17:22:38 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657E23A6A5F; Thu, 9 Oct 2008 17:22:38 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C24E3A6A5F; Thu, 9 Oct 2008 17:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, 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 PQmTUkD7pXGr; Thu, 9 Oct 2008 17:22:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 78B9F3A6868; Thu, 9 Oct 2008 17:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223598201; x=1255134201; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"'iesg@ietf.org'"=20,=20"ietf@ietf.org" =20|CC:=20"p2pi@ietf.org"=20|Date:=20Thu,=209=20Oct=202008=2017:23:22=20-0700 |Subject:=20RE:=20WG=20Review:=20Application-Layer=20Traf fic=20Optimization=20(alto)=20|Thread-Topic:=20WG=20Revie w:=20Application-Layer=20Traffic=20Optimization=20(alto) =20|Thread-Index:=20Ackn81APsSzGOXtYRR6bfTbQ+SG5OQBwJZXA |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>|In-Reply-To:=20<20081006203 532.B1D673A68AF@core3.amsl.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10436917"; bh=BAj+RBEiMmFIlOTMtuCTaqivJQ3E5s0BmIPWSvQG+FU=; b=qmvHyFQaTnnY9BmxfLos7ZAYZMpuCXmdWe4UAGaFE5gzPu7uZ9vxWgci UFKdB7W+MxKpPuXA0LCSMHxUTAQuCvWl0sQEwJTHIE032f+lDiifiN4WH 1KDvKgJSSA6WpN4vNCIRKGBgrEV02uOmCSK6FSKWILp6JPMTWOG0lbTlY c=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10436917" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 17:23:19 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A0NJ8w008082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 17:23:19 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A0NIRV015575 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2008 17:23:19 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 9 Oct 2008 17:23:18 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 9 Oct 2008 17:23:18 -0700 From: "Narayanan, Vidya" To: "'iesg@ietf.org'" , "ietf@ietf.org" Date: Thu, 9 Oct 2008 17:23:22 -0700 Thread-Topic: WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQBwJZXA Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I am surprised to see that ALTO is being proposed for a WG after the last BoF concluded with no consensus whatsoever. I think a second BoF is more appropriate than a WG on the topic at this time. That said, I do see the need for this work, although I have some comments on the current direction. Overall, I think we should work with the notion of an ALTO "service" rather than specifically an ALTO "server". The ALTO service may be provided by a server, a cluster of distributed servers or as a service in an overlay. Although some of the charter wording talks about a "service" rather than a "server", there is enough mention of a "server" entity to imply a strict client-server protocol. As part of that, I think there are a couple of key things that need to be addressed here: - A protocol that allows peers (or ALTO clients) to publish information about themselves as part of the ALTO service. An example of such information may be the uplink/downlink bandwidth of the peer. - The ability to register information types with IANA and extend these. The request/response protocol should be a generic enough container for any information that peers can provide and look for, plus what may be available from service providers, etc. There may be some guidelines on how such information types can be registered and we may start with default ones. Some further comments/questions inline. > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Monday, October 06, 2008 1:36 PM > To: IETF Announcement list > Cc: p2pi@ietf.org > Subject: WG Review: Application-Layer Traffic Optimization (alto) > > A new IETF working group has been proposed in the > Applications Area. The IESG has not made any determination > as yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by Monday, > October 13, 2008. > > Application-Layer Traffic Optimization (alto) > ============================================= > Last Modified: 2008-09-29 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Applications Area Director(s): > > Lisa Dusseault (lisa at osafoundation.org) Chris Newman > (Chris.Newman at sun.com) > > Applications Area Advisor: > > Lisa Dusseault (lisa at osafoundation.org) > > Mailing List: > > General Discussion: p2pi at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi > Archive: http://www.ietf.org/pipermail/p2pi/ > > Description of Working Group: > > A significant part of the Internet traffic today is generated > by peer-to-peer (P2P) applications used for file sharing, > real-time communications, and live media streaming. P2P > applications exchange large amounts of data, often uploading > as much as downloading. In contrast to client/server > architectures, P2P applications often have a selection of > peers and must choose. > > One of the advantages of P2P systems comes from redundancy in > resource availability. This requires choosing among download > locations, yet applications have at best incomplete > information about the topology of the network. Applications > can sometimes make empirical measurements of link > performance, but even when this is an option it takes time. > The application cannot always start out with an optimal > arrangement of peers, thus causing at least temporary reduced > performance and excessive cross-domain traffic. Providing > more information for use in peer selection can improve P2P > performance and lower ISP costs. > > The Working Group will design and specify an > Application-Layer Traffic Optimization (ALTO) service that > will provide applications with information to perform > better-than-random initial peer selection. > ALTO services may take different approaches at balancing > factors including maximum bandwidth, minimum cross-domain > traffic, lowest cost to the user, etc. The WG will consider > the needs of BitTorrent, tracker-less P2P, and other > applications, such as content delivery networks (CDN) and > mirror selection. > What does the above sentence mean? If we are putting such a list together, we must also take into account needs from structured P2P overlays such as those being specified in P2PSIP. > The WG will focus on the following items: > > - A "problem statement" document providing a description of the > problem and a common terminology. > > - A requirements document. This document will list > requirements for the ALTO service, identifying, for example, > what kind of information P2P applications will need for > optimizing their choices. > > - A request/response protocol for querying the ALTO service > to obtain information useful for peer selection, and a format > for requests and > responses. The WG does not require intermediaries between the ALTO > server and the peer querying it. If the requirements > analysis identifies the need to allow clients to delegate > third-parties to query the ALTO service on their behalf, the > WG will ensure that the protocol provides a mechanism to > assert the consent of the delegating client. > Is this meant to allow for entities such as proxies to be in the path? > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different > level of knowledge about the underlying network, such > preferences may have different representations. Initially the > WG will consider: IP ranges to prefer and to avoid, ranked > lists of the peers requested by the client, information about > topological proximity and approximate geographic locations. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > Earlier, it is mentioned that the requirements document will determine the types of information that are useful for P2P applications. Given that, it seems premature to conclude that the WG should consider the above mentioned parameters. Also, as I mentioned earlier, I think it is essential to keep the protocol and message formats extensible and allow for exchange of any registered information type. Another question I have is about the assumptions around expected peer addressing models. Some of the above seems to hint at IP addresses - is this an assumption already? > - In order to query the ALTO server, clients must first know > one or more ALTO servers that might provide useful > information. The WG will look at service discovery > mechanisms that are in use, or defined elsewhere (e.g. > based on DNS SRV records or DHCP options). If such discovery > mechanisms can be reused, the WG will produce a document to > specify how they may be adopted for locating such servers. > However, a new, general-purpose service discovery mechanism > is not in scope. > Alternately, the clients may look for ALTO services within an overlay. This can be modeled as service discovery within the overlay - I'm, however, not suggesting that we take on solutions for that. > When the WG considers standardizing information that the ALTO > server could provide, the following criteria are important to > ensure real feasibility. > > - Can the ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that a client will find useful? I'm not sure how useful it is for us to answer this question. The protocol we develop simply needs to be a container for any information that has a registered type and fits a certain format. > - Can a client get that information without excessive privacy concerns > (e.g. by sending large lists of peers)? > - Is it information that a client cannot find easily some other way? > > After these criteria are met, the generality of the data will > be considered for prioritizing standardization work, for > example the number of operators and clients that are likely > to be able to provide or use that particular data. If we can build an extensible protocol, we don't need to define all possible kinds of information that get carried in it. >In any > case, this WG will not propose standards on how congestion is > signaled, remediated, or avoided, and will not deal with > information representing instantaneous network state. > Such issues belong to other IETF areas and will be treated > accordingly by the specific area. > > This WG will focus solely on the communication protocol > between applications and ALTO servers. Note that ALTO > services may be useful in client-server environments as well > as P2P environments, although P2P environments are the first > focus. If, in the future, the IETF considers changes to > other protocols for actually implementing ALTO servers (e.g. > application-layer protocols for Internet coordinate systems, > routing protocol extensions for ISP-based solutions), such > work will be done in strict coordination with the appropriate WGs. > I hope we can also look at the above from a generalized service perspective rather than just a client-server perspective. Thanks, Vidya > Issues related to the content exchanged in P2P systems are > also excluded from the WG's scope, as is the issue dealing > with enforcing the legality of the content. > > Goals and Milestones (very tentative dates): > > Apr 2009: Working Group Last Call for problem statement Jun > 2009: Submit problem statement to IESG as Informational Aug > 2009: Working Group Last Call for requirements document Oct > 2009: Submit requirements document to IESG as Informational > Jan 2010: Working Group Last Call for request/response > protocol Jan 2010: Working Group Last Call for usage document > for communicating network preferences Mar 2010: Submit > request/response protocol to IESG as Proposed Standard Mar > 2010: Submit usage document to IESG as Proposed Standard May > 2010: Working Group Last Call of discovery mechanism Jul > 2010: Submit discovery mechanism to IESG as Proposed Standard > Aug 2010: Dissolve or re-charter > > Initial Drafts for Consideration > - draft-marocco-alto-problem-statement-02 -- > Application-Layer Traffic Optimization (ALTO) Problem Statement > - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization > (ALTO) Requirements > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 21:14:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2649E3A6952; Thu, 9 Oct 2008 21:14:17 -0700 (PDT) X-Original-To: p2pi@ietf.org Delivered-To: p2pi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B1D673A68AF; Mon, 6 Oct 2008 13:35:32 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Mime-Version: 1.0 Message-Id: <20081006203532.B1D673A68AF@core3.amsl.com> Date: Mon, 6 Oct 2008 13:35:32 -0700 (PDT) X-Mailman-Approved-At: Thu, 09 Oct 2008 21:14:15 -0700 Cc: p2pi@ietf.org Subject: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Monday, October 13, 2008. Application-Layer Traffic Optimization (alto) ============================================= Last Modified: 2008-09-29 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault (lisa at osafoundation.org) Chris Newman (Chris.Newman at sun.com) Applications Area Advisor: Lisa Dusseault (lisa at osafoundation.org) Mailing List: General Discussion: p2pi at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi Archive: http://www.ietf.org/pipermail/p2pi/ Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among download locations, yet applications have at best incomplete information about the topology of the network. Applications can sometimes make empirical measurements of link performance, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus causing at least temporary reduced performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors including maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, what kind of information P2P applications will need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. The WG does not require intermediaries between the ALTO server and the peer querying it. If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as extensions to the charter once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service technically provide that information? - Is the ALTO service willing to obtain and divulge that information? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the generality of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO servers (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones (very tentative dates): Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational Jan 2010: Working Group Last Call for request/response protocol Jan 2010: Working Group Last Call for usage document for communicating network preferences Mar 2010: Submit request/response protocol to IESG as Proposed Standard Mar 2010: Submit usage document to IESG as Proposed Standard May 2010: Working Group Last Call of discovery mechanism Jul 2010: Submit discovery mechanism to IESG as Proposed Standard Aug 2010: Dissolve or re-charter Initial Drafts for Consideration - draft-marocco-alto-problem-statement-02 -- Application-Layer Traffic Optimization (ALTO) Problem Statement - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization (ALTO) Requirements _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 21:14:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B17C3A69F6; Thu, 9 Oct 2008 21:14:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E353A6A07; Thu, 9 Oct 2008 17:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 72JPTjNJPEn4; Thu, 9 Oct 2008 17:40:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D33493A69F6; Thu, 9 Oct 2008 17:40:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7EDB4230; Thu, 9 Oct 2008 20:41:05 -0400 (EDT) From: Sam Hartman To: "Narayanan, Vidya" References: <20081006203532.B1D673A68AF@core3.amsl.com> Date: Thu, 09 Oct 2008 20:41:05 -0400 In-Reply-To: (Vidya Narayanan's message of "Thu, 9 Oct 2008 17:23:22 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Oct 2008 21:14:15 -0700 Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I tend to agree with Vidyan's comments. I think that addressing her comments regarding a service model instead of a server model is critical. While I too am surprised to see a WG review rather than a second bof, I would not personally object to the work if a reasonable process is followed in confirming we have sufficient consensus. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 21:14:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8728E3A6A50; Thu, 9 Oct 2008 21:14:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1300B3A6A27; Thu, 9 Oct 2008 18:36:17 -0700 (PDT) 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 3JnD8fFco9Qv; Thu, 9 Oct 2008 18:36:15 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6FE5F3A69AC; Thu, 9 Oct 2008 18:36:15 -0700 (PDT) Received: from [128.89.253.24] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Ko6vi-0006an-As; Thu, 09 Oct 2008 21:36:34 -0400 Message-ID: <48EEB19C.4000303@bbn.com> Date: Thu, 09 Oct 2008 21:36:28 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Narayanan, Vidya" References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: X-Mailman-Approved-At: Thu, 09 Oct 2008 21:14:15 -0700 Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve. There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection. The question of "service" versus "server" in the text is a complete non-issue, purely a matter of wording. In all of the "ALTO service" scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an "ALTO server". Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work. --Richard Narayanan, Vidya wrote: > I am surprised to see that ALTO is being proposed for a WG after the last BoF concluded with no consensus whatsoever. I think a second BoF is more appropriate than a WG on the topic at this time. That said, I do see the need for this work, although I have some comments on the current direction. > > Overall, I think we should work with the notion of an ALTO "service" rather than specifically an ALTO "server". The ALTO service may be provided by a server, a cluster of distributed servers or as a service in an overlay. Although some of the charter wording talks about a "service" rather than a "server", there is enough mention of a "server" entity to imply a strict client-server protocol. > > As part of that, I think there are a couple of key things that need to be addressed here: > > - A protocol that allows peers (or ALTO clients) to publish information about themselves as part of the ALTO service. An example of such information may be the uplink/downlink bandwidth of the peer. > > - The ability to register information types with IANA and extend these. The request/response protocol should be a generic enough container for any information that peers can provide and look for, plus what may be available from service providers, etc. There may be some guidelines on how such information types can be registered and we may start with default ones. > > Some further comments/questions inline. > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org >> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >> Sent: Monday, October 06, 2008 1:36 PM >> To: IETF Announcement list >> Cc: p2pi@ietf.org >> Subject: WG Review: Application-Layer Traffic Optimization (alto) >> >> A new IETF working group has been proposed in the >> Applications Area. The IESG has not made any determination >> as yet. The following draft charter was submitted, and is >> provided for informational purposes only. Please send your >> comments to the IESG mailing list (iesg@ietf.org) by Monday, >> October 13, 2008. >> >> Application-Layer Traffic Optimization (alto) >> ============================================= >> Last Modified: 2008-09-29 >> >> Current Status: Proposed Working Group >> >> Chair(s): TBD >> >> Applications Area Director(s): >> >> Lisa Dusseault (lisa at osafoundation.org) Chris Newman >> (Chris.Newman at sun.com) >> >> Applications Area Advisor: >> >> Lisa Dusseault (lisa at osafoundation.org) >> >> Mailing List: >> >> General Discussion: p2pi at ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi >> Archive: http://www.ietf.org/pipermail/p2pi/ >> >> Description of Working Group: >> >> A significant part of the Internet traffic today is generated >> by peer-to-peer (P2P) applications used for file sharing, >> real-time communications, and live media streaming. P2P >> applications exchange large amounts of data, often uploading >> as much as downloading. In contrast to client/server >> architectures, P2P applications often have a selection of >> peers and must choose. >> >> One of the advantages of P2P systems comes from redundancy in >> resource availability. This requires choosing among download >> locations, yet applications have at best incomplete >> information about the topology of the network. Applications >> can sometimes make empirical measurements of link >> performance, but even when this is an option it takes time. >> The application cannot always start out with an optimal >> arrangement of peers, thus causing at least temporary reduced >> performance and excessive cross-domain traffic. Providing >> more information for use in peer selection can improve P2P >> performance and lower ISP costs. >> >> The Working Group will design and specify an >> Application-Layer Traffic Optimization (ALTO) service that >> will provide applications with information to perform >> better-than-random initial peer selection. >> ALTO services may take different approaches at balancing >> factors including maximum bandwidth, minimum cross-domain >> traffic, lowest cost to the user, etc. The WG will consider >> the needs of BitTorrent, tracker-less P2P, and other >> applications, such as content delivery networks (CDN) and >> mirror selection. >> > > What does the above sentence mean? If we are putting such a list together, we must also take into account needs from structured P2P overlays such as those being specified in P2PSIP. > >> The WG will focus on the following items: >> >> - A "problem statement" document providing a description of the >> problem and a common terminology. >> >> - A requirements document. This document will list >> requirements for the ALTO service, identifying, for example, >> what kind of information P2P applications will need for >> optimizing their choices. >> >> - A request/response protocol for querying the ALTO service >> to obtain information useful for peer selection, and a format >> for requests and >> responses. The WG does not require intermediaries between the ALTO >> server and the peer querying it. If the requirements >> analysis identifies the need to allow clients to delegate >> third-parties to query the ALTO service on their behalf, the >> WG will ensure that the protocol provides a mechanism to >> assert the consent of the delegating client. >> > > Is this meant to allow for entities such as proxies to be in the path? > >> - A document defining core request and response formats and >> semantics to communicate network preferences to applications. >> Since ALTO services may be run by entities with different >> level of knowledge about the underlying network, such >> preferences may have different representations. Initially the >> WG will consider: IP ranges to prefer and to avoid, ranked >> lists of the peers requested by the client, information about >> topological proximity and approximate geographic locations. >> Other usages will be considered as extensions to the charter >> once the work for the initial services has been completed. >> > > Earlier, it is mentioned that the requirements document will determine the types of information that are useful for P2P applications. Given that, it seems premature to conclude that the WG should consider the above mentioned parameters. Also, as I mentioned earlier, I think it is essential to keep the protocol and message formats extensible and allow for exchange of any registered information type. > > Another question I have is about the assumptions around expected peer addressing models. Some of the above seems to hint at IP addresses - is this an assumption already? > >> - In order to query the ALTO server, clients must first know >> one or more ALTO servers that might provide useful >> information. The WG will look at service discovery >> mechanisms that are in use, or defined elsewhere (e.g. >> based on DNS SRV records or DHCP options). If such discovery >> mechanisms can be reused, the WG will produce a document to >> specify how they may be adopted for locating such servers. >> However, a new, general-purpose service discovery mechanism >> is not in scope. >> > > Alternately, the clients may look for ALTO services within an overlay. This can be modeled as service discovery within the overlay - I'm, however, not suggesting that we take on solutions for that. > >> When the WG considers standardizing information that the ALTO >> server could provide, the following criteria are important to >> ensure real feasibility. >> >> - Can the ALTO service technically provide that information? >> - Is the ALTO service willing to obtain and divulge that information? >> - Is it information that a client will find useful? > > I'm not sure how useful it is for us to answer this question. The protocol we develop simply needs to be a container for any information that has a registered type and fits a certain format. > >> - Can a client get that information without excessive privacy concerns >> (e.g. by sending large lists of peers)? >> - Is it information that a client cannot find easily some other way? >> >> After these criteria are met, the generality of the data will >> be considered for prioritizing standardization work, for >> example the number of operators and clients that are likely >> to be able to provide or use that particular data. > > If we can build an extensible protocol, we don't need to define all possible kinds of information that get carried in it. > >> In any >> case, this WG will not propose standards on how congestion is >> signaled, remediated, or avoided, and will not deal with >> information representing instantaneous network state. >> Such issues belong to other IETF areas and will be treated >> accordingly by the specific area. >> >> This WG will focus solely on the communication protocol >> between applications and ALTO servers. Note that ALTO >> services may be useful in client-server environments as well >> as P2P environments, although P2P environments are the first >> focus. If, in the future, the IETF considers changes to >> other protocols for actually implementing ALTO servers (e.g. >> application-layer protocols for Internet coordinate systems, >> routing protocol extensions for ISP-based solutions), such >> work will be done in strict coordination with the appropriate WGs. >> > > I hope we can also look at the above from a generalized service perspective rather than just a client-server perspective. > > Thanks, > Vidya > >> Issues related to the content exchanged in P2P systems are >> also excluded from the WG's scope, as is the issue dealing >> with enforcing the legality of the content. >> >> Goals and Milestones (very tentative dates): >> >> Apr 2009: Working Group Last Call for problem statement Jun >> 2009: Submit problem statement to IESG as Informational Aug >> 2009: Working Group Last Call for requirements document Oct >> 2009: Submit requirements document to IESG as Informational >> Jan 2010: Working Group Last Call for request/response >> protocol Jan 2010: Working Group Last Call for usage document >> for communicating network preferences Mar 2010: Submit >> request/response protocol to IESG as Proposed Standard Mar >> 2010: Submit usage document to IESG as Proposed Standard May >> 2010: Working Group Last Call of discovery mechanism Jul >> 2010: Submit discovery mechanism to IESG as Proposed Standard >> Aug 2010: Dissolve or re-charter >> >> Initial Drafts for Consideration >> - draft-marocco-alto-problem-statement-02 -- >> Application-Layer Traffic Optimization (ALTO) Problem Statement >> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization >> (ALTO) Requirements >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 21:28:35 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7673A67EC; Thu, 9 Oct 2008 21:28:35 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB4B3A67EC for ; Thu, 9 Oct 2008 21:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rR-Uz5QCJvpd for ; Thu, 9 Oct 2008 21:28:32 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id 3D50E3A6359 for ; Thu, 9 Oct 2008 21:28:32 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id c49so197364wra.17 for ; Thu, 09 Oct 2008 21:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=36HJb4ph/DZaT/I1qn8eAOZ/Q2FbjuwocLJnde3r7Mw=; b=dnTfVJfT1h96JWpFlotO1ex3WECAQGD5QN2kOo4cMJd3ewM2WF6xo9V2iLU9lO+9xb dQoRGiFMIwr7jf5NDC3T2rIW+rcLLngDBMgom5vXHyGkCg+6BDKkquje0dr6Lczyu2my WJt+3wwB7eT2agYb4JAwtboGRUB1WOfgxl8bA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dY8X9cQRLH/8TP/c/l1ZWG7QRbMq8HM8SweRhgMOG982cgbizzesGd0TT+Tx1OD2fv xAU2ZkqG74G+/jqUJmK28xm/YafVfWWZG1mQhHRb/odiLLMsK0G8532390sy7W1bmKwC QzG64S3ovEBbAhfvcKr6bnmiq42RF5t8g6OCM= Received: by 10.90.101.17 with SMTP id y17mr1055797agb.108.1223612947804; Thu, 09 Oct 2008 21:29:07 -0700 (PDT) Received: by 10.90.26.11 with HTTP; Thu, 9 Oct 2008 21:29:07 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 13:29:07 +0900 From: "Daniel Park" To: "Richard Barnes" In-Reply-To: <48EEB19C.4000303@bbn.com> MIME-Version: 1.0 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> Cc: "p2pi@ietf.org" , "iesg@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428086272==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1428086272== Content-Type: multipart/alternative; boundary="----=_Part_101415_25466507.1223612947772" ------=_Part_101415_25466507.1223612947772 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also agree to move it forward. One example: ALTO issue is quickly coming up in the IPTV business. P2P for IPTV service already takes place in some of standard bodies (e.g., DVB, EBU, etc...). So, it's a good timing not to missing over the important business changes... -- Daniel Park [at] Samsung Electronics Standard Architect, blog.naver.com/natpt On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes wrote: > On the contrary, I perceived pretty strong agreement at the BoF that the > ALTO problem, as expressed in the documents and presentations, as an > important one to solve. There was some disagreement about solutions, but > there seemed to be agreement about the general idea that it would be useful > to create an ALTO service that could help peers optimize their peer > selection. > > The question of "service" versus "server" in the text is a complete > non-issue, purely a matter of wording. In all of the "ALTO service" > scenarios Vidya describes, there is ultimately a single host that provides > ALTO information, which you might as well call an "ALTO server". > > Since it addresses an important problem, and a problem that many people > agree is important, I support moving forward with this work. > > --Richard > > > > Narayanan, Vidya wrote: > >> I am surprised to see that ALTO is being proposed for a WG after the last >> BoF concluded with no consensus whatsoever. I think a second BoF is more >> appropriate than a WG on the topic at this time. That said, I do see the >> need for this work, although I have some comments on the current direction. >> >> Overall, I think we should work with the notion of an ALTO "service" >> rather than specifically an ALTO "server". The ALTO service may be provided >> by a server, a cluster of distributed servers or as a service in an overlay. >> Although some of the charter wording talks about a "service" rather than a >> "server", there is enough mention of a "server" entity to imply a strict >> client-server protocol. >> >> As part of that, I think there are a couple of key things that need to be >> addressed here: >> >> - A protocol that allows peers (or ALTO clients) to publish information >> about themselves as part of the ALTO service. An example of such >> information may be the uplink/downlink bandwidth of the peer. >> >> - The ability to register information types with IANA and extend these. >> The request/response protocol should be a generic enough container for any >> information that peers can provide and look for, plus what may be available >> from service providers, etc. There may be some guidelines on how such >> information types can be registered and we may start with default ones. >> >> Some further comments/questions inline. >> >> -----Original Message----- >>> From: ietf-announce-bounces@ietf.org >>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >>> Sent: Monday, October 06, 2008 1:36 PM >>> To: IETF Announcement list >>> Cc: p2pi@ietf.org >>> Subject: WG Review: Application-Layer Traffic Optimization (alto) >>> >>> A new IETF working group has been proposed in the >>> Applications Area. The IESG has not made any determination >>> as yet. The following draft charter was submitted, and is >>> provided for informational purposes only. Please send your >>> comments to the IESG mailing list (iesg@ietf.org) by Monday, >>> October 13, 2008. >>> >>> Application-Layer Traffic Optimization (alto) >>> ============================================= >>> Last Modified: 2008-09-29 >>> >>> Current Status: Proposed Working Group >>> >>> Chair(s): TBD >>> >>> Applications Area Director(s): >>> >>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman >>> (Chris.Newman at sun.com) >>> >>> Applications Area Advisor: >>> >>> Lisa Dusseault (lisa at osafoundation.org) >>> >>> Mailing List: >>> >>> General Discussion: p2pi at ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi >>> Archive: http://www.ietf.org/pipermail/p2pi/ >>> >>> Description of Working Group: >>> >>> A significant part of the Internet traffic today is generated >>> by peer-to-peer (P2P) applications used for file sharing, >>> real-time communications, and live media streaming. P2P >>> applications exchange large amounts of data, often uploading >>> as much as downloading. In contrast to client/server >>> architectures, P2P applications often have a selection of >>> peers and must choose. >>> >>> One of the advantages of P2P systems comes from redundancy in >>> resource availability. This requires choosing among download >>> locations, yet applications have at best incomplete >>> information about the topology of the network. Applications >>> can sometimes make empirical measurements of link >>> performance, but even when this is an option it takes time. >>> The application cannot always start out with an optimal >>> arrangement of peers, thus causing at least temporary reduced >>> performance and excessive cross-domain traffic. Providing >>> more information for use in peer selection can improve P2P >>> performance and lower ISP costs. >>> >>> The Working Group will design and specify an >>> Application-Layer Traffic Optimization (ALTO) service that >>> will provide applications with information to perform >>> better-than-random initial peer selection. >>> ALTO services may take different approaches at balancing >>> factors including maximum bandwidth, minimum cross-domain >>> traffic, lowest cost to the user, etc. The WG will consider >>> the needs of BitTorrent, tracker-less P2P, and other >>> applications, such as content delivery networks (CDN) and >>> mirror selection. >>> >>> >> What does the above sentence mean? If we are putting such a list together, >> we must also take into account needs from structured P2P overlays such as >> those being specified in P2PSIP. >> >> The WG will focus on the following items: >>> >>> - A "problem statement" document providing a description of the >>> problem and a common terminology. >>> >>> - A requirements document. This document will list >>> requirements for the ALTO service, identifying, for example, >>> what kind of information P2P applications will need for >>> optimizing their choices. >>> >>> - A request/response protocol for querying the ALTO service >>> to obtain information useful for peer selection, and a format >>> for requests and >>> responses. The WG does not require intermediaries between the ALTO >>> server and the peer querying it. If the requirements >>> analysis identifies the need to allow clients to delegate >>> third-parties to query the ALTO service on their behalf, the >>> WG will ensure that the protocol provides a mechanism to >>> assert the consent of the delegating client. >>> >>> >> Is this meant to allow for entities such as proxies to be in the path? >> >> - A document defining core request and response formats and >>> semantics to communicate network preferences to applications. >>> Since ALTO services may be run by entities with different >>> level of knowledge about the underlying network, such >>> preferences may have different representations. Initially the >>> WG will consider: IP ranges to prefer and to avoid, ranked >>> lists of the peers requested by the client, information about >>> topological proximity and approximate geographic locations. >>> Other usages will be considered as extensions to the charter >>> once the work for the initial services has been completed. >>> >>> >> Earlier, it is mentioned that the requirements document will determine the >> types of information that are useful for P2P applications. Given that, it >> seems premature to conclude that the WG should consider the above mentioned >> parameters. Also, as I mentioned earlier, I think it is essential to keep >> the protocol and message formats extensible and allow for exchange of any >> registered information type. >> >> Another question I have is about the assumptions around expected peer >> addressing models. Some of the above seems to hint at IP addresses - is >> this an assumption already? >> >> - In order to query the ALTO server, clients must first know >>> one or more ALTO servers that might provide useful >>> information. The WG will look at service discovery >>> mechanisms that are in use, or defined elsewhere (e.g. >>> based on DNS SRV records or DHCP options). If such discovery >>> mechanisms can be reused, the WG will produce a document to >>> specify how they may be adopted for locating such servers. >>> However, a new, general-purpose service discovery mechanism >>> is not in scope. >>> >>> >> Alternately, the clients may look for ALTO services within an overlay. >> This can be modeled as service discovery within the overlay - I'm, however, >> not suggesting that we take on solutions for that. >> >> When the WG considers standardizing information that the ALTO >>> server could provide, the following criteria are important to >>> ensure real feasibility. >>> >>> - Can the ALTO service technically provide that information? >>> - Is the ALTO service willing to obtain and divulge that information? >>> - Is it information that a client will find useful? >>> >> >> I'm not sure how useful it is for us to answer this question. The >> protocol we develop simply needs to be a container for any information that >> has a registered type and fits a certain format. >> >> - Can a client get that information without excessive privacy concerns >>> (e.g. by sending large lists of peers)? >>> - Is it information that a client cannot find easily some other way? >>> >>> After these criteria are met, the generality of the data will >>> be considered for prioritizing standardization work, for >>> example the number of operators and clients that are likely >>> to be able to provide or use that particular data. >>> >> >> If we can build an extensible protocol, we don't need to define all >> possible kinds of information that get carried in it. >> >> In any >>> case, this WG will not propose standards on how congestion is >>> signaled, remediated, or avoided, and will not deal with >>> information representing instantaneous network state. >>> Such issues belong to other IETF areas and will be treated >>> accordingly by the specific area. >>> >>> This WG will focus solely on the communication protocol >>> between applications and ALTO servers. Note that ALTO >>> services may be useful in client-server environments as well >>> as P2P environments, although P2P environments are the first >>> focus. If, in the future, the IETF considers changes to >>> other protocols for actually implementing ALTO servers (e.g. >>> application-layer protocols for Internet coordinate systems, >>> routing protocol extensions for ISP-based solutions), such >>> work will be done in strict coordination with the appropriate WGs. >>> >>> >> I hope we can also look at the above from a generalized service >> perspective rather than just a client-server perspective. >> >> Thanks, >> Vidya >> >> Issues related to the content exchanged in P2P systems are >>> also excluded from the WG's scope, as is the issue dealing >>> with enforcing the legality of the content. >>> >>> Goals and Milestones (very tentative dates): >>> >>> Apr 2009: Working Group Last Call for problem statement Jun >>> 2009: Submit problem statement to IESG as Informational Aug >>> 2009: Working Group Last Call for requirements document Oct >>> 2009: Submit requirements document to IESG as Informational >>> Jan 2010: Working Group Last Call for request/response >>> protocol Jan 2010: Working Group Last Call for usage document >>> for communicating network preferences Mar 2010: Submit >>> request/response protocol to IESG as Proposed Standard Mar >>> 2010: Submit usage document to IESG as Proposed Standard May >>> 2010: Working Group Last Call of discovery mechanism Jul >>> 2010: Submit discovery mechanism to IESG as Proposed Standard >>> Aug 2010: Dissolve or re-charter >>> >>> Initial Drafts for Consideration >>> - draft-marocco-alto-problem-statement-02 -- >>> Application-Layer Traffic Optimization (ALTO) Problem Statement >>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization >>> (ALTO) Requirements >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_101415_25466507.1223612947772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I also agree to move it forward. One example: ALTO issue is quickly coming up in the IPTV business. P2P for IPTV service already takes place in some of standard bodies (e.g., DVB, EBU, etc...).  So, it's a good timing not to missing over the important business changes...

--
Daniel Park [at] Samsung Electronics
Standard Architect, blog.naver.com/natpt



On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes <rbarnes@bbn.com> wrote:
On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve.  There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection.

The question of "service" versus "server" in the text is a complete non-issue, purely a matter of wording.  In all of the "ALTO service" scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an "ALTO server".

Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work.

--Richard



Narayanan, Vidya wrote:
I am surprised to see that ALTO is being proposed for a WG after the last BoF concluded with no consensus whatsoever.  I think a second BoF is more appropriate than a WG on the topic at this time.  That said, I do see the need for this work, although I have some comments on the current direction.

Overall, I think we should work with the notion of an ALTO "service" rather than specifically an ALTO "server".  The ALTO service may be provided by a server, a cluster of distributed servers or as a service in an overlay.  Although some of the charter wording talks about a "service" rather than a "server", there is enough mention of a "server" entity to imply a strict client-server protocol.

As part of that, I think there are a couple of key things that need to be addressed here:

- A protocol that allows peers (or ALTO clients) to publish information about themselves as part of the ALTO service.  An example of such information may be the uplink/downlink bandwidth of the peer.

- The ability to register information types with IANA and extend these.  The request/response protocol should be a generic enough container for any information that peers can provide and look for, plus what may be available from service providers, etc.  There may be some guidelines on how such information types can be registered and we may start with default ones.

Some further comments/questions inline.

-----Original Message-----
From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary
Sent: Monday, October 06, 2008 1:36 PM
To: IETF Announcement list
Cc: p2pi@ietf.org
Subject: WG Review: Application-Layer Traffic Optimization (alto)

A new IETF working group has been proposed in the
Applications Area.  The IESG has not made any determination
as yet.  The following draft charter was submitted, and is
provided for informational purposes only.  Please send your
comments to the IESG mailing list (iesg@ietf.org) by Monday,
October 13, 2008.

Application-Layer Traffic Optimization (alto)
=============================================
Last Modified: 2008-09-29

Current Status: Proposed Working Group

Chair(s): TBD

Applications Area Director(s):

Lisa Dusseault (lisa at osafoundation.org) Chris Newman
(Chris.Newman at sun.com)

Applications Area Advisor:

Lisa Dusseault (lisa at osafoundation.org)

Mailing List:

General Discussion: p2pi at ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi
Archive: http://www.ietf.org/pipermail/p2pi/

Description of Working Group:

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

One of the advantages of P2P systems comes from redundancy in
resource availability.  This requires choosing among download
locations, yet applications have at best incomplete
information about the topology of the network.  Applications
can sometimes make empirical measurements of link
performance, but even when this is an option it takes time.
The application cannot always start out with an optimal
arrangement of peers, thus causing at least temporary reduced
performance and excessive cross-domain traffic.  Providing
more information for use in peer selection can improve P2P
performance and lower ISP costs.

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


What does the above sentence mean? If we are putting such a list together, we must also take into account needs from structured P2P overlays such as those being specified in P2PSIP.

The WG will focus on the following items:

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

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

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


Is this meant to allow for entities such as proxies to be in the path?

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


Earlier, it is mentioned that the requirements document will determine the types of information that are useful for P2P applications.  Given that, it seems premature to conclude that the WG should consider the above mentioned parameters.  Also, as I mentioned earlier, I think it is essential to keep the protocol and message formats extensible and allow for exchange of any registered information type.

Another question I have is about the assumptions around expected peer addressing models.  Some of the above seems to hint at IP addresses - is this an assumption already?

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


Alternately, the clients may look for ALTO services within an overlay.  This can be modeled as service discovery within the overlay - I'm, however, not suggesting that we take on solutions for that.

When the WG considers standardizing information that the ALTO
server could provide, the following criteria are important to
ensure real feasibility.

- Can the ALTO service technically provide that information?
- Is the ALTO service willing to obtain and divulge that information?
- Is it information that a client will find useful?

I'm not sure how useful it is for us to answer this question.  The protocol we develop simply needs to be a container for any information that has a registered type and fits a certain format.

- Can a client get that information without excessive privacy concerns
 (e.g. by sending large lists of peers)?
- Is it information that a client cannot find easily some other way?

After these criteria are met, the generality of the data will
be considered for prioritizing standardization work, for
example the number of operators and clients that are likely
to be able to provide or use that particular data.

If we can build an extensible protocol, we don't need to define all possible kinds of information that get carried in it.

In any
case, this WG will not propose standards on how congestion is
signaled, remediated, or avoided, and will not deal with
information representing instantaneous network state.
Such issues belong to other IETF areas and will be treated
accordingly by the specific area.

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


I hope we can also look at the above from a generalized service perspective rather than just a client-server perspective.

Thanks,
Vidya

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

Goals and Milestones (very tentative dates):

Apr 2009: Working Group Last Call for problem statement Jun
2009: Submit problem statement to IESG as Informational Aug
2009: Working Group Last Call for requirements document Oct
2009: Submit requirements document to IESG as Informational
Jan 2010: Working Group Last Call for request/response
protocol Jan 2010: Working Group Last Call for usage document
for communicating network preferences Mar 2010: Submit
request/response protocol to IESG as Proposed Standard Mar
2010: Submit usage document to IESG as Proposed Standard May
2010: Working Group Last Call of discovery mechanism Jul
2010: Submit discovery mechanism to IESG as Proposed Standard
Aug 2010: Dissolve or re-charter

Initial Drafts for Consideration
- draft-marocco-alto-problem-statement-02 --
Application-Layer Traffic Optimization (ALTO) Problem Statement
- draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization
(ALTO) Requirements



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf@ietf.org

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

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi




------=_Part_101415_25466507.1223612947772-- --===============1428086272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1428086272==-- From p2pi-bounces@ietf.org Thu Oct 9 21:44:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB7F3A6AA4; Thu, 9 Oct 2008 21:44:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C518C3A6843 for ; Thu, 9 Oct 2008 21:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jU3-XXYfsSbY for ; Thu, 9 Oct 2008 21:44:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0F51D3A69CD for ; Thu, 9 Oct 2008 21:44:48 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ko9sP-00049s-VE; Thu, 09 Oct 2008 21:45:22 -0700 Message-Id: From: Philip Levis To: Richard Barnes In-Reply-To: <48EEB19C.4000303@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 21:45:21 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: p2pi@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 9, 2008, at 6:36 PM, Richard Barnes wrote: > On the contrary, I perceived pretty strong agreement at the BoF that > the ALTO problem, as expressed in the documents and presentations, > as an important one to solve. There was some disagreement about > solutions, but there seemed to be agreement about the general idea > that it would be useful to create an ALTO service that could help > peers optimize their peer selection. > > The question of "service" versus "server" in the text is a complete > non-issue, purely a matter of wording. In all of the "ALTO service" > scenarios Vidya describes, there is ultimately a single host that > provides ALTO information, which you might as well call an "ALTO > server". > > Since it addresses an important problem, and a problem that many > people agree is important, I support moving forward with this work. I agree. This is such a pressing problem that blocking on terminology disputes which can be easily reconciled seems ill-advised. There was an excellent technical discussion on the list after the last IETF, and I think we reached at least rough consensus on the important points. I support moving forward. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 22:16:38 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14BF3A69AF; Thu, 9 Oct 2008 22:16:38 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AB83A6952; Thu, 9 Oct 2008 22:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 q3SYLFdPHim8; Thu, 9 Oct 2008 22:16:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BB7A83A67D8; Thu, 9 Oct 2008 22:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223615841; x=1255151841; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48EEE549.1080208@qualcomm.com>|Date:=20Th u,=2009=20Oct=202008=2022:16:57=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Richard=20Barnes=20|CC:=20"Nara yanan,=20Vidya"=20,=20"p2pi@ietf.org "=20,=0D=0A=20=20=20=20=20=20=20=20"'iesg@ ietf.org'"=20|Subject:=20Re:=20[p2pi]=20WG =20Review:=20Application-Layer=20Traffic=20Optimization =20(alto)|References:=20<20081006203532.B1D673A68AF@core3 .amsl.com>=09=20<48EEB19C.4000303@bbn.com> |In-Reply-To:=20<48EEB19C.4000303@bbn.com>|Content-Type: =20text/plain=3B=20charset=3DISO-8859-15=3B=20format=3Dfl owed|Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E =3DMcAfee=3Bi=3D"5300,2777,5402"=3B=20a=3D"10459624"; bh=6/iSUvxDzj/9KH4tRB2NDAwhZs2HN0ZWEyxndSIblQY=; b=HNfElECg8HstgK9sT+SBKjEBn36Juz0WFLQvCR/XmD/Jsij/0xZaj7k8 rElv9bMJ/jmu6/xPBOZwex6m/iLEuTlD3GmSQFiWUa/hoZFP/wNVdgNpq +7I3Y6STXwp+oN7sNxtUzs9kQQRHv61Tymg5e1YgLMBM+m3BCJXqASTog 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10459624" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 22:17:07 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A5H7eu024243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 22:17:07 -0700 Received: from [10.50.68.165] (qconnect-10-50-68-165.qualcomm.com [10.50.68.165]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A5Gvqu023186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Oct 2008 22:17:02 -0700 Message-ID: <48EEE549.1080208@qualcomm.com> Date: Thu, 09 Oct 2008 22:16:57 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Richard Barnes References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> In-Reply-To: <48EEB19C.4000303@bbn.com> Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 10/9/2008 6:36 PM, Richard Barnes wrote: > On the contrary, I perceived pretty strong agreement at the BoF that the > ALTO problem, as expressed in the documents and presentations, as an > important one to solve. There was some disagreement about solutions, > but there seemed to be agreement about the general idea that it would be > useful to create an ALTO service that could help peers optimize their > peer selection. Richard, The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++++++++++++++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the "no" hums were (in Jon's words) vehement. +++++++++++++++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. > > The question of "service" versus "server" in the text is a complete > non-issue, purely a matter of wording. No it is not; please see below. > In all of the "ALTO service" > scenarios Vidya describes, there is ultimately a single host that > provides ALTO information, which you might as well call an "ALTO server". > A distributed service is not necessarily provided by a single host. > Since it addresses an important problem, and a problem that many people > agree is important, I support moving forward with this work. I for one think that there needs to be much more clarity on the goals and the terminology before just moving forward and producing useless RFCs. regards, Lakshminath > > --Richard > > > > Narayanan, Vidya wrote: >> I am surprised to see that ALTO is being proposed for a WG after the >> last BoF concluded with no consensus whatsoever. I think a second BoF >> is more appropriate than a WG on the topic at this time. That said, I >> do see the need for this work, although I have some comments on the >> current direction. >> >> Overall, I think we should work with the notion of an ALTO "service" >> rather than specifically an ALTO "server". The ALTO service may be >> provided by a server, a cluster of distributed servers or as a service >> in an overlay. Although some of the charter wording talks about a >> "service" rather than a "server", there is enough mention of a >> "server" entity to imply a strict client-server protocol. >> >> As part of that, I think there are a couple of key things that need to >> be addressed here: >> >> - A protocol that allows peers (or ALTO clients) to publish >> information about themselves as part of the ALTO service. An example >> of such information may be the uplink/downlink bandwidth of the peer. >> >> - The ability to register information types with IANA and extend >> these. The request/response protocol should be a generic enough >> container for any information that peers can provide and look for, >> plus what may be available from service providers, etc. There may be >> some guidelines on how such information types can be registered and we >> may start with default ones. >> >> Some further comments/questions inline. >> >>> -----Original Message----- >>> From: ietf-announce-bounces@ietf.org >>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >>> Sent: Monday, October 06, 2008 1:36 PM >>> To: IETF Announcement list >>> Cc: p2pi@ietf.org >>> Subject: WG Review: Application-Layer Traffic Optimization (alto) >>> >>> A new IETF working group has been proposed in the >>> Applications Area. The IESG has not made any determination >>> as yet. The following draft charter was submitted, and is >>> provided for informational purposes only. Please send your >>> comments to the IESG mailing list (iesg@ietf.org) by Monday, >>> October 13, 2008. >>> >>> Application-Layer Traffic Optimization (alto) >>> ============================================= >>> Last Modified: 2008-09-29 >>> >>> Current Status: Proposed Working Group >>> >>> Chair(s): TBD >>> >>> Applications Area Director(s): >>> >>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman >>> (Chris.Newman at sun.com) >>> >>> Applications Area Advisor: >>> >>> Lisa Dusseault (lisa at osafoundation.org) >>> >>> Mailing List: >>> >>> General Discussion: p2pi at ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi >>> Archive: http://www.ietf.org/pipermail/p2pi/ >>> >>> Description of Working Group: >>> >>> A significant part of the Internet traffic today is generated >>> by peer-to-peer (P2P) applications used for file sharing, >>> real-time communications, and live media streaming. P2P >>> applications exchange large amounts of data, often uploading >>> as much as downloading. In contrast to client/server >>> architectures, P2P applications often have a selection of >>> peers and must choose. >>> >>> One of the advantages of P2P systems comes from redundancy in >>> resource availability. This requires choosing among download >>> locations, yet applications have at best incomplete >>> information about the topology of the network. Applications >>> can sometimes make empirical measurements of link >>> performance, but even when this is an option it takes time. >>> The application cannot always start out with an optimal >>> arrangement of peers, thus causing at least temporary reduced >>> performance and excessive cross-domain traffic. Providing >>> more information for use in peer selection can improve P2P >>> performance and lower ISP costs. >>> >>> The Working Group will design and specify an >>> Application-Layer Traffic Optimization (ALTO) service that >>> will provide applications with information to perform >>> better-than-random initial peer selection. >>> ALTO services may take different approaches at balancing >>> factors including maximum bandwidth, minimum cross-domain >>> traffic, lowest cost to the user, etc. The WG will consider >>> the needs of BitTorrent, tracker-less P2P, and other >>> applications, such as content delivery networks (CDN) and >>> mirror selection. >>> >> >> What does the above sentence mean? If we are putting such a list >> together, we must also take into account needs from structured P2P >> overlays such as those being specified in P2PSIP. >> >>> The WG will focus on the following items: >>> >>> - A "problem statement" document providing a description of the >>> problem and a common terminology. >>> >>> - A requirements document. This document will list >>> requirements for the ALTO service, identifying, for example, >>> what kind of information P2P applications will need for >>> optimizing their choices. >>> >>> - A request/response protocol for querying the ALTO service >>> to obtain information useful for peer selection, and a format >>> for requests and >>> responses. The WG does not require intermediaries between the ALTO >>> server and the peer querying it. If the requirements >>> analysis identifies the need to allow clients to delegate >>> third-parties to query the ALTO service on their behalf, the >>> WG will ensure that the protocol provides a mechanism to >>> assert the consent of the delegating client. >>> >> >> Is this meant to allow for entities such as proxies to be in the path? >> >>> - A document defining core request and response formats and >>> semantics to communicate network preferences to applications. >>> Since ALTO services may be run by entities with different >>> level of knowledge about the underlying network, such >>> preferences may have different representations. Initially the >>> WG will consider: IP ranges to prefer and to avoid, ranked >>> lists of the peers requested by the client, information about >>> topological proximity and approximate geographic locations. >>> Other usages will be considered as extensions to the charter >>> once the work for the initial services has been completed. >>> >> >> Earlier, it is mentioned that the requirements document will determine >> the types of information that are useful for P2P applications. Given >> that, it seems premature to conclude that the WG should consider the >> above mentioned parameters. Also, as I mentioned earlier, I think it >> is essential to keep the protocol and message formats extensible and >> allow for exchange of any registered information type. >> >> Another question I have is about the assumptions around expected peer >> addressing models. Some of the above seems to hint at IP addresses - >> is this an assumption already? >> >>> - In order to query the ALTO server, clients must first know >>> one or more ALTO servers that might provide useful >>> information. The WG will look at service discovery >>> mechanisms that are in use, or defined elsewhere (e.g. >>> based on DNS SRV records or DHCP options). If such discovery >>> mechanisms can be reused, the WG will produce a document to >>> specify how they may be adopted for locating such servers. >>> However, a new, general-purpose service discovery mechanism >>> is not in scope. >>> >> >> Alternately, the clients may look for ALTO services within an >> overlay. This can be modeled as service discovery within the overlay >> - I'm, however, not suggesting that we take on solutions for that. >> >>> When the WG considers standardizing information that the ALTO >>> server could provide, the following criteria are important to >>> ensure real feasibility. >>> >>> - Can the ALTO service technically provide that information? >>> - Is the ALTO service willing to obtain and divulge that information? >>> - Is it information that a client will find useful? >> >> I'm not sure how useful it is for us to answer this question. The >> protocol we develop simply needs to be a container for any information >> that has a registered type and fits a certain format. >> >>> - Can a client get that information without excessive privacy concerns >>> (e.g. by sending large lists of peers)? >>> - Is it information that a client cannot find easily some other way? >>> >>> After these criteria are met, the generality of the data will >>> be considered for prioritizing standardization work, for >>> example the number of operators and clients that are likely >>> to be able to provide or use that particular data. >> >> If we can build an extensible protocol, we don't need to define all >> possible kinds of information that get carried in it. >> >>> In any >>> case, this WG will not propose standards on how congestion is >>> signaled, remediated, or avoided, and will not deal with >>> information representing instantaneous network state. >>> Such issues belong to other IETF areas and will be treated >>> accordingly by the specific area. >>> >>> This WG will focus solely on the communication protocol >>> between applications and ALTO servers. Note that ALTO >>> services may be useful in client-server environments as well >>> as P2P environments, although P2P environments are the first >>> focus. If, in the future, the IETF considers changes to >>> other protocols for actually implementing ALTO servers (e.g. >>> application-layer protocols for Internet coordinate systems, >>> routing protocol extensions for ISP-based solutions), such >>> work will be done in strict coordination with the appropriate WGs. >>> >> >> I hope we can also look at the above from a generalized service >> perspective rather than just a client-server perspective. >> >> Thanks, >> Vidya >> >>> Issues related to the content exchanged in P2P systems are >>> also excluded from the WG's scope, as is the issue dealing >>> with enforcing the legality of the content. >>> >>> Goals and Milestones (very tentative dates): >>> >>> Apr 2009: Working Group Last Call for problem statement Jun >>> 2009: Submit problem statement to IESG as Informational Aug >>> 2009: Working Group Last Call for requirements document Oct >>> 2009: Submit requirements document to IESG as Informational >>> Jan 2010: Working Group Last Call for request/response >>> protocol Jan 2010: Working Group Last Call for usage document >>> for communicating network preferences Mar 2010: Submit >>> request/response protocol to IESG as Proposed Standard Mar >>> 2010: Submit usage document to IESG as Proposed Standard May >>> 2010: Working Group Last Call of discovery mechanism Jul >>> 2010: Submit discovery mechanism to IESG as Proposed Standard >>> Aug 2010: Dissolve or re-charter >>> >>> Initial Drafts for Consideration >>> - draft-marocco-alto-problem-statement-02 -- >>> Application-Layer Traffic Optimization (ALTO) Problem Statement >>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization >>> (ALTO) Requirements >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 9 23:07:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95E028C134; Thu, 9 Oct 2008 23:07:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7263028C107; Thu, 9 Oct 2008 23:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 EhaeVr6YNmeE; Thu, 9 Oct 2008 23:06:57 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3C79428C0EA; Thu, 9 Oct 2008 23:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223618863; x=1255154863; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Dondeti,=20Lakshminath"=20,=0D =0A=20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09|CC:=20"p2pi@ietf.org"=20,=20" 'iesg@ietf.org'"=20,=0D=0A=20=20=20=20=20 =20=20=20"ietf@ietf.org"=20|Date:=20Thu, =209=20Oct=202008=2023:07:21=20-0700|Subject:=20RE:=20[p2 pi]=20WG=20Review:=20Application-Layer=20Traffic=20Optimi zation=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review:=20A pplication-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=09=0D=0A =20<48EEB19C.4000303@bbn.com>=20<48EEE549.1080208@qualcom m.com>|In-Reply-To:=20<48EEE549.1080208@qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10547023"; bh=0+6fCBVuUYiM03QnPaWYwMIYrQCuT51h7Az6+bSpXOI=; b=LMxFKHIMJ1Rdd/hbIFkG5Q0Gv6wqa08YzBve5DunfuQlVEvJvepjK3dJ G+ioMj6/zWBbHUJNwV9BodQpFYCGs8i36khwV17TPrY6JONO88H27qjw8 4rgrRMMPbpe6Ls38XGvKi3Ke9LeFXRGzJfCaHiGCpcC/6uTwxRievR8Dm I=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10547023" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 23:07:26 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PuM013850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 23:07:25 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PWB005355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2008 23:07:25 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 9 Oct 2008 23:07:24 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 9 Oct 2008 23:07:23 -0700 From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , Richard Barnes Date: Thu, 9 Oct 2008 23:07:21 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> In-Reply-To: <48EEE549.1080208@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed. I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements. However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal. As Lakshminath notes, the notion of "service" vs. "server" is more than a terminology issue. It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context. I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server. We need to shoot for a much more generic and extensible mechanism. Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value. Regards, Vidya > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Thursday, October 09, 2008 10:17 PM > To: Richard Barnes > Cc: Narayanan, Vidya; p2pi@ietf.org; 'iesg@ietf.org' > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > On 10/9/2008 6:36 PM, Richard Barnes wrote: > > On the contrary, I perceived pretty strong agreement at the > BoF that > > the ALTO problem, as expressed in the documents and > presentations, as > > an important one to solve. There was some disagreement about > > solutions, but there seemed to be agreement about the general idea > > that it would be useful to create an ALTO service that could help > > peers optimize their peer selection. > > Richard, > > The minutes > (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say > this: > > +++++++++++++++ > Many people agreed that this is important work for the IETF, also some > (less) people hummed against. Hum was inconclusive - some of the "no" > hums were (in Jon's words) vehement. > +++++++++++++++ > > Given that there was no consensus, it would have been nice if > the sponsoring AD(s) or the IESG explained what's going on, > but then transparency, it appears, is not really a goal in > this case. If the idea was to just go forward anyway, we > really wasted 3, may be 6 months. > The half measures are a waste of everyone's time. > > > > > The question of "service" versus "server" in the text is a complete > > non-issue, purely a matter of wording. > > No it is not; please see below. > > > In all of the "ALTO service" > > scenarios Vidya describes, there is ultimately a single host that > > provides ALTO information, which you might as well call an > "ALTO server". > > > > A distributed service is not necessarily provided by a single host. > > > Since it addresses an important problem, and a problem that many > > people agree is important, I support moving forward with this work. > > I for one think that there needs to be much more clarity on > the goals and the terminology before just moving forward and > producing useless RFCs. > > regards, > Lakshminath > > > > > --Richard > > > > > > > > Narayanan, Vidya wrote: > >> I am surprised to see that ALTO is being proposed for a WG > after the > >> last BoF concluded with no consensus whatsoever. I think a second > >> BoF is more appropriate than a WG on the topic at this time. That > >> said, I do see the need for this work, although I have > some comments > >> on the current direction. > >> > >> Overall, I think we should work with the notion of an ALTO > "service" > >> rather than specifically an ALTO "server". The ALTO > service may be > >> provided by a server, a cluster of distributed servers or as a > >> service in an overlay. Although some of the charter wording talks > >> about a "service" rather than a "server", there is enough > mention of > >> a "server" entity to imply a strict client-server protocol. > >> > >> As part of that, I think there are a couple of key things > that need > >> to be addressed here: > >> > >> - A protocol that allows peers (or ALTO clients) to publish > >> information about themselves as part of the ALTO service. > An example > >> of such information may be the uplink/downlink bandwidth > of the peer. > >> > >> - The ability to register information types with IANA and extend > >> these. The request/response protocol should be a generic enough > >> container for any information that peers can provide and look for, > >> plus what may be available from service providers, etc. > There may be > >> some guidelines on how such information types can be > registered and > >> we may start with default ones. > >> > >> Some further comments/questions inline. > >> > >>> -----Original Message----- > >>> From: ietf-announce-bounces@ietf.org > >>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG > Secretary > >>> Sent: Monday, October 06, 2008 1:36 PM > >>> To: IETF Announcement list > >>> Cc: p2pi@ietf.org > >>> Subject: WG Review: Application-Layer Traffic Optimization (alto) > >>> > >>> A new IETF working group has been proposed in the > Applications Area. > >>> The IESG has not made any determination as yet. The > following draft > >>> charter was submitted, and is provided for informational purposes > >>> only. Please send your comments to the IESG mailing list > >>> (iesg@ietf.org) by Monday, October 13, 2008. > >>> > >>> Application-Layer Traffic Optimization (alto) > >>> ============================================= > >>> Last Modified: 2008-09-29 > >>> > >>> Current Status: Proposed Working Group > >>> > >>> Chair(s): TBD > >>> > >>> Applications Area Director(s): > >>> > >>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman > >>> (Chris.Newman at sun.com) > >>> > >>> Applications Area Advisor: > >>> > >>> Lisa Dusseault (lisa at osafoundation.org) > >>> > >>> Mailing List: > >>> > >>> General Discussion: p2pi at ietf.org To Subscribe: > >>> https://www.ietf.org/mailman/listinfo/p2pi > >>> Archive: http://www.ietf.org/pipermail/p2pi/ > >>> > >>> Description of Working Group: > >>> > >>> A significant part of the Internet traffic today is generated by > >>> peer-to-peer (P2P) applications used for file sharing, real-time > >>> communications, and live media streaming. P2P > applications exchange > >>> large amounts of data, often uploading as much as > downloading. In > >>> contrast to client/server architectures, P2P applications > often have > >>> a selection of peers and must choose. > >>> > >>> One of the advantages of P2P systems comes from redundancy in > >>> resource availability. This requires choosing among download > >>> locations, yet applications have at best incomplete information > >>> about the topology of the network. Applications can > sometimes make > >>> empirical measurements of link performance, but even when > this is an > >>> option it takes time. > >>> The application cannot always start out with an optimal > arrangement > >>> of peers, thus causing at least temporary reduced performance and > >>> excessive cross-domain traffic. Providing more > information for use > >>> in peer selection can improve P2P performance and lower ISP costs. > >>> > >>> The Working Group will design and specify an Application-Layer > >>> Traffic Optimization (ALTO) service that will provide > applications > >>> with information to perform better-than-random initial peer > >>> selection. > >>> ALTO services may take different approaches at balancing factors > >>> including maximum bandwidth, minimum cross-domain traffic, lowest > >>> cost to the user, etc. The WG will consider the needs of > >>> BitTorrent, tracker-less P2P, and other applications, such as > >>> content delivery networks (CDN) and mirror selection. > >>> > >> > >> What does the above sentence mean? If we are putting such a list > >> together, we must also take into account needs from structured P2P > >> overlays such as those being specified in P2PSIP. > >> > >>> The WG will focus on the following items: > >>> > >>> - A "problem statement" document providing a description of the > >>> problem and a common terminology. > >>> > >>> - A requirements document. This document will list > requirements for > >>> the ALTO service, identifying, for example, what kind of > information > >>> P2P applications will need for optimizing their choices. > >>> > >>> - A request/response protocol for querying the ALTO service to > >>> obtain information useful for peer selection, and a format for > >>> requests and > >>> responses. The WG does not require intermediaries > between the ALTO > >>> server and the peer querying it. If the requirements analysis > >>> identifies the need to allow clients to delegate third-parties to > >>> query the ALTO service on their behalf, the WG will > ensure that the > >>> protocol provides a mechanism to assert the consent of the > >>> delegating client. > >>> > >> > >> Is this meant to allow for entities such as proxies to be > in the path? > >> > >>> - A document defining core request and response formats and > >>> semantics to communicate network preferences to applications. > >>> Since ALTO services may be run by entities with > different level of > >>> knowledge about the underlying network, such preferences may have > >>> different representations. Initially the WG will > consider: IP ranges > >>> to prefer and to avoid, ranked lists of the peers > requested by the > >>> client, information about topological proximity and approximate > >>> geographic locations. > >>> Other usages will be considered as extensions to the charter once > >>> the work for the initial services has been completed. > >>> > >> > >> Earlier, it is mentioned that the requirements document will > >> determine the types of information that are useful for P2P > >> applications. Given that, it seems premature to conclude > that the WG > >> should consider the above mentioned parameters. Also, as > I mentioned > >> earlier, I think it is essential to keep the protocol and message > >> formats extensible and allow for exchange of any > registered information type. > >> > >> Another question I have is about the assumptions around > expected peer > >> addressing models. Some of the above seems to hint at IP > addresses - > >> is this an assumption already? > >> > >>> - In order to query the ALTO server, clients must first > know one or > >>> more ALTO servers that might provide useful information. The WG > >>> will look at service discovery mechanisms that are in use, or > >>> defined elsewhere (e.g. > >>> based on DNS SRV records or DHCP options). If such discovery > >>> mechanisms can be reused, the WG will produce a document > to specify > >>> how they may be adopted for locating such servers. > >>> However, a new, general-purpose service discovery > mechanism is not > >>> in scope. > >>> > >> > >> Alternately, the clients may look for ALTO services within an > >> overlay. This can be modeled as service discovery within > the overlay > >> - I'm, however, not suggesting that we take on solutions for that. > >> > >>> When the WG considers standardizing information that the > ALTO server > >>> could provide, the following criteria are important to > ensure real > >>> feasibility. > >>> > >>> - Can the ALTO service technically provide that information? > >>> - Is the ALTO service willing to obtain and divulge that > information? > >>> - Is it information that a client will find useful? > >> > >> I'm not sure how useful it is for us to answer this question. The > >> protocol we develop simply needs to be a container for any > >> information that has a registered type and fits a certain format. > >> > >>> - Can a client get that information without excessive > privacy concerns > >>> (e.g. by sending large lists of peers)? > >>> - Is it information that a client cannot find easily some > other way? > >>> > >>> After these criteria are met, the generality of the data will be > >>> considered for prioritizing standardization work, for example the > >>> number of operators and clients that are likely to be able to > >>> provide or use that particular data. > >> > >> If we can build an extensible protocol, we don't need to > define all > >> possible kinds of information that get carried in it. > >> > >>> In any > >>> case, this WG will not propose standards on how congestion is > >>> signaled, remediated, or avoided, and will not deal with > information > >>> representing instantaneous network state. > >>> Such issues belong to other IETF areas and will be treated > >>> accordingly by the specific area. > >>> > >>> This WG will focus solely on the communication protocol between > >>> applications and ALTO servers. Note that ALTO services may be > >>> useful in client-server environments as well as P2P environments, > >>> although P2P environments are the first focus. If, in > the future, > >>> the IETF considers changes to other protocols for actually > >>> implementing ALTO servers (e.g. > >>> application-layer protocols for Internet coordinate > systems, routing > >>> protocol extensions for ISP-based solutions), such work > will be done > >>> in strict coordination with the appropriate WGs. > >>> > >> > >> I hope we can also look at the above from a generalized service > >> perspective rather than just a client-server perspective. > >> > >> Thanks, > >> Vidya > >> > >>> Issues related to the content exchanged in P2P systems are also > >>> excluded from the WG's scope, as is the issue dealing > with enforcing > >>> the legality of the content. > >>> > >>> Goals and Milestones (very tentative dates): > >>> > >>> Apr 2009: Working Group Last Call for problem statement Jun > >>> 2009: Submit problem statement to IESG as Informational Aug > >>> 2009: Working Group Last Call for requirements document Oct > >>> 2009: Submit requirements document to IESG as Informational Jan > >>> 2010: Working Group Last Call for request/response protocol Jan > >>> 2010: Working Group Last Call for usage document for > communicating > >>> network preferences Mar 2010: Submit request/response protocol to > >>> IESG as Proposed Standard Mar > >>> 2010: Submit usage document to IESG as Proposed Standard May > >>> 2010: Working Group Last Call of discovery mechanism Jul > >>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug > >>> 2010: Dissolve or re-charter > >>> > >>> Initial Drafts for Consideration > >>> - draft-marocco-alto-problem-statement-02 -- Application-Layer > >>> Traffic Optimization (ALTO) Problem Statement > >>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic > >>> Optimization > >>> (ALTO) Requirements > >>> > >>> > >>> > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 02:06:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87E13A6A85; Fri, 10 Oct 2008 02:06:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CF228C115 for ; Fri, 10 Oct 2008 02:06:02 -0700 (PDT) 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 tgxXBz6QubIu for ; Fri, 10 Oct 2008 02:05:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id B8F483A6857 for ; Fri, 10 Oct 2008 02:05:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9A96fI11685 for ; Fri, 10 Oct 2008 11:06:41 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp807.cisco.com [10.61.67.39]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9A96eG11653 for ; Fri, 10 Oct 2008 11:06:40 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 10 Oct 2008 11:06:32 +0200 From: stefano previdi To: "p2pi@ietf.org" Message-ID: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7gAAbMAnA= In-Reply-To: Mime-version: 1.0 Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org It was evident that the Dublin BoF went well but also evident that it ended without consensus on the work that a ALTO WG should do/not do. However, it looks to me that the 200 and more emails that followed the BoF, allowed us to find some form of agreement on the direction ALTO community should look at. A few weeks later we had a new (revised) charter document. It has been sent to the mailing list and slightly amended (nothing really substantial as I recall). This also enforces the idea that we reached substantial consensus. We may argue that consensus reached is not enough for a WG creation but sincerely this is not my perception. Naively, I tend to believe that a WG can be created once agreement exists on problem statement and charter. Once WG is created, consensus is anyway required for any standardization process so, we'll have a lot of other opportunities for disagreement... thanks. s. > From: "Narayanan, Vidya" > Date: Thu, 9 Oct 2008 23:07:21 -0700 > To: "Dondeti, Lakshminath" , Richard Barnes > > Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" , > "ietf@ietf.org" > Conversation: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > > Contrary to what some people seem to have interpreted my email to mean, I did > actually say that the work is needed. I was noting the lack of consensus from > the last BoF and I definitely feel a second BoF is more appropriate at this > time to iron out the disagreements. However, I am still not trying to block > the work - I am saying that there are some critical things to alter in the > charter proposal. > > As Lakshminath notes, the notion of "service" vs. "server" is more than a > terminology issue. It is important that we consider the possibility of ALTO > being provided as a distributed service, potentially in an overlay context. I > also see the charter being restrictive in terms of assuming a subset of > information types to be provided by the ALTO server. We need to shoot for a > much more generic and extensible mechanism. Another important missing piece > is the ability for peers to publish information about themselves - without > that, the request/response protocol alone carries much less value. > > Regards, > Vidya > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Thursday, October 09, 2008 10:17 PM >> To: Richard Barnes >> Cc: Narayanan, Vidya; p2pi@ietf.org; 'iesg@ietf.org' >> Subject: Re: [p2pi] WG Review: Application-Layer Traffic >> Optimization (alto) >> >> On 10/9/2008 6:36 PM, Richard Barnes wrote: >>> On the contrary, I perceived pretty strong agreement at the >> BoF that >>> the ALTO problem, as expressed in the documents and >> presentations, as >>> an important one to solve. There was some disagreement about >>> solutions, but there seemed to be agreement about the general idea >>> that it would be useful to create an ALTO service that could help >>> peers optimize their peer selection. >> >> Richard, >> >> The minutes >> (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say >> this: >> >> +++++++++++++++ >> Many people agreed that this is important work for the IETF, also some >> (less) people hummed against. Hum was inconclusive - some of the "no" >> hums were (in Jon's words) vehement. >> +++++++++++++++ >> >> Given that there was no consensus, it would have been nice if >> the sponsoring AD(s) or the IESG explained what's going on, >> but then transparency, it appears, is not really a goal in >> this case. If the idea was to just go forward anyway, we >> really wasted 3, may be 6 months. >> The half measures are a waste of everyone's time. >> >>> >>> The question of "service" versus "server" in the text is a complete >>> non-issue, purely a matter of wording. >> >> No it is not; please see below. >> >>> In all of the "ALTO service" >>> scenarios Vidya describes, there is ultimately a single host that >>> provides ALTO information, which you might as well call an >> "ALTO server". >>> >> >> A distributed service is not necessarily provided by a single host. >> >>> Since it addresses an important problem, and a problem that many >>> people agree is important, I support moving forward with this work. >> >> I for one think that there needs to be much more clarity on >> the goals and the terminology before just moving forward and >> producing useless RFCs. >> >> regards, >> Lakshminath >> >>> >>> --Richard >>> >>> >>> >>> Narayanan, Vidya wrote: >>>> I am surprised to see that ALTO is being proposed for a WG >> after the >>>> last BoF concluded with no consensus whatsoever. I think a second >>>> BoF is more appropriate than a WG on the topic at this time. That >>>> said, I do see the need for this work, although I have >> some comments >>>> on the current direction. >>>> >>>> Overall, I think we should work with the notion of an ALTO >> "service" >>>> rather than specifically an ALTO "server". The ALTO >> service may be >>>> provided by a server, a cluster of distributed servers or as a >>>> service in an overlay. Although some of the charter wording talks >>>> about a "service" rather than a "server", there is enough >> mention of >>>> a "server" entity to imply a strict client-server protocol. >>>> >>>> As part of that, I think there are a couple of key things >> that need >>>> to be addressed here: >>>> >>>> - A protocol that allows peers (or ALTO clients) to publish >>>> information about themselves as part of the ALTO service. >> An example >>>> of such information may be the uplink/downlink bandwidth >> of the peer. >>>> >>>> - The ability to register information types with IANA and extend >>>> these. The request/response protocol should be a generic enough >>>> container for any information that peers can provide and look for, >>>> plus what may be available from service providers, etc. >> There may be >>>> some guidelines on how such information types can be >> registered and >>>> we may start with default ones. >>>> >>>> Some further comments/questions inline. >>>> >>>>> -----Original Message----- >>>>> From: ietf-announce-bounces@ietf.org >>>>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG >> Secretary >>>>> Sent: Monday, October 06, 2008 1:36 PM >>>>> To: IETF Announcement list >>>>> Cc: p2pi@ietf.org >>>>> Subject: WG Review: Application-Layer Traffic Optimization (alto) >>>>> >>>>> A new IETF working group has been proposed in the >> Applications Area. >>>>> The IESG has not made any determination as yet. The >> following draft >>>>> charter was submitted, and is provided for informational purposes >>>>> only. Please send your comments to the IESG mailing list >>>>> (iesg@ietf.org) by Monday, October 13, 2008. >>>>> >>>>> Application-Layer Traffic Optimization (alto) >>>>> ============================================= >>>>> Last Modified: 2008-09-29 >>>>> >>>>> Current Status: Proposed Working Group >>>>> >>>>> Chair(s): TBD >>>>> >>>>> Applications Area Director(s): >>>>> >>>>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman >>>>> (Chris.Newman at sun.com) >>>>> >>>>> Applications Area Advisor: >>>>> >>>>> Lisa Dusseault (lisa at osafoundation.org) >>>>> >>>>> Mailing List: >>>>> >>>>> General Discussion: p2pi at ietf.org To Subscribe: >>>>> https://www.ietf.org/mailman/listinfo/p2pi >>>>> Archive: http://www.ietf.org/pipermail/p2pi/ >>>>> >>>>> Description of Working Group: >>>>> >>>>> A significant part of the Internet traffic today is generated by >>>>> peer-to-peer (P2P) applications used for file sharing, real-time >>>>> communications, and live media streaming. P2P >> applications exchange >>>>> large amounts of data, often uploading as much as >> downloading. In >>>>> contrast to client/server architectures, P2P applications >> often have >>>>> a selection of peers and must choose. >>>>> >>>>> One of the advantages of P2P systems comes from redundancy in >>>>> resource availability. This requires choosing among download >>>>> locations, yet applications have at best incomplete information >>>>> about the topology of the network. Applications can >> sometimes make >>>>> empirical measurements of link performance, but even when >> this is an >>>>> option it takes time. >>>>> The application cannot always start out with an optimal >> arrangement >>>>> of peers, thus causing at least temporary reduced performance and >>>>> excessive cross-domain traffic. Providing more >> information for use >>>>> in peer selection can improve P2P performance and lower ISP costs. >>>>> >>>>> The Working Group will design and specify an Application-Layer >>>>> Traffic Optimization (ALTO) service that will provide >> applications >>>>> with information to perform better-than-random initial peer >>>>> selection. >>>>> ALTO services may take different approaches at balancing factors >>>>> including maximum bandwidth, minimum cross-domain traffic, lowest >>>>> cost to the user, etc. The WG will consider the needs of >>>>> BitTorrent, tracker-less P2P, and other applications, such as >>>>> content delivery networks (CDN) and mirror selection. >>>>> >>>> >>>> What does the above sentence mean? If we are putting such a list >>>> together, we must also take into account needs from structured P2P >>>> overlays such as those being specified in P2PSIP. >>>> >>>>> The WG will focus on the following items: >>>>> >>>>> - A "problem statement" document providing a description of the >>>>> problem and a common terminology. >>>>> >>>>> - A requirements document. This document will list >> requirements for >>>>> the ALTO service, identifying, for example, what kind of >> information >>>>> P2P applications will need for optimizing their choices. >>>>> >>>>> - A request/response protocol for querying the ALTO service to >>>>> obtain information useful for peer selection, and a format for >>>>> requests and >>>>> responses. The WG does not require intermediaries >> between the ALTO >>>>> server and the peer querying it. If the requirements analysis >>>>> identifies the need to allow clients to delegate third-parties to >>>>> query the ALTO service on their behalf, the WG will >> ensure that the >>>>> protocol provides a mechanism to assert the consent of the >>>>> delegating client. >>>>> >>>> >>>> Is this meant to allow for entities such as proxies to be >> in the path? >>>> >>>>> - A document defining core request and response formats and >>>>> semantics to communicate network preferences to applications. >>>>> Since ALTO services may be run by entities with >> different level of >>>>> knowledge about the underlying network, such preferences may have >>>>> different representations. Initially the WG will >> consider: IP ranges >>>>> to prefer and to avoid, ranked lists of the peers >> requested by the >>>>> client, information about topological proximity and approximate >>>>> geographic locations. >>>>> Other usages will be considered as extensions to the charter once >>>>> the work for the initial services has been completed. >>>>> >>>> >>>> Earlier, it is mentioned that the requirements document will >>>> determine the types of information that are useful for P2P >>>> applications. Given that, it seems premature to conclude >> that the WG >>>> should consider the above mentioned parameters. Also, as >> I mentioned >>>> earlier, I think it is essential to keep the protocol and message >>>> formats extensible and allow for exchange of any >> registered information type. >>>> >>>> Another question I have is about the assumptions around >> expected peer >>>> addressing models. Some of the above seems to hint at IP >> addresses - >>>> is this an assumption already? >>>> >>>>> - In order to query the ALTO server, clients must first >> know one or >>>>> more ALTO servers that might provide useful information. The WG >>>>> will look at service discovery mechanisms that are in use, or >>>>> defined elsewhere (e.g. >>>>> based on DNS SRV records or DHCP options). If such discovery >>>>> mechanisms can be reused, the WG will produce a document >> to specify >>>>> how they may be adopted for locating such servers. >>>>> However, a new, general-purpose service discovery >> mechanism is not >>>>> in scope. >>>>> >>>> >>>> Alternately, the clients may look for ALTO services within an >>>> overlay. This can be modeled as service discovery within >> the overlay >>>> - I'm, however, not suggesting that we take on solutions for that. >>>> >>>>> When the WG considers standardizing information that the >> ALTO server >>>>> could provide, the following criteria are important to >> ensure real >>>>> feasibility. >>>>> >>>>> - Can the ALTO service technically provide that information? >>>>> - Is the ALTO service willing to obtain and divulge that >> information? >>>>> - Is it information that a client will find useful? >>>> >>>> I'm not sure how useful it is for us to answer this question. The >>>> protocol we develop simply needs to be a container for any >>>> information that has a registered type and fits a certain format. >>>> >>>>> - Can a client get that information without excessive >> privacy concerns >>>>> (e.g. by sending large lists of peers)? >>>>> - Is it information that a client cannot find easily some >> other way? >>>>> >>>>> After these criteria are met, the generality of the data will be >>>>> considered for prioritizing standardization work, for example the >>>>> number of operators and clients that are likely to be able to >>>>> provide or use that particular data. >>>> >>>> If we can build an extensible protocol, we don't need to >> define all >>>> possible kinds of information that get carried in it. >>>> >>>>> In any >>>>> case, this WG will not propose standards on how congestion is >>>>> signaled, remediated, or avoided, and will not deal with >> information >>>>> representing instantaneous network state. >>>>> Such issues belong to other IETF areas and will be treated >>>>> accordingly by the specific area. >>>>> >>>>> This WG will focus solely on the communication protocol between >>>>> applications and ALTO servers. Note that ALTO services may be >>>>> useful in client-server environments as well as P2P environments, >>>>> although P2P environments are the first focus. If, in >> the future, >>>>> the IETF considers changes to other protocols for actually >>>>> implementing ALTO servers (e.g. >>>>> application-layer protocols for Internet coordinate >> systems, routing >>>>> protocol extensions for ISP-based solutions), such work >> will be done >>>>> in strict coordination with the appropriate WGs. >>>>> >>>> >>>> I hope we can also look at the above from a generalized service >>>> perspective rather than just a client-server perspective. >>>> >>>> Thanks, >>>> Vidya >>>> >>>>> Issues related to the content exchanged in P2P systems are also >>>>> excluded from the WG's scope, as is the issue dealing >> with enforcing >>>>> the legality of the content. >>>>> >>>>> Goals and Milestones (very tentative dates): >>>>> >>>>> Apr 2009: Working Group Last Call for problem statement Jun >>>>> 2009: Submit problem statement to IESG as Informational Aug >>>>> 2009: Working Group Last Call for requirements document Oct >>>>> 2009: Submit requirements document to IESG as Informational Jan >>>>> 2010: Working Group Last Call for request/response protocol Jan >>>>> 2010: Working Group Last Call for usage document for >> communicating >>>>> network preferences Mar 2010: Submit request/response protocol to >>>>> IESG as Proposed Standard Mar >>>>> 2010: Submit usage document to IESG as Proposed Standard May >>>>> 2010: Working Group Last Call of discovery mechanism Jul >>>>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug >>>>> 2010: Dissolve or re-charter >>>>> >>>>> Initial Drafts for Consideration >>>>> - draft-marocco-alto-problem-statement-02 -- Application-Layer >>>>> Traffic Optimization (ALTO) Problem Statement >>>>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic >>>>> Optimization >>>>> (ALTO) Requirements >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >>> >> > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 02:22:14 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ECF3A6908; Fri, 10 Oct 2008 02:22:14 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCD93A6908; Fri, 10 Oct 2008 02:22:13 -0700 (PDT) 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 aIlFIBqtRNBA; Fri, 10 Oct 2008 02:22:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 9A5933A67D8; Fri, 10 Oct 2008 02:22:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9A9Lro08979; Fri, 10 Oct 2008 11:21:53 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp807.cisco.com [10.61.67.39]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9A9LqG08942; Fri, 10 Oct 2008 11:21:52 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 10 Oct 2008 11:21:45 +0200 From: stefano previdi To: "p2pi@ietf.org" Message-ID: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckquZ0c228ha5asEd2KWgAX8vOM8g== Mime-version: 1.0 Cc: "ietf@ietf.org" , "'iesg@ietf.org'" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org It was evident that the Dublin BoF went well but also evident that it ended without consensus on the work that a ALTO WG should do/not do. However, it looks to me that the 200 and more emails that followed the BoF, allowed us to find some form of agreement on the direction ALTO community should look at. A few weeks later we had a new (revised) charter document. It has been sent to the mailing list and slightly amended (nothing really substantial as I recall). This also enforces the idea that we reached substantial consensus. We may argue that consensus reached is not enough for a WG creation but sincerely this is not my perception. Naively, I tend to believe that a WG can be created once agreement exists on problem statement and charter. Once WG is created, consensus is anyway required for any standardization process so, we'll have a lot of other opportunities for disagreement... thanks. s. > From: "Narayanan, Vidya" > Date: Thu, 9 Oct 2008 23:07:21 -0700 > To: "Dondeti, Lakshminath" , Richard Barnes > > Cc: "p2pi@ietf.org" , "'iesg@ietf.org'" , > "ietf@ietf.org" > Conversation: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > > Contrary to what some people seem to have interpreted my email to mean, I did > actually say that the work is needed. I was noting the lack of consensus from > the last BoF and I definitely feel a second BoF is more appropriate at this > time to iron out the disagreements. However, I am still not trying to block > the work - I am saying that there are some critical things to alter in the > charter proposal. > > As Lakshminath notes, the notion of "service" vs. "server" is more than a > terminology issue. It is important that we consider the possibility of ALTO > being provided as a distributed service, potentially in an overlay context. I > also see the charter being restrictive in terms of assuming a subset of > information types to be provided by the ALTO server. We need to shoot for a > much more generic and extensible mechanism. Another important missing piece > is the ability for peers to publish information about themselves - without > that, the request/response protocol alone carries much less value. > > Regards, > Vidya > >> -----Original Message----- >> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] >> Sent: Thursday, October 09, 2008 10:17 PM >> To: Richard Barnes >> Cc: Narayanan, Vidya; p2pi@ietf.org; 'iesg@ietf.org' >> Subject: Re: [p2pi] WG Review: Application-Layer Traffic >> Optimization (alto) >> >> On 10/9/2008 6:36 PM, Richard Barnes wrote: >>> On the contrary, I perceived pretty strong agreement at the >> BoF that >>> the ALTO problem, as expressed in the documents and >> presentations, as >>> an important one to solve. There was some disagreement about >>> solutions, but there seemed to be agreement about the general idea >>> that it would be useful to create an ALTO service that could help >>> peers optimize their peer selection. >> >> Richard, >> >> The minutes >> (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say >> this: >> >> +++++++++++++++ >> Many people agreed that this is important work for the IETF, also some >> (less) people hummed against. Hum was inconclusive - some of the "no" >> hums were (in Jon's words) vehement. >> +++++++++++++++ >> >> Given that there was no consensus, it would have been nice if >> the sponsoring AD(s) or the IESG explained what's going on, >> but then transparency, it appears, is not really a goal in >> this case. If the idea was to just go forward anyway, we >> really wasted 3, may be 6 months. >> The half measures are a waste of everyone's time. >> >>> >>> The question of "service" versus "server" in the text is a complete >>> non-issue, purely a matter of wording. >> >> No it is not; please see below. >> >>> In all of the "ALTO service" >>> scenarios Vidya describes, there is ultimately a single host that >>> provides ALTO information, which you might as well call an >> "ALTO server". >>> >> >> A distributed service is not necessarily provided by a single host. >> >>> Since it addresses an important problem, and a problem that many >>> people agree is important, I support moving forward with this work. >> >> I for one think that there needs to be much more clarity on >> the goals and the terminology before just moving forward and >> producing useless RFCs. >> >> regards, >> Lakshminath >> >>> >>> --Richard >>> >>> >>> >>> Narayanan, Vidya wrote: >>>> I am surprised to see that ALTO is being proposed for a WG >> after the >>>> last BoF concluded with no consensus whatsoever. I think a second >>>> BoF is more appropriate than a WG on the topic at this time. That >>>> said, I do see the need for this work, although I have >> some comments >>>> on the current direction. >>>> >>>> Overall, I think we should work with the notion of an ALTO >> "service" >>>> rather than specifically an ALTO "server". The ALTO >> service may be >>>> provided by a server, a cluster of distributed servers or as a >>>> service in an overlay. Although some of the charter wording talks >>>> about a "service" rather than a "server", there is enough >> mention of >>>> a "server" entity to imply a strict client-server protocol. >>>> >>>> As part of that, I think there are a couple of key things >> that need >>>> to be addressed here: >>>> >>>> - A protocol that allows peers (or ALTO clients) to publish >>>> information about themselves as part of the ALTO service. >> An example >>>> of such information may be the uplink/downlink bandwidth >> of the peer. >>>> >>>> - The ability to register information types with IANA and extend >>>> these. The request/response protocol should be a generic enough >>>> container for any information that peers can provide and look for, >>>> plus what may be available from service providers, etc. >> There may be >>>> some guidelines on how such information types can be >> registered and >>>> we may start with default ones. >>>> >>>> Some further comments/questions inline. >>>> >>>>> -----Original Message----- >>>>> From: ietf-announce-bounces@ietf.org >>>>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG >> Secretary >>>>> Sent: Monday, October 06, 2008 1:36 PM >>>>> To: IETF Announcement list >>>>> Cc: p2pi@ietf.org >>>>> Subject: WG Review: Application-Layer Traffic Optimization (alto) >>>>> >>>>> A new IETF working group has been proposed in the >> Applications Area. >>>>> The IESG has not made any determination as yet. The >> following draft >>>>> charter was submitted, and is provided for informational purposes >>>>> only. Please send your comments to the IESG mailing list >>>>> (iesg@ietf.org) by Monday, October 13, 2008. >>>>> >>>>> Application-Layer Traffic Optimization (alto) >>>>> ============================================= >>>>> Last Modified: 2008-09-29 >>>>> >>>>> Current Status: Proposed Working Group >>>>> >>>>> Chair(s): TBD >>>>> >>>>> Applications Area Director(s): >>>>> >>>>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman >>>>> (Chris.Newman at sun.com) >>>>> >>>>> Applications Area Advisor: >>>>> >>>>> Lisa Dusseault (lisa at osafoundation.org) >>>>> >>>>> Mailing List: >>>>> >>>>> General Discussion: p2pi at ietf.org To Subscribe: >>>>> https://www.ietf.org/mailman/listinfo/p2pi >>>>> Archive: http://www.ietf.org/pipermail/p2pi/ >>>>> >>>>> Description of Working Group: >>>>> >>>>> A significant part of the Internet traffic today is generated by >>>>> peer-to-peer (P2P) applications used for file sharing, real-time >>>>> communications, and live media streaming. P2P >> applications exchange >>>>> large amounts of data, often uploading as much as >> downloading. In >>>>> contrast to client/server architectures, P2P applications >> often have >>>>> a selection of peers and must choose. >>>>> >>>>> One of the advantages of P2P systems comes from redundancy in >>>>> resource availability. This requires choosing among download >>>>> locations, yet applications have at best incomplete information >>>>> about the topology of the network. Applications can >> sometimes make >>>>> empirical measurements of link performance, but even when >> this is an >>>>> option it takes time. >>>>> The application cannot always start out with an optimal >> arrangement >>>>> of peers, thus causing at least temporary reduced performance and >>>>> excessive cross-domain traffic. Providing more >> information for use >>>>> in peer selection can improve P2P performance and lower ISP costs. >>>>> >>>>> The Working Group will design and specify an Application-Layer >>>>> Traffic Optimization (ALTO) service that will provide >> applications >>>>> with information to perform better-than-random initial peer >>>>> selection. >>>>> ALTO services may take different approaches at balancing factors >>>>> including maximum bandwidth, minimum cross-domain traffic, lowest >>>>> cost to the user, etc. The WG will consider the needs of >>>>> BitTorrent, tracker-less P2P, and other applications, such as >>>>> content delivery networks (CDN) and mirror selection. >>>>> >>>> >>>> What does the above sentence mean? If we are putting such a list >>>> together, we must also take into account needs from structured P2P >>>> overlays such as those being specified in P2PSIP. >>>> >>>>> The WG will focus on the following items: >>>>> >>>>> - A "problem statement" document providing a description of the >>>>> problem and a common terminology. >>>>> >>>>> - A requirements document. This document will list >> requirements for >>>>> the ALTO service, identifying, for example, what kind of >> information >>>>> P2P applications will need for optimizing their choices. >>>>> >>>>> - A request/response protocol for querying the ALTO service to >>>>> obtain information useful for peer selection, and a format for >>>>> requests and >>>>> responses. The WG does not require intermediaries >> between the ALTO >>>>> server and the peer querying it. If the requirements analysis >>>>> identifies the need to allow clients to delegate third-parties to >>>>> query the ALTO service on their behalf, the WG will >> ensure that the >>>>> protocol provides a mechanism to assert the consent of the >>>>> delegating client. >>>>> >>>> >>>> Is this meant to allow for entities such as proxies to be >> in the path? >>>> >>>>> - A document defining core request and response formats and >>>>> semantics to communicate network preferences to applications. >>>>> Since ALTO services may be run by entities with >> different level of >>>>> knowledge about the underlying network, such preferences may have >>>>> different representations. Initially the WG will >> consider: IP ranges >>>>> to prefer and to avoid, ranked lists of the peers >> requested by the >>>>> client, information about topological proximity and approximate >>>>> geographic locations. >>>>> Other usages will be considered as extensions to the charter once >>>>> the work for the initial services has been completed. >>>>> >>>> >>>> Earlier, it is mentioned that the requirements document will >>>> determine the types of information that are useful for P2P >>>> applications. Given that, it seems premature to conclude >> that the WG >>>> should consider the above mentioned parameters. Also, as >> I mentioned >>>> earlier, I think it is essential to keep the protocol and message >>>> formats extensible and allow for exchange of any >> registered information type. >>>> >>>> Another question I have is about the assumptions around >> expected peer >>>> addressing models. Some of the above seems to hint at IP >> addresses - >>>> is this an assumption already? >>>> >>>>> - In order to query the ALTO server, clients must first >> know one or >>>>> more ALTO servers that might provide useful information. The WG >>>>> will look at service discovery mechanisms that are in use, or >>>>> defined elsewhere (e.g. >>>>> based on DNS SRV records or DHCP options). If such discovery >>>>> mechanisms can be reused, the WG will produce a document >> to specify >>>>> how they may be adopted for locating such servers. >>>>> However, a new, general-purpose service discovery >> mechanism is not >>>>> in scope. >>>>> >>>> >>>> Alternately, the clients may look for ALTO services within an >>>> overlay. This can be modeled as service discovery within >> the overlay >>>> - I'm, however, not suggesting that we take on solutions for that. >>>> >>>>> When the WG considers standardizing information that the >> ALTO server >>>>> could provide, the following criteria are important to >> ensure real >>>>> feasibility. >>>>> >>>>> - Can the ALTO service technically provide that information? >>>>> - Is the ALTO service willing to obtain and divulge that >> information? >>>>> - Is it information that a client will find useful? >>>> >>>> I'm not sure how useful it is for us to answer this question. The >>>> protocol we develop simply needs to be a container for any >>>> information that has a registered type and fits a certain format. >>>> >>>>> - Can a client get that information without excessive >> privacy concerns >>>>> (e.g. by sending large lists of peers)? >>>>> - Is it information that a client cannot find easily some >> other way? >>>>> >>>>> After these criteria are met, the generality of the data will be >>>>> considered for prioritizing standardization work, for example the >>>>> number of operators and clients that are likely to be able to >>>>> provide or use that particular data. >>>> >>>> If we can build an extensible protocol, we don't need to >> define all >>>> possible kinds of information that get carried in it. >>>> >>>>> In any >>>>> case, this WG will not propose standards on how congestion is >>>>> signaled, remediated, or avoided, and will not deal with >> information >>>>> representing instantaneous network state. >>>>> Such issues belong to other IETF areas and will be treated >>>>> accordingly by the specific area. >>>>> >>>>> This WG will focus solely on the communication protocol between >>>>> applications and ALTO servers. Note that ALTO services may be >>>>> useful in client-server environments as well as P2P environments, >>>>> although P2P environments are the first focus. If, in >> the future, >>>>> the IETF considers changes to other protocols for actually >>>>> implementing ALTO servers (e.g. >>>>> application-layer protocols for Internet coordinate >> systems, routing >>>>> protocol extensions for ISP-based solutions), such work >> will be done >>>>> in strict coordination with the appropriate WGs. >>>>> >>>> >>>> I hope we can also look at the above from a generalized service >>>> perspective rather than just a client-server perspective. >>>> >>>> Thanks, >>>> Vidya >>>> >>>>> Issues related to the content exchanged in P2P systems are also >>>>> excluded from the WG's scope, as is the issue dealing >> with enforcing >>>>> the legality of the content. >>>>> >>>>> Goals and Milestones (very tentative dates): >>>>> >>>>> Apr 2009: Working Group Last Call for problem statement Jun >>>>> 2009: Submit problem statement to IESG as Informational Aug >>>>> 2009: Working Group Last Call for requirements document Oct >>>>> 2009: Submit requirements document to IESG as Informational Jan >>>>> 2010: Working Group Last Call for request/response protocol Jan >>>>> 2010: Working Group Last Call for usage document for >> communicating >>>>> network preferences Mar 2010: Submit request/response protocol to >>>>> IESG as Proposed Standard Mar >>>>> 2010: Submit usage document to IESG as Proposed Standard May >>>>> 2010: Working Group Last Call of discovery mechanism Jul >>>>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug >>>>> 2010: Dissolve or re-charter >>>>> >>>>> Initial Drafts for Consideration >>>>> - draft-marocco-alto-problem-statement-02 -- Application-Layer >>>>> Traffic Optimization (ALTO) Problem Statement >>>>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic >>>>> Optimization >>>>> (ALTO) Requirements >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >>> >> > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 03:12:22 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89B428C197; Fri, 10 Oct 2008 03:12:22 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1025728C18B for ; Fri, 10 Oct 2008 03:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 h+RTVjIyyhXP for ; Fri, 10 Oct 2008 03:12:21 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 416DB28C110 for ; Fri, 10 Oct 2008 03:12:21 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13322670; Fri, 10 Oct 2008 06:12:47 -0400 Message-Id: <44965FC0-69E9-4DED-8925-45DB6B7429F7@multicasttech.com> From: Marshall Eubanks To: Philip Levis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 06:12:46 -0400 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: Richard Barnes , p2pi@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 10, 2008, at 12:45 AM, Philip Levis wrote: > > On Oct 9, 2008, at 6:36 PM, Richard Barnes wrote: > >> On the contrary, I perceived pretty strong agreement at the BoF >> that the ALTO problem, as expressed in the documents and >> presentations, as an important one to solve. There was some >> disagreement about solutions, but there seemed to be agreement >> about the general idea that it would be useful to create an ALTO >> service that could help peers optimize their peer selection. >> >> The question of "service" versus "server" in the text is a complete >> non-issue, purely a matter of wording. In all of the "ALTO >> service" scenarios Vidya describes, there is ultimately a single >> host that provides ALTO information, which you might as well call >> an "ALTO server". >> >> Since it addresses an important problem, and a problem that many >> people agree is important, I support moving forward with this work. > > I agree. This is such a pressing problem that blocking on > terminology disputes which can be easily reconciled seems ill- > advised. There was an excellent technical discussion on the list > after the last IETF, and I think we reached at least rough consensus > on the important points. I support moving forward. > I agree with this interpretation and also support moving this forward into a WG. Regards Marshall > Phil > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 05:01:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01FC28C1B5; Fri, 10 Oct 2008 05:01:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C9E28C1AB; Fri, 10 Oct 2008 05:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 DunScT+xWLQD; Fri, 10 Oct 2008 05:00:58 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id E4F6B3A6ADF; Fri, 10 Oct 2008 05:00:32 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13323589; Fri, 10 Oct 2008 08:00:57 -0400 Message-Id: From: Marshall Eubanks To: iesg@ietf.org In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 08:00:56 -0400 References: <20081006203532.B1D673A68AF@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, IETF Discussion Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I support this moving forward. My reading of the room in Dublin was that there was serious support for this and certainly a critical mass to move forward. Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO "servers" and would keep the charter focused on describing the ALTO "service." I do not see consensus at this moment as to a central service solution versus a distributed solution. Regards Marshall On Oct 6, 2008, at 4:35 PM, IESG Secretary wrote: > A new IETF working group has been proposed in the Applications > Area. The > IESG has not made any determination as yet. The following draft > charter > was submitted, and is provided for informational purposes only. > Please > send your comments to the IESG mailing list (iesg@ietf.org) by Monday, > October 13, 2008. > > Application-Layer Traffic Optimization (alto) > ============================================= > Last Modified: 2008-09-29 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Applications Area Director(s): > > Lisa Dusseault (lisa at osafoundation.org) > Chris Newman (Chris.Newman at sun.com) > > Applications Area Advisor: > > Lisa Dusseault (lisa at osafoundation.org) > > Mailing List: > > General Discussion: p2pi at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi > Archive: http://www.ietf.org/pipermail/p2pi/ > > Description of Working Group: > > A significant part of the Internet traffic today is generated by > peer-to-peer (P2P) applications used for file sharing, real-time > communications, and live media streaming. P2P applications exchange > large amounts of data, often uploading as much as downloading. In > contrast to client/server architectures, P2P applications often have > a selection of peers and must choose. s/choose/choose the best peer or peers to exchange data with/ > > > One of the advantages of P2P systems comes from redundancy in resource > availability. This requires choosing among download locations, yet > applications have at best incomplete information about the topology of > the network. Applications can sometimes make empirical measurements > of link performance, but even when this is an option it takes time. > The application cannot always start out with an optimal arrangement of > peers, thus causing at least temporary reduced performance and > excessive cross-domain traffic. Providing more information for use in > peer selection can improve P2P performance and lower ISP costs. > > The Working Group will design and specify an Application-Layer Traffic > Optimization (ALTO) service that will provide applications with > information to perform better-than-random initial peer selection. > ALTO services may take different approaches at balancing factors > including maximum bandwidth, minimum cross-domain traffic, lowest cost > to the user, etc. The WG will consider the needs of BitTorrent, > tracker-less P2P, and other applications, such as content delivery > networks (CDN) and mirror selection. > > The WG will focus on the following items: > > - A "problem statement" document providing a description of the > problem and a common terminology. > > - A requirements document. This document will list requirements for > the ALTO service, identifying, for example, what kind of information > P2P applications will need for optimizing their choices. > > - A request/response protocol for querying the ALTO service to obtain > information useful for peer selection, and a format for requests and > responses. The WG does not require intermediaries between the ALTO This is strange wording, as WG themselves are not protocols. More fundamentally, is this a requirement ? If so, it seems premature before a requirements draft is adopted. Saying "The ALTO server" here also seems limiting - is there a solution draft describing a server ? Others have already commented on central servers versus a distributed system, and to me the charter is not the place to make such decisions. I would remove this sentence entirely. > > server and the peer querying it. If the requirements analysis > identifies > the need to allow clients to delegate third-parties to query the ALTO > service on their behalf, the WG will ensure that the protocol > provides a > mechanism to assert the consent of the delegating client. > > - A document defining core request and response formats and > semantics to > communicate network preferences to applications. Since ALTO > services may > be run by entities with different level of knowledge about the > underlying > network, such preferences may have different representations. > Initially > the WG will consider: IP ranges to prefer and to avoid, ranked lists > of > the peers requested by the client, information about topological > proximity > and approximate geographic locations. Other usages will be > considered as > extensions to the charter once the work for the initial services has > been > completed. > > - In order to query the ALTO server, clients must first know one or > more s/server/service/ s/know/find/ > > ALTO servers that might provide useful information. The WG will > look at > service discovery mechanisms that are in use, or defined elsewhere > (e.g. > based on DNS SRV records or DHCP options). If such discovery > mechanisms > can be reused, the WG will produce a document to specify how they > may be > adopted for locating such servers. However, a new, general-purpose > service discovery mechanism is not in scope. > > When the WG considers standardizing information that the ALTO server s/server/service/ > > could provide, the following criteria are important to ensure real > feasibility. > > - Can the ALTO service technically provide that information? I think that what is meant here is "Can the ALTO service realistically discover that information?" > > - Is the ALTO service willing to obtain and divulge that information? Do computers have free will ? More seriously, it seems very odd to assume that a P2P service will not do something that the owners of the peers want it to do. In my opinion that drives P2P adoption much more than the efficiencies of bandwidth sharing. > > - Is it information that a client will find useful? > - Can a client get that information without excessive privacy concerns > (e.g. by sending large lists of peers)? > - Is it information that a client cannot find easily some other way? > > > After these criteria are met, the generality of the data will be What is meant by "the generality of the data" ? > > considered for prioritizing standardization work, for example the > number of operators and clients that are likely to be able to provide > or use that particular data. In any case, this WG will not propose > standards on how congestion is signaled, remediated, or avoided, and Does this mean that congestion is not an issue to consider ? If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? > > will not deal with information representing instantaneous network > state. What is meant by "information representing instantaneous network state" ? Isn't this a protocol to share information about the state of the network ? Or is this an attempt to separate network topology from network performance ? But should network performance also be an issue ? > > Such issues belong to other IETF areas and will be treated > accordingly by > the specific area. > > This WG will focus solely on the communication protocol between Not according to the previous paragraphs. Service discovery is not part of this communication protocol, Load balancing is not part of this, etc. I would suggest changing "solely" to "primarily" > > applications and ALTO servers. Note that ALTO services may be useful > in client-server environments as well as P2P environments, although > P2P environments are the first focus. If, in the future, the IETF > considers changes to other protocols for actually implementing ALTO > servers (e.g. application-layer protocols for Internet coordinate > systems, What is an Internet coordinate system ? > > routing protocol extensions for ISP-based solutions), such work will > be done in strict coordination with the appropriate WGs. > > Issues related to the content exchanged in P2P systems are also s/also// > > excluded from the WG's scope, as is the issue dealing with enforcing s/is the issue/are issues/ > > the legality of the content. s/the legality of the content/copyrights/ > > > Goals and Milestones (very tentative dates): > > Apr 2009: Working Group Last Call for problem statement > Jun 2009: Submit problem statement to IESG as Informational > Aug 2009: Working Group Last Call for requirements document > Oct 2009: Submit requirements document to IESG as Informational > Jan 2010: Working Group Last Call for request/response protocol > Jan 2010: Working Group Last Call for usage document for > communicating network preferences > Mar 2010: Submit request/response protocol to IESG as Proposed > Standard > Mar 2010: Submit usage document to IESG as Proposed Standard > May 2010: Working Group Last Call of discovery mechanism > Jul 2010: Submit discovery mechanism to IESG as Proposed Standard > Aug 2010: Dissolve or re-charter > > Initial Drafts for Consideration > - draft-marocco-alto-problem-statement-02 -- Application-Layer Traffic > Optimization (ALTO) Problem Statement > - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization > (ALTO) Requirements > > Regards Marshall > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 05:15:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCC828C0FE; Fri, 10 Oct 2008 05:15:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2059D28C0FE; Fri, 10 Oct 2008 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y-Omg1ZbbMPU; Fri, 10 Oct 2008 05:15:25 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id D32733A69C5; Fri, 10 Oct 2008 05:15:24 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:16:07 +0200 Received: from ptpxch005rm001.idc.cww.telecomitalia.it ([156.54.205.167]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:16:06 +0200 Received: from [10.229.8.44] ([10.229.8.44]) by ptpxch005rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:16:05 +0200 Message-ID: <48EF477E.4080708@telecomitalia.it> Date: Fri, 10 Oct 2008 14:15:58 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Lakshminath Dondeti References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> In-Reply-To: <48EEE549.1080208@qualcomm.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 10 Oct 2008 12:16:05.0801 (UTC) FILETIME=[F83C6990:01C92AD1] Cc: Richard Barnes , "p2pi@ietf.org" , "'iesg@ietf.org'" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1814329419==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1814329419== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010008050504080605000004" This is a cryptographically signed message in MIME format. --------------ms010008050504080605000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lakshminath Dondeti wrote: > The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say > this: > > +++++++++++++++ > Many people agreed that this is important work for the IETF, also some > (less) people hummed against. Hum was inconclusive - some of the "no" > hums were (in Jon's words) vehement. > +++++++++++++++ > > Given that there was no consensus, it would have been nice if the > sponsoring AD(s) or the IESG explained what's going on, but then > transparency, it appears, is not really a goal in this case. If the > idea was to just go forward anyway, we really wasted 3, may be 6 months. > The half measures are a waste of everyone's time. Lakshminath, the objections raised during the BoF in Dublin were on very specific issues, namely the "general service discovery problem" supposedly addressed by the charter, a too broad scope in terms of information exchanged between ALTO clients and ALTO servers, and the connection between traffic localization and optimization someone seemed to see implied in the problem statement. During the weeks following the meeting, people who had expressed concerns at the mic and on the list constructively contributed to the discussion and the group converged on a charter the current version is a slight variant of. For this reason, and for the amount of interest shown in Dublin -- we called inconclusive the hum on the charter, but interest in the problem was made pretty clear by what we heard at the mic, by the number of contributors, and by the number of people in the room -- we managed to convince our sponsoring AD (and transitively the IESG) to send it out for IETF-wide review. If the community identifies new serious issues or considers the old ones not completely addressed, probably a new BoF will be the best way to sort them out. Of course I'm only speaking for myself, not certainly on behalf of Lisa nor the IESG. -- Ciao, Enrico --------------ms010008050504080605000004 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTAxMjE1NThaMCMG CSqGSIb3DQEJBDEWBBQgp+xB0HTyRddf1sT02K9Jx7m+MzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAGM9Vhbhd59V 1sJ4dJi590YDF+UkTJ6ak7hIwcTwicrMEZI6iXW5/0vbi6V766Xs0dfJ0yoArtsgl49iTsI0 elccUBnSe7tB2GQoz5jVW+HNxtw8/s3o7yhZqdnsO0X3lh+vNX1pHSaby6MNdtykTu4DXmfp Iz6qeZpBhZZiwGhPI66v1V+e+TWaixfWEEc1MYk5Hm1LMViboch7bK1IMyMH86qd8OGDM6RE dNVcSKYbUzWy6Wh+Uf+VM0qIJ1nsGN7sjA3/rNYoUsQ6A91DfKlGaYoO8wLgnrGIxzUe/pWp 2hyfCWbILy/aYFA5jZBUDfr8UKmeS32U5sO+QJccDDQAAAAAAAA= --------------ms010008050504080605000004-- --===============1814329419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1814329419==-- From p2pi-bounces@ietf.org Fri Oct 10 07:20:44 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4153A69FE; Fri, 10 Oct 2008 07:20:44 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDD13A6A5C; Fri, 10 Oct 2008 07:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6K1-FA6C2P1o; Fri, 10 Oct 2008 07:20:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 47C0E3A69C5; Fri, 10 Oct 2008 07:20:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="89347375" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2008 14:21:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9AELFFK010101; Fri, 10 Oct 2008 07:21:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9AELEWc002179; Fri, 10 Oct 2008 14:21:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 07:21:14 -0700 Received: from [10.32.241.68] ([10.32.241.68]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 07:21:13 -0700 Message-Id: <33C354C5-0C2F-42F7-8457-D7C7C36B566B@cisco.com> From: Bruce Davie To: Enrico Marocco In-Reply-To: <48EF477E.4080708@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 10:21:12 -0400 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 10 Oct 2008 14:21:13.0822 (UTC) FILETIME=[735D7FE0:01C92AE3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2777; t=1223648475; x=1224512475; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[p2pi]=20WG=20Review=3A=20Application-L ayer=20Traffic=20Optimization=20(alto) |Sender:=20; bh=fcUJAyReqHg7vVJo+dur/rdzzHs3+dOLWD3Qnc+J3AU=; b=bugEiXLzfR0ShxIRsEpNh5AGvCR7c0ay57iK2tuc08IkXZlG0HmGvFCNMz rBvSnHfvzaB/Wda5axLsXVkqXqe2cFxULBZG5LiQIdmgHZEcjwJ1q2jbXsdw NAy2adyCLe; Authentication-Results: sj-dkim-3; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: p2pi@ietf.org, Richard Barnes , iesg@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I think Enrico's summary is a good one as I saw things. I am pleased to see how much work has gone into refining the charter since Dublin, as there was clearly an interest in getting this problem tackled by the IETF if the problem definition could be more clearly defined. The IETF has traditionally prided itself in making progress quickly and not only in face to face meetings - it is good to see that is the goal here as well. I support the formation of the WG. Bruce Davie On Oct 10, 2008, at 8:15 AM, Enrico Marocco wrote: > Lakshminath Dondeti wrote: >> The minutes (http://www.ietf.org/proceedings/08jul/minutes/ >> alto.txt) say >> this: >> >> +++++++++++++++ >> Many people agreed that this is important work for the IETF, also >> some >> (less) people hummed against. Hum was inconclusive - some of the >> "no" >> hums were (in Jon's words) vehement. >> +++++++++++++++ >> >> Given that there was no consensus, it would have been nice if the >> sponsoring AD(s) or the IESG explained what's going on, but then >> transparency, it appears, is not really a goal in this case. If the >> idea was to just go forward anyway, we really wasted 3, may be 6 >> months. >> The half measures are a waste of everyone's time. > > Lakshminath, the objections raised during the BoF in Dublin were on > very > specific issues, namely the "general service discovery problem" > supposedly addressed by the charter, a too broad scope in terms of > information exchanged between ALTO clients and ALTO servers, and the > connection between traffic localization and optimization someone > seemed > to see implied in the problem statement. During the weeks following > the > meeting, people who had expressed concerns at the mic and on the list > constructively contributed to the discussion and the group converged > on > a charter the current version is a slight variant of. For this reason, > and for the amount of interest shown in Dublin -- we called > inconclusive the hum on the charter, but interest in the problem was > made pretty clear by what we heard at the mic, by the number of > contributors, and by the number of people in the room -- we managed to > convince our sponsoring AD (and transitively the IESG) to send it out > for IETF-wide review. If the community identifies new serious issues > or > considers the old ones not completely addressed, probably a new BoF > will > be the best way to sort them out. > > Of course I'm only speaking for myself, not certainly on behalf of > Lisa > nor the IESG. > > -- > Ciao, > Enrico > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 07:28:51 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FE33A69AB; Fri, 10 Oct 2008 07:28:51 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED553A69AB for ; Fri, 10 Oct 2008 07:28:49 -0700 (PDT) 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=[AWL=0.000, 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 YwO1bc-93D+b for ; Fri, 10 Oct 2008 07:28:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 7CEC93A6861 for ; Fri, 10 Oct 2008 07:28:47 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m9AETV6n006553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 09:29:32 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9AETUZn000169; Fri, 10 Oct 2008 09:29:31 -0500 (CDT) Message-ID: <48EF66C9.40008@alcatel-lucent.com> Date: Fri, 10 Oct 2008 09:29:29 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lakshminath Dondeti References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> In-Reply-To: <48EEE549.1080208@qualcomm.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323336145==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1323336145== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070801070600030107010908" This is a cryptographically signed message in MIME format. --------------ms070801070600030107010908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lakshminath Dondeti wrote: > Given that there was no consensus, it would have been nice if the > sponsoring AD(s) or the IESG explained what's going on, but then > transparency, it appears, is not really a goal in this case. Lakshminath: I respectfully submit that transparency has not been obviated here. The BoF in Dublin indicated that some people hummed against it, but there was a vigorous discussion on the mailing list immediately on why people hummed against ALTO and what should be done to rectify the deficiencies moving forward. By and large, the hums against were because (1) it was thought that the initial charter was too broad; (2) there was an element of "research", not "engineering" inherent in the charter; (3) the charter attempted to find an "optimal" peer, whereas optimality is a function of different things at a specific point in time; (4) we unfortunately used the term "oracle" in the BoF charter, which many people took to assume that we were trying to standardize a solution already. Since the Dublin BoF, Enrico and I, guided by the list participants have attempted to resolve all of the above. To wit, Aug 1, 2008: End of Dublin IETF. Aug 7, 2008: A new version of charter proposed on mailing list that took in account discussions at the Dublin BoF. (please see http://www.ietf.org/mail-archive/web/p2pi/current/msg00575.html) Those that hummed against the old charter were happy with the new one. Aug 7, 2008: A thread started on the mailing list to agree on what kind of information will be provided in ALTO (please see http://www.ietf.org/mail-archive/web/p2pi/current/msg00576.html) Aug 21, 2008: Opened up a channel with IRTF chair to move some work that was deemed as "research" to the p2prg. Sept. 12, 2008: A revised version of the charter resulting from Aug 7, 2008 was posted on the list (please see http://www.ietf.org/mail-archive/web/p2pi/current/msg00669.html) Sept. 18, 2008: Email sent out to the list that the revised charter resulting from Sept. 12, 2008 will be sent to IESG (please see: http://www.ietf.org/mail-archive/web/p2pi/current/msg00696.html). Sept. 30, 2008: Email to list that the charter has been sent out for IETF-wide last call (please see: http://www.ietf.org/mail-archive/web/p2pi/current/msg00698.html) Oct. 6, 2008: Charter appears on IETF announcement list. > I for one think that there needs to be much more clarity on the goals > and the terminology before just moving forward and producing useless RFCs. I agree, and I sincerely believe that we have used the last few months after Dublin ensuring that what you write above does not happen. Regards, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs --------------ms070801070600030107010908 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJaTCC Aw8wggJ4oAMCAQICEBWN7P+5Br92SXsp1uXfYbgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMTIxNTQzN1oX DTA5MDIxMDIxNTQzN1owZDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEaMBgG CSqGSIb3DQEJARYLdmtnQGFjbS5vcmcxJTAjBgkqhkiG9w0BCQEWFnZrZ0BhbGNhdGVsLWx1 Y2VudC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDyhyhaaQ5pI2XcT/68 WLaGBj/wLsh2mW0sE2s+wbLQ/tlqgcLdfZ5MammpJReTclAI9IrDR39P8AhKboTVQkOLtqfA YfDMkK8/iWxw8TkuxEldMlbyxnpuLm7kKtOozx2TYgfAxFNP9GaGVvVwKaqA52OCgipkM12T EwRmYXhWRvbKUTjCg5RhpFQV4zYaeu8jdU5g+K7PBlTafKSsTQutVXgmR+vEvuc+B53Yl5zO m6xOJNJv+derC9t97++Iu+l769vEXVLRGYvB9GplWbbacE58pTC7WSIviYz/+e+Ytb07aIsZ CfDN3cA7g/QEyzA/HyhaqFof/1ZXO6Kdut03AgMBAAGjQDA+MC4GA1UdEQQnMCWBC3ZrZ0Bh Y20ub3JngRZ2a2dAYWxjYXRlbC1sdWNlbnQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADgYEAH5bUrTdXIxd5Pvy6buMUu8A+wnbCZBioMOoQFK3uKhvvQshRv9b+gwRNhcBx h1JnQEyDPKgDDpE3vL5qkG8z3q2XOAmp6F+4Ma1hBrigFUSaWhmqxCQlxM46U4aZYWJ44ggH 4Lg6O8xR/u8Dd5nhDPO0f8EzZtFsinIIiFYIF5swggMPMIICeKADAgECAhAVjez/uQa/dkl7 Kdbl32G4MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTAeFw0wODAyMTEyMTU0MzdaFw0wOTAyMTAyMTU0MzdaMGQxHzAdBgNV BAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxGjAYBgkqhkiG9w0BCQEWC3ZrZ0BhY20ub3Jn MSUwIwYJKoZIhvcNAQkBFhZ2a2dAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA8ocoWmkOaSNl3E/+vFi2hgY/8C7IdpltLBNrPsGy0P7ZaoHC 3X2eTGppqSUXk3JQCPSKw0d/T/AISm6E1UJDi7anwGHwzJCvP4lscPE5LsRJXTJW8sZ6bi5u 5CrTqM8dk2IHwMRTT/Rmhlb1cCmqgOdjgoIqZDNdkxMEZmF4Vkb2ylE4woOUYaRUFeM2Gnrv I3VOYPiuzwZU2nykrE0LrVV4JkfrxL7nPged2JeczpusTiTSb/nXqwvbfe/viLvpe+vbxF1S 0RmLwfRqZVm22nBOfKUwu1kiL4mM//nvmLW9O2iLGQnwzd3AO4P0BMswPx8oWqhaH/9WVzui nbrdNwIDAQABo0AwPjAuBgNVHREEJzAlgQt2a2dAYWNtLm9yZ4EWdmtnQGFsY2F0ZWwtbHVj ZW50LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAB+W1K03VyMXeT78um7j FLvAPsJ2wmQYqDDqEBSt7iob70LIUb/W/oMETYXAcYdSZ0BMgzyoAw6RN7y+apBvM96tlzgJ qehfuDGtYQa4oBVEmloZqsQkJcTOOlOGmWFieOIIB+C4OjvMUf7vA3eZ4QzztH/BM2bRbIpy CIhWCBebMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2 JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wID AQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG 9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAVjez/uQa/dkl7Kdbl32G4 MAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA4MTAxMDE0MjkyOVowIwYJKoZIhvcNAQkEMRYEFC6LCPyB54Pho3hvlh0Mz4XT3nnr MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQFY3s/7kGv3ZJeynW 5d9huDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQFY3s/7kGv3ZJeynW5d9huDANBgkqhkiG9w0BAQEFAASCAQDt RAz0p/ZIjZCiPn1g5UTydDN1XW8qfGCwU+Lnrb77bxCAUCWAuqownVD7sFf/4UL4BVaLjJse nAAibLm0gPhvtOAd5g9X9F3OSds2kloDgAsCrsPefEIi675PSSGTrdFSBSUC/eU/WQXpx2pN 14ETIfD4QE0PnJHd5w3RxHfLYtNS7UatGK1f9cQdaKplrw6USe5BZ1L3dFOlPwtSc6OHQz5l tWLQZaD6uGtc/5KmQSf6ldiQ3CnEfihvz/XAU1+JoECOK3pThDiGFF0HxsUhJdxx+gSxH7uD lu7ABcFSPbZSbhHiqLXNjYu2Xi1J0eCQBe53AYmHudpsMrQ0rGmiAAAAAAAA --------------ms070801070600030107010908-- --===============1323336145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1323336145==-- From p2pi-bounces@ietf.org Fri Oct 10 08:09:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA62C28C163; Fri, 10 Oct 2008 08:09:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C4028C118; Fri, 10 Oct 2008 08:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.963 X-Spam-Level: X-Spam-Status: No, score=-104.963 tagged_above=-999 required=5 tests=[AWL=1.636, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cAAfkHae1I6c; Fri, 10 Oct 2008 08:09:51 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B183928C163; Fri, 10 Oct 2008 08:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223651438; x=1255187438; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48EF706C.9050508@qualcomm.com>|Date:=20Fr i,=2010=20Oct=202008=2008:10:36=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Enrico=20Marocco=20|CC:=20Richard=20Barnes=20,=20"p2pi@ ietf.org"=20,=0D=0A=20=20=20=20=20=20=20 =20"'iesg@ietf.org'"=20,=20ietf@ietf.org |Subject:=20Re:=20[p2pi]=20WG=20Review:=20Application-Lay er=20Traffic=20Optimization=20(alto)|References:=20<20081 006203532.B1D673A68AF@core3.amsl.com>=09=09< 48EEB19C.4000303@bbn.com>=20<48EEE549.1080208@qualcomm.co m>=20<48EF477E.4080708@telecomitalia.it>|In-Reply-To:=20< 48EF477E.4080708@telecomitalia.it>|Content-Type:=20text/p lain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5402"=3B=20a=3D"10589960"; bh=nHQ4ocCjG2vQzXOM2k/yxH6OIzd48vQSBYPnbCiagis=; b=iscgiaQv/8MwjShKjun9Kh9rA8TMk+NEION83OHTrP3vKLJ7K/ANj3kW EUl9pnDSuhLaT2pLXnpfu6xH66/r7DCsYSVcA72K7PtyGvjCxb4bqCuuN LavPNAFlV2A8blNf5AV8Ci2AEMG2mnDlDrMVHkEKFYdtjfL/C05oDJeNN A=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10589960" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 08:10:38 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AFAbkp029675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 08:10:38 -0700 Received: from [10.50.68.73] (qconnect-10-50-68-73.qualcomm.com [10.50.68.73]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AFAbRs011403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Oct 2008 08:10:37 -0700 Message-ID: <48EF706C.9050508@qualcomm.com> Date: Fri, 10 Oct 2008 08:10:36 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Enrico Marocco References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> In-Reply-To: <48EF477E.4080708@telecomitalia.it> Cc: Richard Barnes , "p2pi@ietf.org" , "'iesg@ietf.org'" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Enrico, Vijay, Thank you for the summary of what transpired after the Dublin meeting. I appreciate you taking the time. My reading at the BoF was that there were some concerns about this work being done in haste without clearly understanding what it is that we want to do and what it is that we need to do to address this particular problem space (there were even suggestions to move some of the work to the IRTF). My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. We have been in situations where working groups have been created in haste to address important and urgent problems, but then people disagree so much in working groups that some such working groups never made any real progress or had to be shut down (folks, please don't try to guess which WG(s) and try to explain the individual situations; thanks). Surely, we don't want that to happen here. Some of the disagreements here in this thread now, and the intent of some of the folks to whitewash the issues raised do seem troublesome. It would be great if we could rather focus on trying to understand all aspects of the problem, have the charter reflect the correct level of scope (too wide or too narrow are problematic as we know), and move forward. thanks, Lakshminath On 10/10/2008 5:15 AM, Enrico Marocco wrote: > Lakshminath Dondeti wrote: >> The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say >> this: >> >> +++++++++++++++ >> Many people agreed that this is important work for the IETF, also some >> (less) people hummed against. Hum was inconclusive - some of the "no" >> hums were (in Jon's words) vehement. >> +++++++++++++++ >> >> Given that there was no consensus, it would have been nice if the >> sponsoring AD(s) or the IESG explained what's going on, but then >> transparency, it appears, is not really a goal in this case. If the >> idea was to just go forward anyway, we really wasted 3, may be 6 months. >> The half measures are a waste of everyone's time. > > Lakshminath, the objections raised during the BoF in Dublin were on very > specific issues, namely the "general service discovery problem" > supposedly addressed by the charter, a too broad scope in terms of > information exchanged between ALTO clients and ALTO servers, and the > connection between traffic localization and optimization someone seemed > to see implied in the problem statement. During the weeks following the > meeting, people who had expressed concerns at the mic and on the list > constructively contributed to the discussion and the group converged on > a charter the current version is a slight variant of. For this reason, > and for the amount of interest shown in Dublin -- we called > inconclusive the hum on the charter, but interest in the problem was > made pretty clear by what we heard at the mic, by the number of > contributors, and by the number of people in the room -- we managed to > convince our sponsoring AD (and transitively the IESG) to send it out > for IETF-wide review. If the community identifies new serious issues or > considers the old ones not completely addressed, probably a new BoF will > be the best way to sort them out. > > Of course I'm only speaking for myself, not certainly on behalf of Lisa > nor the IESG. > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 11:36:15 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAB13A686D; Fri, 10 Oct 2008 11:36:15 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DA73A67FB; Fri, 10 Oct 2008 11:36:13 -0700 (PDT) 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 OZAxWOPA6aVZ; Fri, 10 Oct 2008 11:36:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 754FE3A66B4; Fri, 10 Oct 2008 11:36:11 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m9AIalPw015842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 13:36:47 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9AIakq3027754; Fri, 10 Oct 2008 13:36:46 -0500 (CDT) Message-ID: <48EFA0BE.1040809@alcatel-lucent.com> Date: Fri, 10 Oct 2008 13:36:46 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lakshminath Dondeti References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> In-Reply-To: <48EF706C.9050508@qualcomm.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" , IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lakshminath Dondeti wrote: > Hi Enrico, Vijay, > > Thank you for the summary of what transpired after the Dublin > meeting. I appreciate you taking the time. Lakshminath: No problem. Thank you for your time and effort on this. > My reading at the BoF was that there were some concerns about this > work being done in haste without clearly understanding what it is > that we want to do and what it is that we need to do to address this > particular problem space (there were even suggestions to move some of > the work to the IRTF). And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) > My perception and my understanding of some of the dissenting opinions > was that some of those need to be worked out before creating a > working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. > Some of the disagreements here in this thread now, and the intent of > some of the folks to whitewash the issues raised do seem > troublesome. I sincerely do not believe that we are trying to whitewash any issues here. It would seem an awful waste of time of the ADs, IRTF chair and list participants to engage in detailed discussions since the Dublin BoF if that were indeed the case. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 11:40:14 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3063A6889; Fri, 10 Oct 2008 11:40:14 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339A13A67FB; Fri, 10 Oct 2008 11:40:14 -0700 (PDT) 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 g7SIQnZ7esjd; Fri, 10 Oct 2008 11:40:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A07473A67F5; Fri, 10 Oct 2008 11:40:12 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m9AIeu6i020383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 13:40:56 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9AIetVN001971; Fri, 10 Oct 2008 13:40:55 -0500 (CDT) Message-ID: <48EFA1B7.7010508@alcatel-lucent.com> Date: Fri, 10 Oct 2008 13:40:55 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: vidyan@qualcomm.com References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" , IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Narayanan, Vidya wrote: > I am surprised to see that ALTO is being proposed for a WG after the > last BoF concluded with no consensus whatsoever. I think a second > BoF is more appropriate than a WG on the topic at this time. That > said, I do see the need for this work, although I have some comments > on the current direction. Vidya: Thank you for the feedback. After analyzing your points, it seems that the charter as written is already conducive to the important points raised in your review of it (i.e., we may already be in agreement.) More inline. > Overall, I think we should work with the notion of an ALTO "service" > rather than specifically an ALTO "server". Great. I believe that is exactly what the charter does; the charter talks in terms of an "ALTO service" at many places (pedantically speaking, the term "ALTO service" occurs eight times and the term "ALTO server" occurs six.) The ALTO "server" mentioned in the charter refers to the *host* the client finally queries (calling it a "peer" is ambiguous; if you have a specific term to use here instead of "server", please do let us know.) > The ALTO service may be provided by a server, a cluster of > distributed servers or as a service in an overlay. Although some of > the charter wording talks about a "service" rather than a "server", > there is enough mention of a "server" entity to imply a strict > client-server protocol. The charter is not meant to imply a centralized architecture, nor to rule out peer-to-peer implementations of it. The charter simply mentions a "request/reply" protocol is needed. Whether or not there is a cluster of ALTO servers or one needs to be decided by the requirement analysis and subsequent discussions in the WG. > As part of that, I think there are a couple of key things that need > to be addressed here: > > - A protocol that allows peers (or ALTO clients) to publish > information about themselves as part of the ALTO service. An example > of such information may be the uplink/downlink bandwidth of the > peer. We have had discussions on the mailing list about this already. Some people felt that providing uplink bandwidth would not be a good idea for various reasons running from privacy concerns to peers skewing traffic in favor of a high uplink bandwidth. Others felt that even if a peers uplink bandwidth was not provided, it could calculated nonetheless by other peers. That is, there are degrees of disagreement here and consequently, including a contentious point in the charter would be counter- productive. > - The ability to register information types with IANA and extend > these. Having a IANA registry for the information type carried in the protocol is certainly a possibility the charter does not rule out, no? > The request/response protocol should be a generic enough container > for any information that peers can provide and look for, plus what > may be available from service providers, etc. There may be some > guidelines on how such information types can be registered and we may > start with default ones. Exactly; this is what the charter is saying in the paragraph: - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as extensions to the charter once the work for the initial services has been completed. We *are* starting with the default information; as other information is required, we can extend the charter, right? Extending the charter is cheap -- it is a bureaucratic process that will auto- matically happen if there are enough interested parties willing to do the work and the work is considered to be important enough. I believe that the higher bar is ensuring that the initial charter contains the right amount of work so that the WG can finish it in an appropriate amount of time. >> The Working Group will design and specify an Application-Layer >> Traffic Optimization (ALTO) service that will provide applications >> with information to perform better-than-random initial peer >> selection. ALTO services may take different approaches at balancing >> factors including maximum bandwidth, minimum cross-domain traffic, >> lowest cost to the user, etc. The WG will consider the needs of >> BitTorrent, tracker-less P2P, and other applications, such as >> content delivery networks (CDN) and mirror selection. > > What does the above sentence mean? If we are putting such a list > together, we must also take into account needs from structured P2P > overlays such as those being specified in P2PSIP. In P2PSIP, the amount of information being stored in the overlay is small (a R-URI, on the order of tens of bytes.) ALTO will not much help there. OTOH, ALTO will help tremendously if in a P2PSIP network, there is a need to find a peer that hosts the recording of a 2-hour conference call. Nothing in the ALTO charter prevents this from happening as it is specified today. > Is this meant to allow for entities such as proxies to be in the > path? There's been quite a lot of discussion on this topic on the list. Current consensus is to keep the architecture as simple as possible and exclude at least initially support for non-transparent intermediaries; if at some point we have evidence of the need for it, the group will go through rechartering. > Earlier, it is mentioned that the requirements document will > determine the types of information that are useful for P2P > applications. Given that, it seems premature to conclude that the WG > should consider the above mentioned parameters. Also, as I > mentioned earlier, I think it is essential to keep the protocol and > message formats extensible and allow for exchange of any registered > information type. The limit on what data to consider initially was suggested to avoid the group to wander for years discussing any kind of possible information; however, extensibility will be the key principle in designing a protocol (for good design practices rather than because it is written in the charter). > Another question I have is about the assumptions around expected peer > addressing models. Some of the above seems to hint at IP addresses > - is this an assumption already? No, the text says "ranked lists of the peers requested by the client" exactly because we still don't know how they could be identified. >> - In order to query the ALTO server, clients must first know one or >> more ALTO servers that might provide useful information. The WG >> will look at service discovery mechanisms that are in use, or >> defined elsewhere (e.g. based on DNS SRV records or DHCP options). >> If such discovery mechanisms can be reused, the WG will produce a >> document to specify how they may be adopted for locating such >> servers. However, a new, general-purpose service discovery >> mechanism is not in scope. > > Alternately, the clients may look for ALTO services within an > overlay. This can be modeled as service discovery within the overlay > - I'm, however, not suggesting that we take on solutions for that. OK, good; we do not want to bite more than we can chew. If a suitable overlay service discovery mechanism exists, we will happily use it. >> When the WG considers standardizing information that the ALTO >> server could provide, the following criteria are important to >> ensure real feasibility. >> >> - Can the ALTO service technically provide that information? >> - Is the ALTO service willing to obtain and divulge that >> information? >> - Is it information that a client will find useful? > > I'm not sure how useful it is for us to answer this question. The > protocol we develop simply needs to be a container for any > information that has a registered type and fits a certain format. Sure, no disagreements here. However, the list of questions that appears in the charter was suggested as a set of minimum vetting points to ensure that the WG spent some thought process on making an adequate determination on the importance and use of an ALTO service. The list of questions does not inhibit the protocol we develop in any way. > If we can build an extensible protocol, we don't need to define all > possible kinds of information that get carried in it. Please see above. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 12:20:18 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DB73A697B; Fri, 10 Oct 2008 12:20:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4972C3A6888 for ; Fri, 10 Oct 2008 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Jjlbvbb2ibhW for ; Fri, 10 Oct 2008 12:20:15 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 64E5B3A6846 for ; Fri, 10 Oct 2008 12:20:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so627147rvf.49 for ; Fri, 10 Oct 2008 12:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=F+kWSYxEV4cUPloW+AF48M+3TWooXJKywhVo35vrgWU=; b=JhlmF6nsPuNc7jQQvQFxDYnvDhjf8XwdDcYlYGBrDaj3oIPdjZJjTTzZ72cyHJVa5c pOxRZtGuo4bA1JkoecmVNAz7R7JBHwiDbXwJjnfYhUc8bOq1NJYbxjge4xesSvljqsuv 1p6MiDfvPeTI1a4qtIMihpNBX2X1bfFSa3QqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=S181FJpHCqUQYRTqAQ2ob1D/hvreHKuLrFatjehQ3J0HPZnYnhKPNjr0WT9+9KYr79 h3O0q4SLfHOwcyPYhiKQ2bXM5cr8vItjNAW4j1AcmJZgAQ/djX3gFrVWlbZMuV7Yn7Ba rKD9MwFbpHYBk+TOykk11NthOmjFgb/fqEl1c= Received: by 10.141.29.14 with SMTP id g14mr1420944rvj.241.1223666462177; Fri, 10 Oct 2008 12:21:02 -0700 (PDT) Received: by 10.141.79.16 with HTTP; Fri, 10 Oct 2008 12:21:02 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 12:21:02 -0700 From: "Lisa Dusseault" To: "Lakshminath Dondeti" In-Reply-To: <48EFA0BE.1040809@alcatel-lucent.com> MIME-Version: 1.0 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> Cc: "p2pi@ietf.org" , IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1996140781==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1996140781== Content-Type: multipart/alternative; boundary="----=_Part_106317_9067399.1223666462145" ------=_Part_106317_9067399.1223666462145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani wrote: ... > > And since the BoF, much has changed to narrow the scope of the > charter down to more manageable pieces as well as establish a > channel with IRTF to move certain aspects of the work there > (as the timeline in my previous email indicated.) > >> Lakshminath Dondeti wrote: >> > > > My perception and my understanding of some of the dissenting opinions >> was that some of those need to be worked out before creating a working >> group. >> > > But I believe that we have done exactly that: the list has been > busy since Dublin on attempts to move the work forward in a manner > that is conducive to all participants. > > ------=_Part_106317_9067399.1223666462145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Lakshminath and Vidya,

Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF.  This IETF Last Call is also part of confirming whether there's now consensus.

It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts.  I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected.  It would be most excellent to see some individual proposals before a committee gets their hands on them :)

Lisa



On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani <vkg@alcatel-lucent.com> wrote:

 ...

And since the BoF, much has changed to narrow the scope of the
charter down to more manageable pieces as well as establish a
channel with IRTF to move certain aspects of the work there
(as the timeline in my previous email indicated.)

Lakshminath Dondeti wrote:
 

My perception and my understanding of some of the dissenting opinions
was that some of those need to be worked out before creating a working group.

But I believe that we have done exactly that: the list has been
busy since Dublin on attempts to move the work forward in a manner
that is conducive to all participants.



------=_Part_106317_9067399.1223666462145-- --===============1996140781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1996140781==-- From p2pi-bounces@ietf.org Fri Oct 10 12:38:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE2F3A68FB; Fri, 10 Oct 2008 12:38:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461823A68FB; Fri, 10 Oct 2008 12:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 lpqjYhUVhQ59; Fri, 10 Oct 2008 12:37:59 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id AE0983A68F4; Fri, 10 Oct 2008 12:37:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 4F624E10C70; Fri, 10 Oct 2008 15:38:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4QmI6juxEYs; Fri, 10 Oct 2008 15:38:33 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 00F6FE10D7A; Fri, 10 Oct 2008 15:38:33 -0400 (EDT) Date: Fri, 10 Oct 2008 15:38:32 -0400 (EDT) From: Laird Popkin To: Lisa Dusseault Message-ID: <327895541.358291223667512976.JavaMail.root@dkny.pando.com> In-Reply-To: <1991192280.358241223667338374.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org, IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0676325747==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0676325747== Content-Type: multipart/alternative; boundary="----=_Part_16001_1040093103.1223667512975" ------=_Part_16001_1040093103.1223667512975 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On a related note, I'd like to make sure that you guys know that, as we dis= cussed in Dublin, the P4P Working Group is in the process of documenting th= e P4P protocol as used in our field tests, which we would like to offer to = the ALTO group as input into the ALTO process. Our hope is to have this rea= dy for the next IETF meeting.=20 -=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks=20 =C2=A0=C2=A0mobile:=C2=A0646/465-0570=20 ----- Original Message -----=20 From: "Lisa Dusseault" =20 To: "Lakshminath Dondeti" =20 Cc: p2pi@ietf.org, "IESG IESG" , ietf@ietf.org=20 Sent: Friday, October 10, 2008 3:21:02 PM (GMT-0500) America/New_York=20 Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto= )=20 Lakshminath and Vidya,=20 Vijay, Enrico and Stefano have said what I was going to say (e.g. below) --= as sponsoring AD for this charter I've been following the WG discussion, w= orking with the rest of the IESG, and talking to people to confirm that the= re's better consensus on the list, even if there was confusion at the BOF.= =C2=A0 This IETF Last Call is also part of confirming whether there's now c= onsensus.=20 It's difficult to write a charter without actually designing the solution. = What would help with the charter, even now, is for people to write up propo= sals for the solution -- ideally in the form of Internet-Drafts.=C2=A0 I ha= ven't yet selected chairs for the WG, so as you can imagine editors and aut= hors aren't yet selected.=C2=A0 It would be most excellent to see some indi= vidual proposals before a committee gets their hands on them :)=20 Lisa=20 On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani < vkg@alcatel-lucent.com= > wrote:=20 =C2=A0...=20 And since the BoF, much has changed to narrow the scope of the=20 charter down to more manageable pieces as well as establish a=20 channel with IRTF to move certain aspects of the work there=20 (as the timeline in my previous email indicated.)=20 Lakshminath Dondeti wrote:=20 =C2=A0=20 My perception and my understanding of some of the dissenting opinions=20 was that some of those need to be worked out before creating a working grou= p.=20 But I believe that we have done exactly that: the list has been=20 busy since Dublin on attempts to move the work forward in a manner=20 that is conducive to all participants.=20 _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_16001_1040093103.1223667512975 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On a related note, I'd like to make sure that y= ou guys know that, as we discussed in Dublin, the P4P Working Group is in t= he process of documenting the P4P protocol as used in our field tests, whic= h we would like to offer to the ALTO group as input into the ALTO process. = Our hope is to have this ready for the next IETF meeting.

-=C2=A0Lai= rd=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks
=C2=A0=C2=A0mobile:= =C2=A0646/465-0570

----- Original Message -----
From: "Lisa Dusse= ault" <lisa.dusseault@gmail.com>
To: "Lakshminath Dondeti" <ldonde= ti@qualcomm.com>
Cc: p2pi@ietf.org, "IESG IESG" <iesg@ietf.org>, ietf= @ietf.org
Sent: Friday, October 10, 2008 3:21:02 PM (GMT-0500) America/N= ew_York
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimiz= ation (alto)

Lakshminath and Vidya,

Vijay, E= nrico and Stefano have said what I was going to say (e.g. below) -- as spon= soring AD for this charter I've been following the WG discussion, working w= ith the rest of the IESG, and talking to people to confirm that there's bet= ter consensus on the list, even if there was confusion at the BOF.=C2=A0 Th= is IETF Last Call is also part of confirming whether there's now consensus.=

It's difficult to write a charter without actually designing the soluti= on. What would help with the charter, even now, is for people to write up p= roposals for the solution -- ideally in the form of Internet-Drafts.=C2=A0 = I haven't yet selected chairs for the WG, so as you can imagine editors and= authors aren't yet selected.=C2=A0 It would be most excellent to see some = individual proposals before a committee gets their hands on them :)

Lisa



On Fri, Oct 10, 2008 at = 11:36 AM, Vijay K. Gurbani <vkg@alcatel-lucent.com> wrote:=

=C2=A0...

And since the BoF, much has changed to narrow the scope of the
charter down to more manageable pieces as well as establish a
channel with IRTF to move certain aspects of the work there
(as the timeline in my previous email indicated.)

Lakshminath Dondeti wrote:
=C2=A0

My perception and my understanding of some of the dissenting opinions
was that some of those need to be worked out before creating a working grou= p.

But I believe that we have done exactly that: the list has been
busy since Dublin on attempts to move the work forward in a manner
that is conducive to all participants.




_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_16001_1040093103.1223667512975-- --===============0676325747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0676325747==-- From p2pi-bounces@ietf.org Fri Oct 10 13:08:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB0F3A698B; Fri, 10 Oct 2008 13:08:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003993A67A1; Fri, 10 Oct 2008 13:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 5SO0O6Tgh2LD; Fri, 10 Oct 2008 13:08:27 -0700 (PDT) Received: from www.cdt.org (www.cdt.org [72.3.253.41]) by core3.amsl.com (Postfix) with ESMTP id 874143A691F; Fri, 10 Oct 2008 13:08:26 -0700 (PDT) Received: from [10.0.1.14] (66.safeclick.net [63.119.245.66]) (authenticated bits=0) by www.cdt.org (8.12.11.20060308/8.12.11) with ESMTP id m9AK8xba017562; Fri, 10 Oct 2008 16:09:04 -0400 Message-Id: From: Alissa Cooper To: ietf@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 16:08:59 -0400 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, iesg@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree with the sentiment that this work is too important to not move forward. While feelings at the BoF were mixed, the work done since the BoF has been substantial, particularly in the area of narrowing the charter's scope. The ALTO work as it has been put forth in the current charter has potential value not only for diverse applications (as the IPTV example below suggests), but also for a diversity of network operators facing difficult technical and policy trade-offs arising from ever-changing network usage. All sides will benefit from moving forward. Alissa Cooper Center for Democracy & Technology On Oct 10, 2008, at 12:29 AM, Daniel Park wrote: > I also agree to move it forward. One example: ALTO issue is quickly > coming up in the IPTV business. P2P for IPTV service already takes > place in some of standard bodies (e.g., DVB, EBU, etc...). So, it's > a good timing not to missing over the important business changes... > > -- > Daniel Park [at] Samsung Electronics > Standard Architect, blog.naver.com/natpt > > > > On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes > wrote: > On the contrary, I perceived pretty strong agreement at the BoF that > the ALTO problem, as expressed in the documents and presentations, > as an important one to solve. There was some disagreement about > solutions, but there seemed to be agreement about the general idea > that it would be useful to create an ALTO service that could help > peers optimize their peer selection. > > The question of "service" versus "server" in the text is a complete > non-issue, purely a matter of wording. In all of the "ALTO service" > scenarios Vidya describes, there is ultimately a single host that > provides ALTO information, which you might as well call an "ALTO > server". > > Since it addresses an important problem, and a problem that many > people agree is important, I support moving forward with this work. > > --Richard > > > > Narayanan, Vidya wrote: > I am surprised to see that ALTO is being proposed for a WG after the > last BoF concluded with no consensus whatsoever. I think a second > BoF is more appropriate than a WG on the topic at this time. That > said, I do see the need for this work, although I have some comments > on the current direction. > > Overall, I think we should work with the notion of an ALTO "service" > rather than specifically an ALTO "server". The ALTO service may be > provided by a server, a cluster of distributed servers or as a > service in an overlay. Although some of the charter wording talks > about a "service" rather than a "server", there is enough mention of > a "server" entity to imply a strict client-server protocol. > > As part of that, I think there are a couple of key things that need > to be addressed here: > > - A protocol that allows peers (or ALTO clients) to publish > information about themselves as part of the ALTO service. An > example of such information may be the uplink/downlink bandwidth of > the peer. > > - The ability to register information types with IANA and extend > these. The request/response protocol should be a generic enough > container for any information that peers can provide and look for, > plus what may be available from service providers, etc. There may > be some guidelines on how such information types can be registered > and we may start with default ones. > > Some further comments/questions inline. > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Monday, October 06, 2008 1:36 PM > To: IETF Announcement list > Cc: p2pi@ietf.org > Subject: WG Review: Application-Layer Traffic Optimization (alto) > > A new IETF working group has been proposed in the > Applications Area. The IESG has not made any determination > as yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by Monday, > October 13, 2008. > > Application-Layer Traffic Optimization (alto) > ============================================= > Last Modified: 2008-09-29 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Applications Area Director(s): > > Lisa Dusseault (lisa at osafoundation.org) Chris Newman > (Chris.Newman at sun.com) > > Applications Area Advisor: > > Lisa Dusseault (lisa at osafoundation.org) > > Mailing List: > > General Discussion: p2pi at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi > Archive: http://www.ietf.org/pipermail/p2pi/ > > Description of Working Group: > > A significant part of the Internet traffic today is generated > by peer-to-peer (P2P) applications used for file sharing, > real-time communications, and live media streaming. P2P > applications exchange large amounts of data, often uploading > as much as downloading. In contrast to client/server > architectures, P2P applications often have a selection of > peers and must choose. > > One of the advantages of P2P systems comes from redundancy in > resource availability. This requires choosing among download > locations, yet applications have at best incomplete > information about the topology of the network. Applications > can sometimes make empirical measurements of link > performance, but even when this is an option it takes time. > The application cannot always start out with an optimal > arrangement of peers, thus causing at least temporary reduced > performance and excessive cross-domain traffic. Providing > more information for use in peer selection can improve P2P > performance and lower ISP costs. > > The Working Group will design and specify an > Application-Layer Traffic Optimization (ALTO) service that > will provide applications with information to perform > better-than-random initial peer selection. > ALTO services may take different approaches at balancing > factors including maximum bandwidth, minimum cross-domain > traffic, lowest cost to the user, etc. The WG will consider > the needs of BitTorrent, tracker-less P2P, and other > applications, such as content delivery networks (CDN) and > mirror selection. > > > What does the above sentence mean? If we are putting such a list > together, we must also take into account needs from structured P2P > overlays such as those being specified in P2PSIP. > > The WG will focus on the following items: > > - A "problem statement" document providing a description of the > problem and a common terminology. > > - A requirements document. This document will list > requirements for the ALTO service, identifying, for example, > what kind of information P2P applications will need for > optimizing their choices. > > - A request/response protocol for querying the ALTO service > to obtain information useful for peer selection, and a format > for requests and > responses. The WG does not require intermediaries between the ALTO > server and the peer querying it. If the requirements > analysis identifies the need to allow clients to delegate > third-parties to query the ALTO service on their behalf, the > WG will ensure that the protocol provides a mechanism to > assert the consent of the delegating client. > > > Is this meant to allow for entities such as proxies to be in the path? > > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different > level of knowledge about the underlying network, such > preferences may have different representations. Initially the > WG will consider: IP ranges to prefer and to avoid, ranked > lists of the peers requested by the client, information about > topological proximity and approximate geographic locations. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > > > Earlier, it is mentioned that the requirements document will > determine the types of information that are useful for P2P > applications. Given that, it seems premature to conclude that the > WG should consider the above mentioned parameters. Also, as I > mentioned earlier, I think it is essential to keep the protocol and > message formats extensible and allow for exchange of any registered > information type. > > Another question I have is about the assumptions around expected > peer addressing models. Some of the above seems to hint at IP > addresses - is this an assumption already? > > - In order to query the ALTO server, clients must first know > one or more ALTO servers that might provide useful > information. The WG will look at service discovery > mechanisms that are in use, or defined elsewhere (e.g. > based on DNS SRV records or DHCP options). If such discovery > mechanisms can be reused, the WG will produce a document to > specify how they may be adopted for locating such servers. > However, a new, general-purpose service discovery mechanism > is not in scope. > > > Alternately, the clients may look for ALTO services within an > overlay. This can be modeled as service discovery within the > overlay - I'm, however, not suggesting that we take on solutions for > that. > > When the WG considers standardizing information that the ALTO > server could provide, the following criteria are important to > ensure real feasibility. > > - Can the ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that a client will find useful? > > I'm not sure how useful it is for us to answer this question. The > protocol we develop simply needs to be a container for any > information that has a registered type and fits a certain format. > > - Can a client get that information without excessive privacy concerns > (e.g. by sending large lists of peers)? > - Is it information that a client cannot find easily some other way? > > After these criteria are met, the generality of the data will > be considered for prioritizing standardization work, for > example the number of operators and clients that are likely > to be able to provide or use that particular data. > > If we can build an extensible protocol, we don't need to define all > possible kinds of information that get carried in it. > > In any > case, this WG will not propose standards on how congestion is > signaled, remediated, or avoided, and will not deal with > information representing instantaneous network state. > Such issues belong to other IETF areas and will be treated > accordingly by the specific area. > > This WG will focus solely on the communication protocol > between applications and ALTO servers. Note that ALTO > services may be useful in client-server environments as well > as P2P environments, although P2P environments are the first > focus. If, in the future, the IETF considers changes to > other protocols for actually implementing ALTO servers (e.g. > application-layer protocols for Internet coordinate systems, > routing protocol extensions for ISP-based solutions), such > work will be done in strict coordination with the appropriate WGs. > > > I hope we can also look at the above from a generalized service > perspective rather than just a client-server perspective. > > Thanks, > Vidya > > Issues related to the content exchanged in P2P systems are > also excluded from the WG's scope, as is the issue dealing > with enforcing the legality of the content. > > Goals and Milestones (very tentative dates): > > Apr 2009: Working Group Last Call for problem statement Jun > 2009: Submit problem statement to IESG as Informational Aug > 2009: Working Group Last Call for requirements document Oct > 2009: Submit requirements document to IESG as Informational > Jan 2010: Working Group Last Call for request/response > protocol Jan 2010: Working Group Last Call for usage document > for communicating network preferences Mar 2010: Submit > request/response protocol to IESG as Proposed Standard Mar > 2010: Submit usage document to IESG as Proposed Standard May > 2010: Working Group Last Call of discovery mechanism Jul > 2010: Submit discovery mechanism to IESG as Proposed Standard > Aug 2010: Dissolve or re-charter > > Initial Drafts for Consideration > - draft-marocco-alto-problem-statement-02 -- > Application-Layer Traffic Optimization (ALTO) Problem Statement > - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization > (ALTO) Requirements > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 13:22:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D1B3A69C3; Fri, 10 Oct 2008 13:22:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F533A69C3; Fri, 10 Oct 2008 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, 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 PLF+cdcswpt6; Fri, 10 Oct 2008 13:22:10 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B6DB13A691F; Fri, 10 Oct 2008 13:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223670178; x=1255206178; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Marshall=20Eubanks=20,=20"iesg@ ietf.org"=20|CC:=20"p2pi@ietf.org"=20,=20IETF=20Discussion=20|Date: =20Fri,=2010=20Oct=202008=2013:22:53=20-0700|Subject:=20R E:=20[p2pi]=20WG=20Review:=20Application-Layer=20Traffic =20Optimization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Re view:=20Application-Layer=20Traffic=20Optimization=20(alt o)|Thread-Index:=20Ackq0DfXnzmU9Ls6RN+pW3hXEk6yDgAQ/KMA |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10541314"; bh=BLrlP/j3PuE4eaiYuJW+SAfECP79WEHA5CeZB36YOq4=; b=ryDUl6vrhTTv6z4q/EL82PwQN81YSqmLV4cskH+AZ7l7b6DayG/Hu+kv tM1Cs85C+2iMOKIMl9OefkgMaJ7VSVwcj1A3129UaAY3/B5ssdvcrbEgf 2lhdY+bdC1M5LD1oaYPnhYd+8VHHUR/z08wm88SJwIX5H55kW15DJp7p3 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10541314" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 13:22:56 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKMtP0030602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 13:22:56 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKMtx9020248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Oct 2008 13:22:55 -0700 Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 13:22:55 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 13:22:54 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 10 Oct 2008 13:22:54 -0700 From: "Narayanan, Vidya" To: Marshall Eubanks , "iesg@ietf.org" Date: Fri, 10 Oct 2008 13:22:53 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackq0DfXnzmU9Ls6RN+pW3hXEk6yDgAQ/KMA Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , IETF Discussion Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Marshall makes some excellent points. Some additional thoughts on a few of his observations. > > Some comments in the charter below. This document clearly > needs some more work. As a overall comment, I think it is > premature to discuss ALTO "servers" and would keep the > charter focused on describing the ALTO "service." I do not > see consensus at this moment as to a central service solution > versus a distributed solution. > I fully agree. And, I see some discussions almost collapsing the two saying that eventually, there is a "server" that an ALTO client is talking to. That is incorrect in a distributed system and pre-supposing that will get us on the wrong solution path with a narrow view. > > > > > - Is the ALTO service willing to obtain and divulge that > information? > > Do computers have free will ? > > More seriously, it seems very odd to assume that a P2P > service will not do something that the owners of the peers > want it to do. In my opinion that drives P2P adoption much > more than the efficiencies of bandwidth sharing. > Absolutely! This also goes back to some of the responses on sharing uplink/downlink bandwidth information having privacy issues. If a peer is willing to share a piece of information, that makes that information viable to be shared. Building distributed systems within the confines of what may administratively be the best types of information to share doesn't automatically produce the best systems. > > Does this mean that congestion is not an issue to consider ? > > If the closest peer to me was totally congested and had no > available bandwidth, isn't that something that I would want to know ? > I do think this type of information is needed, but, I suspect ALTO is not the place for this. Peers may do measurement-based selection that eventually decides the best ranking of peers and the input from the ALTO service may just be one data point. Regards, Vidya _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 13:33:18 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BB63A67F4; Fri, 10 Oct 2008 13:33:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BFD3A635F; Fri, 10 Oct 2008 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 qQEeaA7KYFGa; Fri, 10 Oct 2008 13:33:16 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 13C103A67F4; Fri, 10 Oct 2008 13:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223670843; x=1255206843; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Lisa=20Dusseault=20,=0D=0A =20=20=20=20=20=20=20=20"Dondeti,=20Lakshminath"=0D=0A=09 |CC:=20"p2pi@ietf.org"=20,=20IESG=20IESG=20,=0D=0A=20=20=20 =20=20=20=20=20"ietf@ietf.org"=20|Date:=20 Fri,=2010=20Oct=202008=2013:34:01=20-0700|Subject:=20RE: =20[p2pi]=20WG=20Review:=20Application-Layer=20Traffic=20 Optimization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Revie w:=20Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20AckrDXVyuSkhuijRSkCAKM+froF1JgABZ7Yw |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=09=0D=0A =09<48EEB19C.4000303@bbn.com>=20<48EEE549.1080208@qualcom m.com>=0D=0A=09<48EF477E.4080708@telecomitalia.it>=20<48E F706C.9050508@qualcomm.com>=0D=0A=09<48EFA0BE.1040809@alc atel-lucent.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10542210"; bh=K9ehEGOYHnjCjKhJI/FgU8sWSGAZZd9htdgBwd/SGwQ=; b=AUUdXI2tdCsRkog99jrRXsR7qjmznpW2zAIcbZjegAYr+45JqlCrZwe7 NPHE+4k1kjgD4Q6ncF2VHs1ApVqRQi222ewVHX0WjGNR1er9l6PN9XLuV pjr1+DcxKtbOZRH3qNx0yORhg1M09jv4Htu+gCVGl8WEi8PwmeEZnOYrW 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10542210" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 13:34:03 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKY2Du031949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 13:34:03 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKY2dd003381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Oct 2008 13:34:02 -0700 (PDT) Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 13:34:01 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 10 Oct 2008 13:34:01 -0700 From: "Narayanan, Vidya" To: Lisa Dusseault , "Dondeti, Lakshminath" Date: Fri, 10 Oct 2008 13:34:01 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckrDXVyuSkhuijRSkCAKM+froF1JgABZ7Yw Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lisa, Enrico, Vijay, Thanks for the clarifications. I went through the P2PI mailing list and found some interesting discussions. There are some topics where I don't yet see consensus and some of the discussions still seem open. As Marshall, Sam, Lakshminath and I have pointed out, I don't yet see a consensus on whether the ALTO service is a centralized or distributed one. I also noted some unresolved discussions on the list on the types of information that can be shared as part of this service. As I've already noted, I do support the work and believe it needs to be done. But, I don't believe we have sorted out all the charter issues yet and focusing on that discussion would help move this forward. Instead, I see a lot of emails reinstating the importance of the work and that it needs to move forward. Well, that's clearly not the point of debate at all here, since I haven't seen anyone say the work is not important. A couple of notes inline. > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Lisa Dusseault > Sent: Friday, October 10, 2008 12:21 PM > To: Dondeti, Lakshminath > Cc: p2pi@ietf.org; IESG IESG; ietf@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Lakshminath and Vidya, > > Vijay, Enrico and Stefano have said what I was going to say > (e.g. below) -- as sponsoring AD for this charter I've been > following the WG discussion, working with the rest of the > IESG, and talking to people to confirm that there's better > consensus on the list, even if there was confusion at the > BOF. This IETF Last Call is also part of confirming whether > there's now consensus. > > It's difficult to write a charter without actually designing > the solution. What would help with the charter, even now, is > for people to write up proposals for the solution -- ideally > in the form of Internet-Drafts. I haven't yet selected > chairs for the WG, so as you can imagine editors and authors > aren't yet selected. It would be most excellent to see some > individual proposals before a committee gets their hands on them :) > The above made me wonder if we are still operating at the IETF :) We repeatedly chastize people for writing charters with a solution in mind. I think it is extremely premature to talk about specific solutions, editors and authors - we have more fundamental discussions to be had on scoping the problem and agreeing to what is going to be solved. I hope we can do that first. Regards, Vidya > Lisa > > > > > On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani > wrote: > > > ... > > > And since the BoF, much has changed to narrow the scope of the > charter down to more manageable pieces as well as establish a > channel with IRTF to move certain aspects of the work there > (as the timeline in my previous email indicated.) > > > Lakshminath Dondeti wrote: > > > > > My perception and my understanding of some of > the dissenting opinions > was that some of those need to be worked out > before creating a working group. > > > > But I believe that we have done exactly that: the list has been > busy since Dublin on attempts to move the work forward > in a manner > that is conducive to all participants. > > > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 14:30:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71FA3A6A62; Fri, 10 Oct 2008 14:30:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10233A69CB; Fri, 10 Oct 2008 14:30:45 -0700 (PDT) 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=[AWL=0.000, 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 yP0Ntep23v+i; Fri, 10 Oct 2008 14:30:44 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9F75E3A6A62; Fri, 10 Oct 2008 14:30:44 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9ALVUu6001380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 16:31:30 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9ALVT9n011039; Fri, 10 Oct 2008 16:31:29 -0500 (CDT) Message-ID: <48EFC9B0.8040609@alcatel-lucent.com> Date: Fri, 10 Oct 2008 16:31:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tme@multicasttech.com References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Marshall Eubanks wrote: > I support this moving forward. My reading of the room in Dublin was > that there was serious support for this and certainly a critical mass > to move forward. Marshall: Thank you for your review. More inline. > Some comments in the charter below. This document clearly needs some > more work. As a overall comment, I think it is premature to discuss > ALTO "servers" and would keep the charter focused on describing the > ALTO "service." In an earlier reply to Vidya I note that the charter does indeed predominantly refer to "ALTO services" over "ALTO server". Having said that, if I did not convince you through that argument, then we can leave the "s/ALTO server/ALTO service" discussion on the table. > I do not see consensus at this moment as to a central > service solution versus a distributed solution. Agreed. > s/choose/choose the best peer or peers to exchange data with/ Unfortunately, in the Dublin BoF charter, we did state best peer (we had termed it "optimal" peer). This was one reason for the negative hums in the BoF because people have differing notion of what an "optimal" (or best) peer is. Thus, we reverted to the non-confrontational use of the phrase that you now see in the charter. >> - A request/response protocol for querying the ALTO service to >> obtain information useful for peer selection, and a format for >> requests and responses. The WG does not require intermediaries >> between the ALTO > > This is strange wording, as WG themselves are not protocols. > > More fundamentally, is this a requirement? No. We had some list discussion on whether or not to include intermediaries, but the resolution of that discussion appeared to be no (please see the few emails around the following link: http://www.ietf.org/mail-archive/web/p2pi/current/msg00635.html). >> - Can the ALTO service technically provide that information? > > I think that what is meant here is "Can the ALTO service > realistically discover that information?" OK. >> - Is the ALTO service willing to obtain and divulge that >> information? > > Do computers have free will? AI notwithstanding ;-) But point taken; we can attempt a reword (if you have any suggestions, please throw them our way.) >> After these criteria are met, the generality of the data will be > > What is meant by "the generality of the data" ? >> >> considered for prioritizing standardization work, for example the Hmmm ... since we are talking about prioritizing, maybe what is meant is "importance" -- as in "importance of the service" -- may be a better fit. Comments? >> number of operators and clients that are likely to be able to >> provide or use that particular data. In any case, this WG will not >> propose standards on how congestion is signaled, remediated, or >> avoided, and > > Does this mean that congestion is not an issue to consider ? It is, but not in ALTO. That will be part of TANA. > If the closest peer to me was totally congested and had no available > bandwidth, isn't that something that I would want to know ? >> >> will not deal with information representing instantaneous network >> state. > > What is meant by "information representing instantaneous network > state" ? Isn't this a protocol to share information about the state > of the network ? Or is this an attempt to separate network topology > from network performance ? But should network performance also be an > issue ? By and large, it has been the case that that instantaneous network characteristics -- like current link usage, congestion, etc. -- are not be part of ALTO; they will be part of TANA. Hence, congestion control was deemed out of scope. > What is an Internet coordinate system? Things like IDMaps, GNP, Vivaldi, etc. Should we define this term in the charter? Thanks, Marshall. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 14:51:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09EC3A6AAC; Fri, 10 Oct 2008 14:51:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1316D3A6967; Fri, 10 Oct 2008 14:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3qimd-R5Glsd; Fri, 10 Oct 2008 14:50:57 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 938BC3A6A6F; Fri, 10 Oct 2008 14:50:57 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13330053; Fri, 10 Oct 2008 17:51:44 -0400 Message-Id: <01D538D0-081C-448C-9E7D-B50A1699F07A@multicasttech.com> From: Marshall Eubanks To: "Vijay K. Gurbani" In-Reply-To: <48EFC9B0.8040609@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 17:51:43 -0400 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFC9B0.8040609@alcatel-lucent.com> X-Mailer: Apple Mail (2.929.2) Cc: "p2pi@ietf.org" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dear Vijay; On Oct 10, 2008, at 5:31 PM, Vijay K. Gurbani wrote: > Marshall Eubanks wrote: >> I support this moving forward. My reading of the room in Dublin was >> that there was serious support for this and certainly a critical mass >> to move forward. > > Marshall: Thank you for your review. More inline. > >> Some comments in the charter below. This document clearly needs some >> more work. As a overall comment, I think it is premature to discuss >> ALTO "servers" and would keep the charter focused on describing the >> ALTO "service." > > In an earlier reply to Vidya I note that the charter does indeed > predominantly refer to "ALTO services" over "ALTO server". > Having said that, if I did not convince you through that > argument, then we can leave the "s/ALTO server/ALTO service" > discussion on the table. > >> I do not see consensus at this moment as to a central >> service solution versus a distributed solution. > > Agreed. To me, this agreement answers the previous point. (Servers presupposes the answer, service does not IMO.) > > >> s/choose/choose the best peer or peers to exchange data with/ > > Unfortunately, in the Dublin BoF charter, we did state best peer > (we had termed it "optimal" peer). This was one reason for the > negative hums in the BoF because people have differing notion of > what an "optimal" (or best) peer is. Thus, we reverted to the > non-confrontational use of the phrase that you now see in the > charter. OK, but is doesn't read well : In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. There is a missing object. How about must choose one or more peers from this selection. ? > > >>> - A request/response protocol for querying the ALTO service to >>> obtain information useful for peer selection, and a format for >>> requests and responses. The WG does not require intermediaries >>> between the ALTO >> This is strange wording, as WG themselves are not protocols. >> More fundamentally, is this a requirement? > > No. We had some list discussion on whether or not to include > intermediaries, but the resolution of that discussion appeared > to be no (please see the few emails around the following > link: http://www.ietf.org/mail-archive/web/p2pi/current/ > msg00635.html). How about s/The WG does not/In scope solutions do not/ > > >>> - Can the ALTO service technically provide that information? >> I think that what is meant here is "Can the ALTO service >> realistically discover that information?" > > OK. > >>> - Is the ALTO service willing to obtain and divulge that >>> information? >> Do computers have free will? > > AI notwithstanding ;-) But point taken; we can attempt a > reword (if you have any suggestions, please throw them our way.) > Whose will ? This gets to a crucial difference between a central server and a distributed system. If it is a central server, then the owner of that server gets a vote here, and maybe a veto. It it is distributed service, then the owners of the peers will ultimately decide this. How about - Is the ALTO service technically able to obtain that information, and is the distribution of that information allowed by the operators of that service ? >>> After these criteria are met, the generality of the data will be >> What is meant by "the generality of the data" ? >>> considered for prioritizing standardization work, for example the > > Hmmm ... since we are talking about prioritizing, maybe what is > meant is "importance" -- as in "importance of the service" -- > may be a better fit. Comments? > WFM >>> number of operators and clients that are likely to be able to >>> provide or use that particular data. In any case, this WG will not >>> propose standards on how congestion is signaled, remediated, or >>> avoided, and >> Does this mean that congestion is not an issue to consider ? > > It is, but not in ALTO. That will be part of TANA. > ACK >> If the closest peer to me was totally congested and had no available >> bandwidth, isn't that something that I would want to know ? >>> will not deal with information representing instantaneous network >>> state. >> What is meant by "information representing instantaneous network >> state" ? Isn't this a protocol to share information about the state >> of the network ? Or is this an attempt to separate network topology >> from network performance ? But should network performance also be an >> issue ? > > By and large, it has been the case that that instantaneous > network characteristics -- like current link usage, congestion, > etc. -- are not be part of ALTO; they will be part of TANA. > Hence, congestion control was deemed out of scope. > OK. This WFM now. >> What is an Internet coordinate system? > > Things like IDMaps, GNP, Vivaldi, etc. Should we define this > term in the charter? > I was not aware of this work. Thanks for alerting me to it. Regards Marshall > Thanks, Marshall. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 15:09:22 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD46728C108; Fri, 10 Oct 2008 15:09:22 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717AA3A6A2E; Fri, 10 Oct 2008 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 abQ2UjDKX4un; Fri, 10 Oct 2008 15:09:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 472BB3A696A; Fri, 10 Oct 2008 15:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223676607; x=1255212607; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48EFD2BC.8050706@qualcomm.com>|Date:=20Fr i,=2010=20Oct=202008=2015:10:04=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Lisa=20Dusseault=20 |CC:=20"p2pi@ietf.org"=20,=20IESG=20IESG =20,=20ietf@ietf.org|Subject:=20Re:=20[p2p i]=20WG=20Review:=20Application-Layer=20Traffic=20Optimiz ation=20(alto)|References:=20<20081006203532.B1D673A68AF@ core3.amsl.com>=09=20=09=20<48EEB19C.4000303 @bbn.com>=20<48EEE549.1080208@qualcomm.com>=09=20<48EF477 E.4080708@telecomitalia.it>=20<48EF706C.9050508@qualcomm. com>=09=20<48EFA0BE.1040809@alcatel-lucent.com>=20 |In-Reply-To:=20|Content-Type:=20text/plain=3B=20chars et=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5402"=3B=20a=3D"10632419"; bh=R8S+hirsnjECKpKpy4uLJOTBmBVlv1TMb1BaNLWr5UY=; b=CVb2mCqF2OTdTNJvUBHOZulWY86HUUBPFo5jk6gzv2frVzexs7VoX2rR CysAGfyuFtzWWdOPnRAggZH59g8bMjf8qFZSlkp9bkyNostdiNurEVMYv H4s9GCFYaqVnhBRoXrOZFuNCZggCDthfVYa/HcdFJnZwQR2+ztwUL3FGP k=; X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10632419" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 15:10:06 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AMA5oW013284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 15:10:05 -0700 Received: from [129.46.74.185] (ldondeti.na.qualcomm.com [129.46.74.185]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AMA5VI000726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Oct 2008 15:10:05 -0700 Message-ID: <48EFD2BC.8050706@qualcomm.com> Date: Fri, 10 Oct 2008 15:10:04 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> In-Reply-To: Cc: "p2pi@ietf.org" , IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 10/10/2008 12:21 PM, Lisa Dusseault wrote: > Lakshminath and Vidya, > > Vijay, Enrico and Stefano have said what I was going to say (e.g. below) > -- as sponsoring AD for this charter I've been following the WG > discussion, working with the rest of the IESG, and talking to people to > confirm that there's better consensus on the list, even if there was > confusion at the BOF. This IETF Last Call is also part of confirming > whether there's now consensus. Hi Lisa, My concern can be put in really simple terms. We have some really very confusing processes and we seem to add to the confusion and not make things simpler. I left Dublin thinking, out of the p2pi efforts, TANA will be a WG (there was strong consensus and agreement on the problem space and what needs to be done) and ALTO may have another BoF. As of today, there is a WG proposal on the table for ALTO and in a different area from where we started; TANA is on the BoF wiki. Next, my experiences in the past on BoFs that did not have consensus have been dramatically different from what is happening on ALTO. The IESG has really even refused to allow another BoF much less directly started creating a working group. So, it makes me wonder whether the rules have recently been changed or whether they are selectively applied. I am also confused by your use of the word consensus; you say that you've "talked to people" to confirm that there's "better consensus on the list," but also say that the charter review is also part of the consensus process. Shouldn't there be a call for consensus? > > It's difficult to write a charter without actually designing the > solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. " - Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants may be limited?" > What would help with the charter, even now, is for people to > write up proposals for the solution -- ideally in the form of > Internet-Drafts. This seems to be starkly different from the process I know of. Are you really suggesting that people come up with solutions to help with the charter? What problem are we solving? What are the requirements? Based on the proposal that was sent out, we won't have consensus on all of those until Oct 2009 or later. Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational > I haven't yet selected chairs for the WG, so as you > can imagine editors and authors aren't yet selected. > It would be most > excellent to see some individual proposals before a committee gets their > hands on them :) I am sorry Lisa, but I am really confused by your request for proposals before we even agree on the problem. I am hoping for a clarification. thanks, Lakshminath > > Lisa > > > > On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani > > wrote: > > ... > > > And since the BoF, much has changed to narrow the scope of the > charter down to more manageable pieces as well as establish a > channel with IRTF to move certain aspects of the work there > (as the timeline in my previous email indicated.) > > Lakshminath Dondeti wrote: > > > > My perception and my understanding of some of the dissenting > opinions > was that some of those need to be worked out before creating a > working group. > > > But I believe that we have done exactly that: the list has been > busy since Dublin on attempts to move the work forward in a manner > that is conducive to all participants. > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 10 18:26:47 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550953A6B02; Fri, 10 Oct 2008 18:26:47 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DEA3A6A62; Fri, 10 Oct 2008 18:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, 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 Qiwd2PY7vrNs; Fri, 10 Oct 2008 18:26:44 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 04F953A69C6; Fri, 10 Oct 2008 18:26:43 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Oct 2008 03:27:29 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Oct 2008 03:27:29 +0200 Received: from [172.16.82.10] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Oct 2008 03:27:28 +0200 Message-ID: <48F000FD.5000302@telecomitalia.it> Date: Sat, 11 Oct 2008 03:27:25 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Lakshminath Dondeti References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> In-Reply-To: <48EFD2BC.8050706@qualcomm.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 11 Oct 2008 01:27:28.0343 (UTC) FILETIME=[86095670:01C92B40] Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884836521==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1884836521== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060502020709010303050907" This is a cryptographically signed message in MIME format. --------------ms060502020709010303050907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lakshminath Dondeti wrote: >> It's difficult to write a charter without actually designing the >> solution. > > This is an interesting opinion. May I translate that to mean that there > is already a solution in the minds of the people who wrote the charter? Nope. Who has been following the p2pi list for the last five months probably knows that there are three different approaches (solutions?) floating around: the "sorting oracle" (described in a SIGCOMM paper authored by folks from TU-Berlin, a variant of which is IDIPS), P4P (soon to be published as I-D and, IIRC, described in another SIGCOMM paper), and Stanislav's proposal (discussed in Dublin and on the list: http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who wrote the charter had all those approaches clear in mind and took special care that none of them got ruled out. > Why then would we bother with the proposed requirements effort, writing > down a problem statement and all the rest? Why not put an RFC number on > the solution? > > It also makes me wonder what your opinion on the following from 2418. > > " - Is the proposed work plan an open IETF effort or is it an attempt > to "bless" non-IETF technology where the effect of input from IETF > participants may be limited?" I don't know Lisa's opinion, but am sure that this is not the case here. -- Ciao, Enrico --------------ms060502020709010303050907 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTEwMTI3MjVaMCMG CSqGSIb3DQEJBDEWBBQ8wXEd/VqQizmLG60kAJHAg/SHMjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABX83PeUH9Bo P5sVPDtj8mNyow7GkM7l3O0qqkkxmddsQtec1GOjuIYIiQHM3Vwh9E6xzVLCSX9h2y5IUzK5 KxwGB0Aym7iKoviB/8iq6cWC0JWcP/MI5ExxeS4CEGJm4ITA8hft1K10EF8/GYdq8PQtcn1I ukibwgAQPAfYWNmyNyBYkhcV8zDjxsCSx7rDG6OJYWTpumJotTt4weFRbOkmXPakP4fU4pr4 Jd69BZOgzWOBSD0rcpNTEuRZqNL0hviQTSc5a99/4c2eeLZ507PGUJe6XKUkIWwecZwtUJ0O k+dqplq0Y7dePZQeuAPASbsYgRzskkMG4sO3y3xZH5kAAAAAAAA= --------------ms060502020709010303050907-- --===============1884836521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1884836521==-- From p2pi-bounces@ietf.org Fri Oct 10 21:58:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839EF28C15F; Fri, 10 Oct 2008 21:58:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2664D3A6834; Fri, 10 Oct 2008 21:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.214 X-Spam-Level: X-Spam-Status: No, score=-105.214 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 oDcvAFjBrOJz; Fri, 10 Oct 2008 21:58:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CAF5A3A67F8; Fri, 10 Oct 2008 21:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223701147; x=1255237147; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48F03281.2030900@qualcomm.com>|Date:=20Fr i,=2010=20Oct=202008=2021:58:41=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Enrico=20Marocco=20|CC:=20Lisa=20Dusseault=20, =20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20 =20=20=20=20IESG=20IESG=20,=20"ietf@ietf.o rg"=20|Subject:=20Re:=20[p2pi]=20WG=20Revi ew:=20Application-Layer=20Traffic=20Optimization=20(alto) |References:=20<20081006203532.B1D673A68AF@core3.amsl.com >=09=09=09=09<48EEB19C.4000303@bbn.com>=20<4 8EEE549.1080208@qualcomm.com>=09=09<48EF477E.4080708@tele comitalia.it>=09<48EF706C.9050508@qualcomm.com>=09=09<48E FA0BE.1040809@alcatel-lucent.com>=09=20<48EFD2BC.80507 06@qualcomm.com>=20<48F000FD.5000302@telecomitalia.it> |In-Reply-To:=20<48F000FD.5000302@telecomitalia.it> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-15=3B =20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5403"=3B=20 a=3D"10664391"; bh=WcRQAHLK7Et0KPrpczIVje3bJ8uT1Q56olBtoru816c=; b=rgiu0euxLS1fsn1WDO2ph4kSpcG1nLjQiH9W9SiZ/0x41WFarBeiG+Og uUKajI/g7SljFNHKWgqeO0ctgFI3I2mdGahFAZSh0kKhNywMtLYguFT0d llCh12BX2Trpke/R9C4Mzk8+KkGkHiht6Z7b6d3sPw1bJ+7tXYcr4UUPy c=; X-IronPort-AV: E=McAfee;i="5300,2777,5403"; a="10664391" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 21:58:53 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9B4wqKq019410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 21:58:52 -0700 Received: from [10.50.69.64] (qconnect-10-50-69-64.qualcomm.com [10.50.69.64]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9B4wodc003938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Oct 2008 21:58:51 -0700 (PDT) Message-ID: <48F03281.2030900@qualcomm.com> Date: Fri, 10 Oct 2008 21:58:41 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Enrico Marocco References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> In-Reply-To: <48F000FD.5000302@telecomitalia.it> Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Thanks for the clarification Enrico :). best, Lakshminath On 10/10/2008 6:27 PM, Enrico Marocco wrote: > Lakshminath Dondeti wrote: >>> It's difficult to write a charter without actually designing the >>> solution. >> This is an interesting opinion. May I translate that to mean that there >> is already a solution in the minds of the people who wrote the charter? > > Nope. Who has been following the p2pi list for the last five months > probably knows that there are three different approaches (solutions?) > floating around: the "sorting oracle" (described in a SIGCOMM paper > authored by folks from TU-Berlin, a variant of which is IDIPS), P4P > (soon to be published as I-D and, IIRC, described in another SIGCOMM > paper), and Stanislav's proposal (discussed in Dublin and on the list: > http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who > wrote the charter had all those approaches clear in mind and took > special care that none of them got ruled out. > >> Why then would we bother with the proposed requirements effort, writing >> down a problem statement and all the rest? Why not put an RFC number on >> the solution? >> >> It also makes me wonder what your opinion on the following from 2418. >> >> " - Is the proposed work plan an open IETF effort or is it an attempt >> to "bless" non-IETF technology where the effect of input from IETF >> participants may be limited?" > > I don't know Lisa's opinion, but am sure that this is not the case here. > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Oct 12 15:58:57 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC793A6AAE; Sun, 12 Oct 2008 15:58:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4513A69EC; Sun, 12 Oct 2008 15:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, 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 5im0t7FlnlmV; Sun, 12 Oct 2008 15:58:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6E85E3A6AC3; Sun, 12 Oct 2008 15:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223852387; x=1255388387; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Vijay=20K.=20Gurbani"=20|CC: =20IESG=20IESG=20,=20"ietf@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"p2pi@ietf.org "=20|Date:=20Sun,=2012=20Oct=202008=2015:5 9:43=20-0700|Subject:=20RE:=20[p2pi]=20WG=20Review:=20App lication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20[p2pi]=20WG=20Review:=20Application-Laye r=20Traffic=20Optimization=20(alto)|Thread-Index:=20AckrB 8UxxycZhW5DQNmtzaNDmm9pNgACj0qw|Message-ID:=20|References:=20<20081006203532.B1D673A68AF@core3.amsl.c om>=0D=0A=20=0D=0A=20<48EFA1B7.7010508@alcat el-lucent.com>|In-Reply-To:=20<48EFA1B7.7010508@alcatel-l ucent.com>|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5403"=3B=20a=3D"10797874"; bh=cuYsvVWkTvigwwiA+34UYefjzZoEYewBdsb2DTyu2tk=; b=hczI8BLvNtXbkCUCNOYIVkdtu67mld2IKJ/unMQxRn6rvSxckDEEbi1D qZ8AiQ6v0PxNbcV627vFphvGWyI3UxdQR9j0FSq3TdTO0y1EexA3mWXaA ghHOONN7Jg26txn9gLEovR/61eONTiAnfq3RzSRRrqo7+TaBDkSJndhtY 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5403"; a="10797874" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2008 15:59:46 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9CMxjEj000900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Oct 2008 15:59:45 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9CMxjHi011829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 12 Oct 2008 15:59:45 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 12 Oct 2008 15:59:44 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Sun, 12 Oct 2008 15:59:44 -0700 From: "Narayanan, Vidya" To: "Vijay K. Gurbani" Date: Sun, 12 Oct 2008 15:59:43 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qw Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> In-Reply-To: <48EFA1B7.7010508@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vijay, Thank you for your response. Please see comments inline below. > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Friday, October 10, 2008 11:41 AM > To: Narayanan, Vidya > Cc: IESG IESG; ietf@ietf.org; p2pi@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Narayanan, Vidya wrote: > > I am surprised to see that ALTO is being proposed for a WG > after the > > last BoF concluded with no consensus whatsoever. I think a > second BoF > > is more appropriate than a WG on the topic at this time. > That said, I > > do see the need for this work, although I have some comments on the > > current direction. > > Vidya: Thank you for the feedback. After analyzing your > points, it seems that the charter as written is already > conducive to the important points raised in your review of it > (i.e., we may already be in agreement.) > > More inline. > > > Overall, I think we should work with the notion of an ALTO "service" > > rather than specifically an ALTO "server". > > Great. I believe that is exactly what the charter does; the > charter talks in terms of an "ALTO service" at many places > (pedantically speaking, the term "ALTO service" occurs eight > times and the term "ALTO server" occurs six.) The ALTO "server" > mentioned in the charter refers to the *host* the client > finally queries (calling it a "peer" is ambiguous; if you > have a specific term to use here instead of "server", please > do let us know.) > When we consider ALTO as a distributed service, there may not necessarily be "a" host that specifically resolves the ALTO queries. For instance, consider the case where ALTO is a service offered in an overlay. There may be peers publishing information about themselves on the overlay and other peers looking up such information. These are not necessarily client-server style communications. In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information. Now, of course, that is one possible model. But, in order to allow for that and other models, I do want the charter to keep the focus on the service and not on a server. > > The ALTO service may be provided by a server, a cluster of > distributed > > servers or as a service in an overlay. Although some of > the charter > > wording talks about a "service" rather than a "server", there is > > enough mention of a "server" entity to imply a strict client-server > > protocol. > > The charter is not meant to imply a centralized architecture, > nor to rule out peer-to-peer implementations of it. The > charter simply mentions a "request/reply" protocol is needed. > Whether or not there is a cluster of ALTO servers or one > needs to be decided by the requirement analysis and > subsequent discussions in the WG. > > > As part of that, I think there are a couple of key things > that need to > > be addressed here: > > > > - A protocol that allows peers (or ALTO clients) to publish > > information about themselves as part of the ALTO service. > An example > > of such information may be the uplink/downlink bandwidth of > the peer. > > We have had discussions on the mailing list about this already. > Some people felt that providing uplink bandwidth would not be > a good idea for various reasons running from privacy concerns > to peers skewing traffic in favor of a high uplink bandwidth. > Others felt that even if a peers uplink bandwidth was not > provided, it could calculated nonetheless by other peers. > That is, there are degrees of disagreement here and > consequently, including a contentious point in the charter > would be counter- productive. > I'm afraid that would be a mistake. It actually doesn't matter if we don't agree today on the exact types of information that can be shared. It is important that we have a protocol that allows peers to publish ALTO related information. Having this protocol be extensible would allow for any type of information to be carried in it. So, I strongly believe we don't need a recharter to consider any information types - in fact, I'd be okay if this effort only took on the protocol and if all information types were to be registered through other means. That said, I'm not against taking on some subset of those types - I don't believe that should be the core focus of this work though. > > - The ability to register information types with IANA and extend > > these. > > Having a IANA registry for the information type carried in > the protocol is certainly a possibility the charter does not > rule out, no? > Well, it is a bit hard to say what the charter does not rule out - typically we try and do what the charter says we should do. However, before we get to the registry, we need to agree on the protocol components. In my view, there are two such components - the publish protocol mentioned above and the request/response protocol (actually, more generically, a lookup protocol) mentioned below. > > The request/response protocol should be a generic enough > container for > > any information that peers can provide and look for, plus > what may be > > available from service providers, etc. There may be some > guidelines > > on how such information types can be registered and we may > start with > > default ones. > > Exactly; this is what the charter is saying in the paragraph: > > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different level > of knowledge about the underlying network, such preferences > may have different representations. Initially the WG will > consider: IP ranges to prefer and to avoid, ranked lists of > the peers requested by the client, information about > topological proximity and approximate geographic locations. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > > We *are* starting with the default information; as other > information is required, we can extend the charter, right? Actually, I am saying that is exactly what is not needed. I don't see the information types as something this effort will necessarily nail down. We need to define interoperable semantics for the protocol - what gets carried in it may actually be registered as a type in the registry outside of this effort. The registry comes into picture for enabling this part. > Extending the charter is cheap -- it is a bureaucratic > process that will auto- matically happen if there are enough > interested parties willing to do the work and the work is > considered to be important enough. > I believe that the higher bar is ensuring that the initial > charter contains the right amount of work so that the WG can > finish it in an appropriate amount of time. > > >> The Working Group will design and specify an Application-Layer > >> Traffic Optimization (ALTO) service that will provide > applications > >> with information to perform better-than-random initial peer > >> selection. ALTO services may take different approaches at > balancing > >> factors including maximum bandwidth, minimum cross-domain > traffic, > >> lowest cost to the user, etc. The WG will consider the needs of > >> BitTorrent, tracker-less P2P, and other applications, such > as content > >> delivery networks (CDN) and mirror selection. > > > > What does the above sentence mean? If we are putting such a list > > together, we must also take into account needs from structured P2P > > overlays such as those being specified in P2PSIP. > > In P2PSIP, the amount of information being stored in the > overlay is small (a R-URI, on the order of tens of bytes.) > ALTO will not much help there. OTOH, ALTO will help > tremendously if in a P2PSIP network, there is a need to find > a peer that hosts the recording of a 2-hour conference call. > Nothing in the ALTO charter prevents this from happening as > it is specified today. > I would like us to think beyond applications we see today. Had TCP not been designed that way, we probably would have needed a redesign of it for HTTP :) I can envision video applications using the P2PSIP framework, for instance. In any event, I still don't have a good understanding of what it means to consider the needs of these various things - what does it mean to say that we'll consider the needs of BitTorrent/CDN, etc.? Could you maybe give me an example of what it means? > > Is this meant to allow for entities such as proxies to be > in the path? > > There's been quite a lot of discussion on this topic on the list. > Current consensus is to keep the architecture as simple as > possible and exclude at least initially support for > non-transparent intermediaries; if at some point we have > evidence of the need for it, the group will go through rechartering. > Okay. > > Earlier, it is mentioned that the requirements document > will determine > > the types of information that are useful for P2P > applications. Given > > that, it seems premature to conclude that the WG should > consider the > > above mentioned parameters. Also, as I mentioned earlier, > I think it > > is essential to keep the protocol and message formats > extensible and > > allow for exchange of any registered information type. > > The limit on what data to consider initially was suggested to > avoid the group to wander for years discussing any kind of > possible information; however, extensibility will be the key > principle in designing a protocol (for good design practices > rather than because it is written in the charter). > Again, as I wrote above, I think the information types are less important than the container for any such type in the protocol. > > Another question I have is about the assumptions around > expected peer > > addressing models. Some of the above seems to hint at IP addresses > > - is this an assumption already? > > No, the text says "ranked lists of the peers requested by the > client" exactly because we still don't know how they could be > identified. > Hmmm... Okay. Perhaps it would be good to say that some analysis is needed to determine how to identify the peers? Maybe this is something that needs to happen in the requirements phase. > >> > >> - Can the ALTO service technically provide that information? > >> - Is the ALTO service willing to obtain and divulge that > information? > >> - Is it information that a client will find useful? > > > > I'm not sure how useful it is for us to answer this question. The > > protocol we develop simply needs to be a container for any > information > > that has a registered type and fits a certain format. > > Sure, no disagreements here. However, the list of questions > that appears in the charter was suggested as a set of minimum > vetting points to ensure that the WG spent some thought > process on making an adequate determination on the importance > and use of an ALTO service. The list of questions does not > inhibit the protocol we develop in any way. > What I am saying is that it is not for us to determine the usefulness of a particular piece of information. As long as the peers or service providers are willing to share a piece of information, that can be consumed by other peers as they deem fit. So, I don't think we should consider ourselves the gatekeeper for the types of information shared. Best regards, Vidya _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Oct 13 08:02:57 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9407E28C108; Mon, 13 Oct 2008 08:02:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA4E3A688A; Mon, 13 Oct 2008 08:02:56 -0700 (PDT) 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 9MlXTGUO7PsE; Mon, 13 Oct 2008 08:02:55 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4605D3A67F1; Mon, 13 Oct 2008 08:02:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DCA932C0012C2; Mon, 13 Oct 2008 17:03:09 +0200 (CEST) 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 Nq1u2FT0-LYy; Mon, 13 Oct 2008 17:03:09 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id AB83A2C000304; Mon, 13 Oct 2008 17:02:44 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 17:02:41 +0200 Message-ID: <547F018265F92642B577B986577D671C3DF92C@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qwAIwwruA= References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com> From: "Martin Stiemerling" To: "Narayanan, Vidya" , "Vijay K. Gurbani" Cc: p2pi@ietf.org, IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vidja, all, I believe that the charter is narrow and broad enough to cover the topic of ALTO, i.e., the charter is not limiting the solution space. However, when reading your comments, it sounds that you have a very specific solution in mind which is probably not covered by the current charter. [...] > > > > > Overall, I think we should work with the notion of an ALTO > "service" > > > rather than specifically an ALTO "server". > > > > Great. I believe that is exactly what the charter does; the > > charter talks in terms of an "ALTO service" at many places > > (pedantically speaking, the term "ALTO service" occurs eight > > times and the term "ALTO server" occurs six.) The ALTO "server" > > mentioned in the charter refers to the *host* the client > > finally queries (calling it a "peer" is ambiguous; if you > > have a specific term to use here instead of "server", please > > do let us know.) > > > > When we consider ALTO as a distributed service, there may not > necessarily be "a" host that specifically resolves the ALTO queries. > For instance, consider the case where ALTO is a service offered in an > overlay. There may be peers publishing information about themselves on > the overlay and other peers looking up such information. These are not > necessarily client-server style communications. In fact, all that is > important in this context is that the overlay acts as a rendezvous for > sharing such information. Now, of course, that is one possible model. You probably have a publish/subscribe system in mind for p2p overlays. I assume this is not in scope of ALTO. > But, in order to allow for that and other models, I do want the charter > to keep the focus on the service and not on a server. Is the IETF anyhow standardizing services? I don't see this. [...] > > > > We have had discussions on the mailing list about this already. > > Some people felt that providing uplink bandwidth would not be > > a good idea for various reasons running from privacy concerns > > to peers skewing traffic in favor of a high uplink bandwidth. > > Others felt that even if a peers uplink bandwidth was not > > provided, it could calculated nonetheless by other peers. > > That is, there are degrees of disagreement here and > > consequently, including a contentious point in the charter > > would be counter- productive. > > > > I'm afraid that would be a mistake. It actually doesn't matter if we I'm afraid that carrying up/downlink capacity of the peer's local link is a complete waste of resource, as this is not indicating something. For instance, a peer may have a relatively huge uplink but on a shared medium, i.e., a medium which might be shared by hundreds of other hosts/traffic. So what does this information express? > don't agree today on the exact types of information that can be shared. > It is important that we have a protocol that allows peers to publish > ALTO related information. Having this protocol be extensible would > allow for any type of information to be carried in it. So, I strongly The question is, whether the roots of ALTO are actually intended to carry any type of information? The main idea is to carry information to optimize traffic, e.g., decreasing cross ISP traffic. > believe we don't need a recharter to consider any information types - > in fact, I'd be okay if this effort only took on the protocol and if > all information types were to be registered through other means. That > said, I'm not against taking on some subset of those types - I don't > believe that should be the core focus of this work though. > > > > - The ability to register information types with IANA and extend > > > these. > > > > Having a IANA registry for the information type carried in > > the protocol is certainly a possibility the charter does not > > rule out, no? > > > > Well, it is a bit hard to say what the charter does not rule out - > typically we try and do what the charter says we should do. However, > before we get to the registry, we need to agree on the protocol > components. In my view, there are two such components - the publish > protocol mentioned above and the request/response protocol (actually, > more generically, a lookup protocol) mentioned below. It is good to see your ideas but doesn't this go beyond a charter discussion, as your are discussing a solution? This comes back to my initial comment about discussing a specific solution, and we haven't yet reached the times to discuss a solution - at least not here. Martin stiemerling@nw.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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Oct 13 08:03:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B962B3A6A3C; Mon, 13 Oct 2008 08:03:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2273D3A6A3C; Mon, 13 Oct 2008 08:03:02 -0700 (PDT) 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 gjqqBFIL4XtO; Mon, 13 Oct 2008 08:03:00 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 403A23A67F1; Mon, 13 Oct 2008 08:03:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EDA7D2C01918D; Mon, 13 Oct 2008 17:03:19 +0200 (CEST) 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 nvRhvgn0RHcH; Mon, 13 Oct 2008 17:03:19 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C1E7C2C000304; Mon, 13 Oct 2008 17:03:09 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 17:03:00 +0200 Message-ID: In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckqjtbBtBGZ4g7iSw6sF2KFPv5xZQCtViqA References: <20081006203532.B1D673A68AF@core3.amsl.com> From: "Jan Seedorf" To: Cc: p2pi@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I have been note-taker at the ALTO BoF in Dublin and I have been following the discussions on the mailing list since the BoF. I believe that the issues which prevented consensus during the ALTO BoF in Dublin have been discussed intensively on the mailing list and been resolved in the meantime. Thus, I support moving forward to a WG. - Jan > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of IESG Secretary > Sent: Monday, October 06, 2008 10:36 PM > To: IETF Announcement list > Cc: p2pi@ietf.org > Subject: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > A new IETF working group has been proposed in the > Applications Area. The IESG has not made any determination > as yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by Monday, > October 13, 2008. > > Application-Layer Traffic Optimization (alto) > ============================================= > Last Modified: 2008-09-29 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Applications Area Director(s): > > Lisa Dusseault (lisa at osafoundation.org) Chris Newman > (Chris.Newman at sun.com) > > Applications Area Advisor: > > Lisa Dusseault (lisa at osafoundation.org) > > Mailing List: > > General Discussion: p2pi at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi > Archive: http://www.ietf.org/pipermail/p2pi/ > > Description of Working Group: > > A significant part of the Internet traffic today is generated > by peer-to-peer (P2P) applications used for file sharing, > real-time communications, and live media streaming. P2P > applications exchange large amounts of data, often uploading > as much as downloading. In contrast to client/server > architectures, P2P applications often have a selection of > peers and must choose. > > One of the advantages of P2P systems comes from redundancy in > resource availability. This requires choosing among download > locations, yet applications have at best incomplete > information about the topology of the network. Applications > can sometimes make empirical measurements of link > performance, but even when this is an option it takes time. > The application cannot always start out with an optimal > arrangement of peers, thus causing at least temporary reduced > performance and excessive cross-domain traffic. Providing > more information for use in peer selection can improve P2P > performance and lower ISP costs. > > The Working Group will design and specify an > Application-Layer Traffic Optimization (ALTO) service that > will provide applications with information to perform > better-than-random initial peer selection. > ALTO services may take different approaches at balancing > factors including maximum bandwidth, minimum cross-domain > traffic, lowest cost to the user, etc. The WG will consider > the needs of BitTorrent, tracker-less P2P, and other > applications, such as content delivery networks (CDN) and > mirror selection. > > The WG will focus on the following items: > > - A "problem statement" document providing a description of the > problem and a common terminology. > > - A requirements document. This document will list > requirements for the ALTO service, identifying, for example, > what kind of information P2P applications will need for > optimizing their choices. > > - A request/response protocol for querying the ALTO service > to obtain information useful for peer selection, and a format > for requests and > responses. The WG does not require intermediaries between the ALTO > server and the peer querying it. If the requirements > analysis identifies the need to allow clients to delegate > third-parties to query the ALTO service on their behalf, the > WG will ensure that the protocol provides a mechanism to > assert the consent of the delegating client. > > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different > level of knowledge about the underlying network, such > preferences may have different representations. Initially the > WG will consider: IP ranges to prefer and to avoid, ranked > lists of the peers requested by the client, information about > topological proximity and approximate geographic locations. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > > - In order to query the ALTO server, clients must first know > one or more ALTO servers that might provide useful > information. The WG will look at service discovery > mechanisms that are in use, or defined elsewhere (e.g. > based on DNS SRV records or DHCP options). If such discovery > mechanisms can be reused, the WG will produce a document to > specify how they may be adopted for locating such servers. > However, a new, general-purpose service discovery mechanism > is not in scope. > > When the WG considers standardizing information that the ALTO > server could provide, the following criteria are important to > ensure real feasibility. > > - Can the ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that a client will find useful? > - Can a client get that information without excessive privacy concerns > (e.g. by sending large lists of peers)? > - Is it information that a client cannot find easily some other way? > > After these criteria are met, the generality of the data will > be considered for prioritizing standardization work, for > example the number of operators and clients that are likely > to be able to provide or use that particular data. In any > case, this WG will not propose standards on how congestion is > signaled, remediated, or avoided, and will not deal with > information representing instantaneous network state. > Such issues belong to other IETF areas and will be treated > accordingly by the specific area. > > This WG will focus solely on the communication protocol > between applications and ALTO servers. Note that ALTO > services may be useful in client-server environments as well > as P2P environments, although P2P environments are the first > focus. If, in the future, the IETF considers changes to > other protocols for actually implementing ALTO servers (e.g. > application-layer protocols for Internet coordinate systems, > routing protocol extensions for ISP-based solutions), such > work will be done in strict coordination with the appropriate WGs. > > Issues related to the content exchanged in P2P systems are > also excluded from the WG's scope, as is the issue dealing > with enforcing the legality of the content. > > Goals and Milestones (very tentative dates): > > Apr 2009: Working Group Last Call for problem statement Jun > 2009: Submit problem statement to IESG as Informational Aug > 2009: Working Group Last Call for requirements document Oct > 2009: Submit requirements document to IESG as Informational > Jan 2010: Working Group Last Call for request/response > protocol Jan 2010: Working Group Last Call for usage document > for communicating network preferences Mar 2010: Submit > request/response protocol to IESG as Proposed Standard Mar > 2010: Submit usage document to IESG as Proposed Standard May > 2010: Working Group Last Call of discovery mechanism Jul > 2010: Submit discovery mechanism to IESG as Proposed Standard > Aug 2010: Dissolve or re-charter > > Initial Drafts for Consideration > - draft-marocco-alto-problem-statement-02 -- > Application-Layer Traffic Optimization (ALTO) Problem Statement > - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization > (ALTO) Requirements > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Oct 13 08:07:41 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D5E3A6A3C; Mon, 13 Oct 2008 08:07:41 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C19C3A6802; Mon, 13 Oct 2008 08:07:40 -0700 (PDT) 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 6Jl+MrP2lLQ5; Mon, 13 Oct 2008 08:07:39 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8C19B3A67CC; Mon, 13 Oct 2008 08:07:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 83FC32C01918D; Mon, 13 Oct 2008 17:07:49 +0200 (CEST) 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 C6iIgLblqaQ1; Mon, 13 Oct 2008 17:07:49 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4ACD82C0012C2; Mon, 13 Oct 2008 17:07:24 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 17:07:23 +0200 Message-ID: In-Reply-To: <48EFD2BC.8050706@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckrJRzs7LhiR3/lTGmP1j9rr6vZcgCH7sjg References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it><48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> From: "Jan Seedorf" To: "Lakshminath Dondeti" , "Lisa Dusseault" Cc: p2pi@ietf.org, IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dear Lakshminath, > I left Dublin thinking, out of the p2pi efforts, TANA will be > a WG (there was strong consensus and agreement on the problem > space and what needs to be done) and ALTO may have another > BoF. As of today, there is a WG proposal on the table for > ALTO and in a different area from where we started; TANA is > on the BoF wiki. > > Next, my experiences in the past on BoFs that did not have > consensus have been dramatically different from what is > happening on ALTO. The IESG has really even refused to allow > another BoF much less directly started creating a working > group. So, it makes me wonder whether the rules have > recently been changed or whether they are selectively applied. I am not an IETF veteran, but from my experience it is perfectly ok for post-BoF discussions to happen on the mailing list and for these discussions to resolve some of the controversial issues at the BoF. I think this is was happened with ALTO. I also think that the IESG has been following the discussions on the mailing list and the WG Review is in fact a reaction to the agreement which has been found on the mailing list regarding the disagreements from the BoF. Just my two cents ... - Jan > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Lakshminath Dondeti > Sent: Saturday, October 11, 2008 12:10 AM > To: Lisa Dusseault > Cc: p2pi@ietf.org; IESG IESG; ietf@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > On 10/10/2008 12:21 PM, Lisa Dusseault wrote: > > Lakshminath and Vidya, > > > > Vijay, Enrico and Stefano have said what I was going to say (e.g. > > below) > > -- as sponsoring AD for this charter I've been following the WG > > discussion, working with the rest of the IESG, and talking > to people > > to confirm that there's better consensus on the list, even if there > > was confusion at the BOF. This IETF Last Call is also part of > > confirming whether there's now consensus. > > Hi Lisa, > > My concern can be put in really simple terms. We have some > really very confusing processes and we seem to add to the > confusion and not make things simpler. > > I left Dublin thinking, out of the p2pi efforts, TANA will be > a WG (there was strong consensus and agreement on the problem > space and what needs to be done) and ALTO may have another > BoF. As of today, there is a WG proposal on the table for > ALTO and in a different area from where we started; TANA is > on the BoF wiki. > > Next, my experiences in the past on BoFs that did not have > consensus have been dramatically different from what is > happening on ALTO. The IESG has really even refused to allow > another BoF much less directly started creating a working > group. So, it makes me wonder whether the rules have > recently been changed or whether they are selectively applied. > > I am also confused by your use of the word consensus; you say > that you've "talked to people" to confirm that there's > "better consensus on the list," but also say that the charter > review is also part of the consensus process. Shouldn't > there be a call for consensus? > > > > > It's difficult to write a charter without actually designing the > > solution. > > This is an interesting opinion. May I translate that to mean > that there > is already a solution in the minds of the people who wrote > the charter? > > Why then would we bother with the proposed requirements > effort, writing > down a problem statement and all the rest? Why not put an > RFC number on > the solution? > > It also makes me wonder what your opinion on the following from 2418. > > " - Is the proposed work plan an open IETF effort or is it an attempt > to "bless" non-IETF technology where the effect of > input from IETF > participants may be limited?" > > > What would help with the charter, even now, is for people to > > write up proposals for the solution -- ideally in the form of > > Internet-Drafts. > > This seems to be starkly different from the process I know > of. Are you > really suggesting that people come up with solutions to help with the > charter? What problem are we solving? What are the requirements? > Based on the proposal that was sent out, we won't have > consensus on all > of those until Oct 2009 or later. > > Apr 2009: Working Group Last Call for problem statement > Jun 2009: Submit problem statement to IESG as Informational > Aug 2009: Working Group Last Call for requirements document > Oct 2009: Submit requirements document to IESG as Informational > > > I haven't yet selected chairs for the WG, so as you > > can imagine editors and authors aren't yet selected. > > > It would be most > > excellent to see some individual proposals before a > committee gets their > > hands on them :) > > I am sorry Lisa, but I am really confused by your request for > proposals > before we even agree on the problem. I am hoping for a clarification. > > thanks, > Lakshminath > > > > > Lisa > > > > > > > > On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani > > > wrote: > > > > ... > > > > > > And since the BoF, much has changed to narrow the scope of the > > charter down to more manageable pieces as well as establish a > > channel with IRTF to move certain aspects of the work there > > (as the timeline in my previous email indicated.) > > > > Lakshminath Dondeti wrote: > > > > > > > > My perception and my understanding of some of the dissenting > > opinions > > was that some of those need to be worked out before > creating a > > working group. > > > > > > But I believe that we have done exactly that: the list has been > > busy since Dublin on attempts to move the work forward > in a manner > > that is conducive to all participants. > > > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Oct 13 08:48:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E513A6B11; Mon, 13 Oct 2008 08:48:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEF53A6B11; Mon, 13 Oct 2008 08:48:56 -0700 (PDT) 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=[AWL=0.000, 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 yZj2u7RpwXf1; Mon, 13 Oct 2008 08:48:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id AD4823A6AF4; Mon, 13 Oct 2008 08:48:54 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m9DFngQT025205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:49:42 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9DFnfNs022037; Mon, 13 Oct 2008 10:49:41 -0500 (CDT) Message-ID: <48F36E15.2000408@alcatel-lucent.com> Date: Mon, 13 Oct 2008 10:49:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: vidyan@qualcomm.com References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "p2pi@ietf.org" , IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Vidya: Thank you for your response and your time in helping define the work. More inline. Narayanan, Vidya wrote: > When we consider ALTO as a distributed service, there may not > necessarily be "a" host that specifically resolves the ALTO queries. > For instance, consider the case where ALTO is a service offered in > an overlay. There may be peers publishing information about > themselves on the overlay and other peers looking up such > information. These are not necessarily client-server style > communications. In fact, all that is important in this context is > that the overlay acts as a rendezvous for sharing such information. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. > I'm afraid that would be a mistake. It actually doesn't matter if we > don't agree today on the exact types of information that can be > shared. It is important that we have a protocol that allows peers to > publish ALTO related information. Having this protocol be > extensible would allow for any type of information to be carried in > it. So far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) > Actually, I am saying that is exactly what is not needed. I don't > see the information types as something this effort will necessarily > nail down. I am confused; I thought earlier you were trying to make the case that ALTO should provide even more specific information that needs to be published? In the end, we do agree on that any protocol be extensible. Whether that is extensible through a registry-like mechanism or other means remains to be discussed in the WG, right? > I would like us to think beyond applications we see today. Had TCP > not been designed that way, we probably would have needed a redesign > of it for HTTP :) Protocols evolve, networks evolve. I am sure we were prescient when we designed TCP such that HTTP could simply use it. However, other realities of evolution did force us to design SCTP, for instance. But regardless, the point is that we should be general, and we are; but we have to do this while drawing a fine line between research and engineering. Some applications that are appearing on the horizon are streaming media and P2PTV; for these we have opened up channels with IRTF. So I don't see where we are constraining ourselves in ALTO. > I can envision video applications using the P2PSIP framework, for > instance. Yes, and as I wrote earlier, they can use ALTO to discover the the peer they find optimal within their constraints and use it. > In any event, I still don't have a good understanding of what it > means to consider the needs of these various things - what does it > mean to say that we'll consider the needs of BitTorrent/CDN, etc.? > Could you maybe give me an example of what it means? Look at the Ono work, which is a plug-in to BitTorrent. It uses Akamai redirections to find the closest peer to download content from. In a sense, ALTO is replacing that ad-hoc lookup and providing a much more deterministic answer. That is what we mean by the needs of "BitTorrent/CDN etc." > What I am saying is that it is not for us to determine the usefulness > of a particular piece of information. As long as the peers or > service providers are willing to share a piece of information, that > can be consumed by other peers as they deem fit. So, I don't think > we should consider ourselves the gatekeeper for the types of > information shared. But we are not. As I made the point earlier, ALTO is not out to replace BitTorrent. So replicating in ALTO the details about peers that BitTorrent already has is counter-productive. Instead, ALTO can focus on providing the pieces that BitTorrent does not: topology, policy, etc. That is where we will make a difference. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 01:29:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A3F3A6ABA; Tue, 14 Oct 2008 01:29:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A363A6A11; Tue, 14 Oct 2008 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 41dQagUMMHAl; Tue, 14 Oct 2008 01:29:25 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 430D23A6936; Tue, 14 Oct 2008 01:29:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P0017GZL2DD@szxga02-in.huawei.com>; Tue, 14 Oct 2008 16:29:27 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00EIYZL2LL@szxga02-in.huawei.com>; Tue, 14 Oct 2008 16:29:26 +0800 (CST) Received: from s64081 ([10.164.12.37]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8P00AOGZL2C2@szxml05-in.huawei.com>; Tue, 14 Oct 2008 16:29:26 +0800 (CST) Date: Tue, 14 Oct 2008 16:29:30 +0800 From: Song Haibin In-reply-to: <48F36E15.2000408@alcatel-lucent.com> To: "'Vijay K. Gurbani'" , vidyan@qualcomm.com Message-id: <005401c92dd6$fafbff80$250ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcktS08fvjdzLHQrQc2p10LG53ipqQAicAwQ Cc: p2pi@ietf.org, 'IESG IESG' , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vijay, >Narayanan, Vidya wrote: >> communications. In fact, all that is important in this context is >> that the overlay acts as a rendezvous for sharing such information. > >I think the disconnect we may be having is that you view >ALTO as a peer description protocol; it is not. Other >protocols like BitTorrent, for example, are more suited to >this, and they do exactly what you want. In a BitTorrent >overlay (swarm), the overlay knows exactly which peer is >contributing which content, which peer has which chunks, >the download/upload ratio, the time the peer joined the swarm, >whether the peer is choked or unchoked, whether the peer has >a public port, etc. ALTO is not out to replace BitTorrent. What >ALTO is providing are better strategies for peer selection. > >For instance, it is not ALTO that gets to decide which peer is >hosting which content and what the contributions of that peer >to the overlay are. However, it is ALTO's job to provide >information to a querying peer allowing it to determine wisely >where it will download the content from. Totally agree. >> I'm afraid that would be a mistake. It actually doesn't matter if we >> don't agree today on the exact types of information that can be >> shared. It is important that we have a protocol that allows peers to >> publish ALTO related information. Having this protocol be >> extensible would allow for any type of information to be carried in >> it. > >So far, no one on the list has proposed that ALTO be a peer >description and publication protocol. So based on the discussion >we have had since (essentially the workshop in) May 2008 on the >p2pi list, I would hesitate to add in the charter something that >participants have not expressed any preference for (i.e., a >deliverable on peers publishing their information.) IMHO, not every type of information can be carried in the ALTO protocol, but only network policy and topology related (e.g. peer preference) information is allowed. I don't think we are designing BitTorrent here. Regards! Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 07:36:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33FE3A6B36; Tue, 14 Oct 2008 07:36:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AA43A6B2F; Tue, 14 Oct 2008 07:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 1Zy8zdlptSxE; Tue, 14 Oct 2008 07:36:20 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 5727C3A659A; Tue, 14 Oct 2008 07:36:19 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9EEb7ug052911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 17:37:08 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <1140F101-0D0C-4586-880C-EA486A52781A@nokia.com> From: Lars Eggert To: ext Marshall Eubanks In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 17:37:07 +0300 References: <20081006203532.B1D673A68AF@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8423/Tue Oct 14 15:36:14 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 14 Oct 2008 17:37:14 +0300 (EEST) Cc: p2pi@ietf.org, iesg@ietf.org, IETF Discussion Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-10-10, at 15:00, ext Marshall Eubanks wrote: >> considered for prioritizing standardization work, for example the >> number of operators and clients that are likely to be able to provide >> or use that particular data. In any case, this WG will not propose >> standards on how congestion is signaled, remediated, or avoided, and > > Does this mean that congestion is not an issue to consider ? > > If the closest peer to me was totally congested and had no available > bandwidth, isn't that something that I would want to know ? I think the intent here is actually fine. ALTO attempts to improve the initial peer selection over simply choosing peers randomly by making some information available before this selection happens. The information provided through ALTO can't - in my opinion - include very detailed or timely load or congestion information, because I remain unconvinced that the ALTO system could actually obtain and maintain this information on the timescales it would need to. But there's other information that could be useful, such as some coarse-grained "this peer is not totally on the other side of the planet"-like information. Assuming that throughput and distance are by and large inversely proportional, preferring closer peers should often be better than choosing totally randomly. Other kinds of useful information could be "talking to this peer doesn't count towards your bandwidth quota", etc. Now, once you actually establish and use a transport connection with the ALTO-recommended peer, you may well find that throughput is low. So you ditch the peer and try another one, which P2P systems already do. The intent here isn't that ALTO would pick the globally optimal peers for you, the intent is that it'll help an application reach a good set of peers a bit more quickly. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 07:40:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E84828C1DD; Tue, 14 Oct 2008 07:40:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1002728C1DD; Tue, 14 Oct 2008 07:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 FY40hBdZLYR5; Tue, 14 Oct 2008 07:39:58 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 9F0DE3A659A; Tue, 14 Oct 2008 07:39:57 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9EEejUd052921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 17:40:46 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> From: Lars Eggert To: ext Enrico Marocco In-Reply-To: <48F000FD.5000302@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 17:40:45 +0300 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8423/Tue Oct 14 15:36:14 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 14 Oct 2008 17:40:52 +0300 (EEST) Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 2008-10-11, at 4:27, ext Enrico Marocco wrote: > Lakshminath Dondeti wrote: >>> It's difficult to write a charter without actually designing the >>> solution. >> >> This is an interesting opinion. May I translate that to mean that >> there >> is already a solution in the minds of the people who wrote the >> charter? > > Nope. Who has been following the p2pi list for the last five months > probably knows that there are three different approaches (solutions?) > floating around: the "sorting oracle" (described in a SIGCOMM paper > authored by folks from TU-Berlin, a variant of which is IDIPS), P4P > (soon to be published as I-D and, IIRC, described in another SIGCOMM > paper), and Stanislav's proposal (discussed in Dublin and on the list: > http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who > wrote the charter had all those approaches clear in mind and took > special care that none of them got ruled out. FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html ). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No "ALTO boxes" needed. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 07:48:14 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0FD28C1DD; Tue, 14 Oct 2008 07:48:14 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC4F28C1DD; Tue, 14 Oct 2008 07:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 z1OKE6jdFPD0; Tue, 14 Oct 2008 07:48:11 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 87EE028C11A; Tue, 14 Oct 2008 07:48:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 598AEE10B62; Tue, 14 Oct 2008 10:48:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH+RvH1WpNch; Tue, 14 Oct 2008 10:48:01 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1B2E0E10B2A; Tue, 14 Oct 2008 10:48:01 -0400 (EDT) Date: Tue, 14 Oct 2008 10:48:01 -0400 (EDT) From: Laird Popkin To: Song Haibin Message-ID: <889695024.364101223995681087.JavaMail.root@dkny.pando.com> In-Reply-To: <005401c92dd6$fafbff80$250ca40a@china.huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org, IESG IESG , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'd like to second this, and also make sure that the relationship between ALTO and the application is clear. >From the application perspective, ALTO is a source of useful guidance (i.e. network topology and "cost" model) that can help the p2p network find good peers to connect. But once peers are exchanging data, the p2p network/protocol (and TCP) pretty much takes over, because those protocols address the actual throughput between peers, real-time congestion, etc., that are not addressed by ALTO. I should also make clear that ALTO does not (and cannot) control the p2p network. Generally ALTO guidance should provide better than average peer connections (which is certainly what we saw in the P4P field tests), so the p2p networks will be motivated to use ALTO guidance when they can because it's in their interests to do so. But there will always be cases that are exceptions. For example, if a p2p network is getting fantastic data delivery between two peers, it is highly likely to keep using that connection no matter what ALTO says. And, on the flip side, if the ALTO-recommended peer connections aren't providing the data needed, the p2p network will use other peers as data sources. And, of course, p2p networks must continue to operate where ALTO guidance is unavailable. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Song Haibin" To: "Vijay K. Gurbani" , vidyan@qualcomm.com Cc: p2pi@ietf.org, "IESG IESG" , ietf@ietf.org Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Hi Vijay, >Narayanan, Vidya wrote: >> communications. In fact, all that is important in this context is >> that the overlay acts as a rendezvous for sharing such information. > >I think the disconnect we may be having is that you view >ALTO as a peer description protocol; it is not. Other >protocols like BitTorrent, for example, are more suited to >this, and they do exactly what you want. In a BitTorrent >overlay (swarm), the overlay knows exactly which peer is >contributing which content, which peer has which chunks, >the download/upload ratio, the time the peer joined the swarm, >whether the peer is choked or unchoked, whether the peer has >a public port, etc. ALTO is not out to replace BitTorrent. What >ALTO is providing are better strategies for peer selection. > >For instance, it is not ALTO that gets to decide which peer is >hosting which content and what the contributions of that peer >to the overlay are. However, it is ALTO's job to provide >information to a querying peer allowing it to determine wisely >where it will download the content from. Totally agree. >> I'm afraid that would be a mistake. It actually doesn't matter if we >> don't agree today on the exact types of information that can be >> shared. It is important that we have a protocol that allows peers to >> publish ALTO related information. Having this protocol be >> extensible would allow for any type of information to be carried in >> it. > >So far, no one on the list has proposed that ALTO be a peer >description and publication protocol. So based on the discussion >we have had since (essentially the workshop in) May 2008 on the >p2pi list, I would hesitate to add in the charter something that >participants have not expressed any preference for (i.e., a >deliverable on peers publishing their information.) IMHO, not every type of information can be carried in the ALTO protocol, but only network policy and topology related (e.g. peer preference) information is allowed. I don't think we are designing BitTorrent here. Regards! Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 07:57:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2FC3A6B2E; Tue, 14 Oct 2008 07:57:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0D13A6B2E; Tue, 14 Oct 2008 07:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.404 X-Spam-Level: X-Spam-Status: No, score=-5.404 tagged_above=-999 required=5 tests=[AWL=1.195, BAYES_00=-2.599, 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 lHDV9vDW1n1D; Tue, 14 Oct 2008 07:57:39 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1ED6B3A659A; Tue, 14 Oct 2008 07:57:39 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9EEtwM2012508; Tue, 14 Oct 2008 07:55:58 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Lars Eggert In-Reply-To: <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 07:55:57 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> X-Mailer: Apple Mail (2.929.2) Cc: "p2pi@ietf.org" , Nicholas Weaver , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: > > FYI, there's at least one more proposal in this space: the Ono stuff > from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html > ). There was a paper at SIGCOMM this year, and their system has the > interesting feature that it simply freeloads of Akamai's DNS entries > in order to determine who's close to whom. No "ALTO boxes" needed. Basically, this is freeloading on the akamai DNS infrastructure to create a "topology oracle": which nodes are close in terms of network topology as a common proxy for bandwidth. It doesn't need "ALTO boxes" only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure. However, it does bring up a good point: DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 13:07:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F3B3A6B31; Tue, 14 Oct 2008 13:07:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF143A6B31 for ; Tue, 14 Oct 2008 13:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 nhat3j3iMx1i for ; Tue, 14 Oct 2008 13:07:39 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 076AB3A6B2C for ; Tue, 14 Oct 2008 13:07:38 -0700 (PDT) Received: by gxk9 with SMTP id 9so5809417gxk.13 for ; Tue, 14 Oct 2008 13:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=K0VCXhKXJzwdGiGZlvZSo5EoHbHv9M0t1f3gSP4+ZF8=; b=NDk1yxvjVn1jN+Pn7i7BnhSpjj4Z2lvg+5LhHo+QXjfHvlaUm3dSLxIt1e0gKT6sCj ChbOKXFvrQcObtTG8MAheesubokH6qlsowlN+3nMkRnrFXdD7Y4ZAbI/+Fc5tphng1JX m1VgmoNwfS4eoCx5aqGKe3L9H7g5gQw2zUORw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=YUG7xLoBBrEyHqg3aO2o8HiqXuAIvGC6to5pwETOYyVEXJZ2WmcV3Vnluab289sEvM IshM5TYMpMpAD28AP+88aHy2gvpURFeyhZcGRDbcn0LK+LRy4ASDTRmbPP3AYw0PDAHI KG1zPlnRUQdiNBMq3le8DkCMMD3MuCBPLai/E= Received: by 10.102.228.10 with SMTP id a10mr57334muh.109.1224014844667; Tue, 14 Oct 2008 13:07:24 -0700 (PDT) Received: by 10.103.52.9 with HTTP; Tue, 14 Oct 2008 13:07:24 -0700 (PDT) Message-ID: <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com> Date: Tue, 14 Oct 2008 16:07:24 -0400 From: "Ye WANG" To: p2pi@ietf.org In-Reply-To: MIME-Version: 1.0 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> Cc: IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088147335==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0088147335== Content-Type: multipart/alternative; boundary="----=_Part_13018_31046875.1224014844638" ------=_Part_13018_31046875.1224014844638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver wrote: > > On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: > >> >> FYI, there's at least one more proposal in this space: the Ono stuff from >> Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). >> There was a paper at SIGCOMM this year, and their system has the interesting >> feature that it simply freeloads of Akamai's DNS entries in order to >> determine who's close to whom. No "ALTO boxes" needed. >> > > Basically, this is freeloading on the akamai DNS infrastructure to create a > "topology oracle": which nodes are close in terms of network topology as a > common proxy for bandwidth. > > It doesn't need "ALTO boxes" only because someone else has colleced that > information, and that there is a separation between the query replying > infrastructure (through DNS) and the measurement infrastructure. > > However, it does bring up a good point: DNS games allow the ability to > divorce the measurement infrastructure from the reporting infrastructure, > and to create a reporting infrastructure that can always work both with and > without ISP cooperation. This is a very good comment on the architecture on "ALTO box". Just to clarify on a risk of building an Internet infrastructure based on a hack of using the Akamai DNS infrastructure to create a "topology oracle". You may already know it, but some others may not. So I would like to point it out. Akamai DNS redirection considers not only topology, but also Akamai's own server state, and Akamai's own redirection policy. To illustrate this, consider a simple example where Akamai temporarily (e.g., during maintenance, or misconfiguration, or under attack, or whatever reason) redirects users from distant geographic locations to the same set of servers. This may result in these users being deemed "close together" when in fact they are not. This is not limited to Akamai. DNS redirection typically considers not only topology, but also the state and policy of whoever controls it. > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_13018_31046875.1224014844638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote:

FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No "ALTO boxes" needed.

Basically, this is freeloading on the akamai DNS infrastructure to create a "topology oracle": which nodes are close in terms of network topology as a common proxy for bandwidth.

It doesn't need "ALTO boxes" only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure.

However, it does bring up a good point:  DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation.

This is a very good comment on the architecture on "ALTO box".   Just to
clarify on a risk of building an Internet infrastructure based on a hack of
using the Akamai DNS infrastructure to create a "topology oracle".
You may already know it, but some others may not. So I would like to
point it out.

Akamai DNS redirection considers not only topology, but also Akamai's own
server state, and Akamai's own redirection policy.  To illustrate this,
consider a simple example where Akamai temporarily (e.g., during maintenance,
or misconfiguration, or under attack, or whatever reason) redirects users
from distant geographic locations to the same set of servers. This may result
in these users being deemed "close together" when in fact they are not.

This is not limited to Akamai. DNS redirection typically considers not
only topology, but also the state and policy of whoever controls it.



_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

------=_Part_13018_31046875.1224014844638-- --===============0088147335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0088147335==-- From p2pi-bounces@ietf.org Tue Oct 14 15:05:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADC23A6C26; Tue, 14 Oct 2008 15:05:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC8A3A6C11; Tue, 14 Oct 2008 15:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pvM3RO-3IfLm; Tue, 14 Oct 2008 15:05:03 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2E48D3A6BBB; Tue, 14 Oct 2008 15:05:03 -0700 (PDT) Received: from dnab4222f5.stanford.edu ([171.66.34.245]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Kps1g-0004mY-5k; Tue, 14 Oct 2008 15:06:00 -0700 Message-Id: <25551223-3B5A-419D-A514-037B8C7E7391@cs.stanford.edu> From: Philip Levis To: Ye WANG In-Reply-To: <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 15:05:58 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 2c21b60125577a2cbf52524016395bed Cc: p2pi@ietf.org, IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 14, 2008, at 1:07 PM, Ye WANG wrote: > On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver > wrote: > > On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: > > FYI, there's at least one more proposal in this space: the Ono stuff > from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html > ). There was a paper at SIGCOMM this year, and their system has the > interesting feature that it simply freeloads of Akamai's DNS entries > in order to determine who's close to whom. No "ALTO boxes" needed. > > Basically, this is freeloading on the akamai DNS infrastructure to > create a "topology oracle": which nodes are close in terms of > network topology as a common proxy for bandwidth. > > It doesn't need "ALTO boxes" only because someone else has colleced > that information, and that there is a separation between the query > replying infrastructure (through DNS) and the measurement > infrastructure. > > However, it does bring up a good point: DNS games allow the ability > to divorce the measurement infrastructure from the reporting > infrastructure, and to create a reporting infrastructure that can > always work both with and without ISP cooperation. > > This is a very good comment on the architecture on "ALTO box". > Just to > clarify on a risk of building an Internet infrastructure based on a > hack of > using the Akamai DNS infrastructure to create a "topology oracle". > You may already know it, but some others may not. So I would like to > point it out. > > Akamai DNS redirection considers not only topology, but also > Akamai's own > server state, and Akamai's own redirection policy. To illustrate > this, > consider a simple example where Akamai temporarily (e.g., during > maintenance, > or misconfiguration, or under attack, or whatever reason) redirects > users > from distant geographic locations to the same set of servers. This > may result > in these users being deemed "close together" when in fact they are > not. > > This is not limited to Akamai. DNS redirection typically considers not > only topology, but also the state and policy of whoever controls it. > To be fair, I don't think anyone was recommending Ono, merely noting it was one that has been proposed and so should be included in the list. While a cute systems hack that might make something work better today, it's pretty clearly not a good interoperable and long-term solution. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 17:08:57 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7EF3A6878; Tue, 14 Oct 2008 17:08:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDF13A6765; Tue, 14 Oct 2008 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.368 X-Spam-Level: X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, 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 Mxb+ulzsSkvr; Tue, 14 Oct 2008 17:08:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 815E23A6784; Tue, 14 Oct 2008 17:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224029392; x=1255565392; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Martin=20Stiemerling=20,=0D =0A=20=20=20=20=20=20=20=20"Vijay=20K.=20Gurbani"=0D=0A =09|CC:=20"p2pi@ietf.org"=20,=20IESG=20IESG=20,=0D=0A=20=20 =20=20=20=20=20=20"ietf@ietf.org"=20|Date: =20Tue,=2014=20Oct=202008=2017:09:49=20-0700|Subject:=20R E:=20[p2pi]=20WG=20Review:=20Application-Layer=20Traffic =20Optimization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Re view:=20Application-Layer=20Traffic=20Optimization=20(alt o)|Thread-Index:=20AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qwAI wwruAAOrX48A=3D=3D|Message-ID:=20 |References:=20<20081006203532.B1D673A68AF@core3.amsl.com ><48EFA1B7.7010508@alcatel-lucent.com>=0D=0A =20=0D=0A=20<547F018265F92642B577B986577D671 C3DF92C@VENUS.office>|In-Reply-To:=20<547F018265F92642B57 7B986577D671C3DF92C@VENUS.office>|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5405"=3B=20a=3D"10888453"; bh=YSzut+m+1iWPWRx9e+duBhJoFm4RN8RYXFwekKZ0nAc=; b=by66SRVTVtWbVizwpmkpb6jtuPqJvuqhvedpAeFrpBIV/ZbjJpJtTfD7 U3D13eBJeOLZyW/9+Uq+6Kt7PW/mW6KrRCysPoWH3qySNs+ef77mzpYEs EURty5e3o2XalhezXRr62l92I0GqwYIjtkScesLXWZeThALi1Q6mcVKhr s=; X-IronPort-AV: E=McAfee;i="5300,2777,5405"; a="10888453" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2008 17:09:52 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9F09pdx011861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 17:09:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9F09oUp001954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2008 17:09:51 -0700 Received: from nasanexhub06.na.qualcomm.com (129.46.134.254) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 17:09:50 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 17:09:50 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 14 Oct 2008 17:09:49 -0700 From: "Narayanan, Vidya" To: Martin Stiemerling , "Vijay K. Gurbani" Date: Tue, 14 Oct 2008 17:09:49 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qwAIwwruAAOrX48A== Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com> <547F018265F92642B577B986577D671C3DF92C@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C3DF92C@VENUS.office> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Martin, Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't. At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers. Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable. We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests. Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture. Thanks, Vidya > -----Original Message----- > From: Martin Stiemerling [mailto:Stiemerling@nw.neclab.eu] > Sent: Monday, October 13, 2008 8:03 AM > To: Narayanan, Vidya; Vijay K. Gurbani > Cc: p2pi@ietf.org; IESG IESG; ietf@ietf.org > Subject: RE: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Hi Vidja, all, > > I believe that the charter is narrow and broad enough to > cover the topic of ALTO, i.e., the charter is not limiting > the solution space. > > However, when reading your comments, it sounds that you have > a very specific solution in mind which is probably not > covered by the current charter. > > [...] > > > > > > > > Overall, I think we should work with the notion of an ALTO > > "service" > > > > rather than specifically an ALTO "server". > > > > > > Great. I believe that is exactly what the charter does; the > > > charter talks in terms of an "ALTO service" at many places > > > (pedantically speaking, the term "ALTO service" occurs > eight times > > > and the term "ALTO server" occurs six.) The ALTO "server" > > > mentioned in the charter refers to the *host* the client finally > > > queries (calling it a "peer" is ambiguous; if you have a specific > > > term to use here instead of "server", please do let us know.) > > > > > > > When we consider ALTO as a distributed service, there may not > > necessarily be "a" host that specifically resolves the ALTO queries. > > For instance, consider the case where ALTO is a service > offered in an > > overlay. There may be peers publishing information about > themselves > > on the overlay and other peers looking up such information. > These are > > not necessarily client-server style communications. In > fact, all that > > is important in this context is that the overlay acts as a > rendezvous > > for sharing such information. Now, of course, that is one > possible model. > > You probably have a publish/subscribe system in mind for p2p overlays. > I assume this is not in scope of ALTO. > > > But, in order to allow for that and other models, I do want the > > charter to keep the focus on the service and not on a server. > > Is the IETF anyhow standardizing services? I don't see this. > > [...] > > > > > > > > We have had discussions on the mailing list about this already. > > > Some people felt that providing uplink bandwidth would > not be a good > > > idea for various reasons running from privacy concerns to peers > > > skewing traffic in favor of a high uplink bandwidth. > > > Others felt that even if a peers uplink bandwidth was not > provided, > > > it could calculated nonetheless by other peers. > > > That is, there are degrees of disagreement here and consequently, > > > including a contentious point in the charter would be counter- > > > productive. > > > > > > > I'm afraid that would be a mistake. It actually doesn't > matter if we > > I'm afraid that carrying up/downlink capacity of the peer's > local link is a complete waste of resource, as this is not > indicating something. For instance, a peer may have a > relatively huge uplink but on a shared medium, i.e., a medium > which might be shared by hundreds of other hosts/traffic. > So what does this information express? > > > don't agree today on the exact types of information that > can be shared. > > It is important that we have a protocol that allows peers > to publish > > ALTO related information. Having this protocol be extensible would > > allow for any type of information to be carried in it. So, > I strongly > > The question is, whether the roots of ALTO are actually > intended to carry any type of information? The main idea is > to carry information to optimize traffic, e.g., decreasing > cross ISP traffic. > > > believe we don't need a recharter to consider any > information types - > > in fact, I'd be okay if this effort only took on the > protocol and if > > all information types were to be registered through other > means. That > > said, I'm not against taking on some subset of those types > - I don't > > believe that should be the core focus of this work though. > > > > > > - The ability to register information types with IANA > and extend > > > > these. > > > > > > Having a IANA registry for the information type carried in the > > > protocol is certainly a possibility the charter does not > rule out, > > > no? > > > > > > > Well, it is a bit hard to say what the charter does not rule out - > > typically we try and do what the charter says we should do. > However, > > before we get to the registry, we need to agree on the protocol > > components. In my view, there are two such components - > the publish > > protocol mentioned above and the request/response protocol > (actually, > > more generically, a lookup protocol) mentioned below. > > It is good to see your ideas but doesn't this go beyond a > charter discussion, as your are discussing a solution? > > This comes back to my initial comment about discussing a > specific solution, and we haven't yet reached the times to > discuss a solution - at least not here. > > Martin > > > stiemerling@nw.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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 18:06:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522273A685C; Tue, 14 Oct 2008 18:06:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0009E3A6A8E; Tue, 14 Oct 2008 18:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 q8EFsL2ul3Kb; Tue, 14 Oct 2008 18:06:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B51F73A67C0; Tue, 14 Oct 2008 18:06:43 -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 <0K8R00LHW9SQQF@szxga01-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R00ITU9SQN2@szxga01-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +0800 (CST) Received: from s64081 ([10.164.12.37]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8R00LAR9SPE2@szxml05-in.huawei.com>; Wed, 15 Oct 2008 09:07:38 +0800 (CST) Date: Wed, 15 Oct 2008 09:07:37 +0800 From: Song Haibin In-reply-to: <889695024.364101223995681087.JavaMail.root@dkny.pando.com> To: 'Laird Popkin' Message-id: <008501c92e62$6a644a40$250ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckuDR/QVdQVuCJUROi4xWSX61IkHAAVRonw Cc: p2pi@ietf.org, 'IESG IESG' , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >-----Original Message----- >From: Laird Popkin [mailto:laird@pando.com] >Sent: Tuesday, October 14, 2008 10:48 PM >To: Song Haibin >Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > >I'd like to second this, and also make sure that the relationship between ALTO >and the application is clear. > >From the application perspective, ALTO is a source of useful guidance (i.e. >network topology and "cost" model) that can help the p2p network find good peers >to connect. But once peers are exchanging data, the p2p network/protocol (and >TCP) pretty much takes over, because those protocols address the actual >throughput between peers, real-time congestion, etc., that are not addressed >by ALTO. > >I should also make clear that ALTO does not (and cannot) control the p2p network. >Generally ALTO guidance should provide better than average peer connections >(which is certainly what we saw in the P4P field tests), so the p2p networks >will be motivated to use ALTO guidance when they can because it's in their >interests to do so. But there will always be cases that are exceptions. For >example, if a p2p network is getting fantastic data delivery between two peers, >it is highly likely to keep using that connection no matter what ALTO says. And, >on the flip side, if the ALTO-recommended peer connections aren't providing the >data needed, the p2p network will use other peers as data sources. And, of course, >p2p networks must continue to operate where ALTO guidance is unavailable. :-) Yes, actually I have the same thought with you. BR Song Haibin >- Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > >----- Original Message ----- >From: "Song Haibin" >To: "Vijay K. Gurbani" , vidyan@qualcomm.com >Cc: p2pi@ietf.org, "IESG IESG" , ietf@ietf.org >Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York >Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) > >Hi Vijay, > >>Narayanan, Vidya wrote: >>> communications. In fact, all that is important in this context is >>> that the overlay acts as a rendezvous for sharing such information. >> >>I think the disconnect we may be having is that you view >>ALTO as a peer description protocol; it is not. Other >>protocols like BitTorrent, for example, are more suited to >>this, and they do exactly what you want. In a BitTorrent >>overlay (swarm), the overlay knows exactly which peer is >>contributing which content, which peer has which chunks, >>the download/upload ratio, the time the peer joined the swarm, >>whether the peer is choked or unchoked, whether the peer has >>a public port, etc. ALTO is not out to replace BitTorrent. What >>ALTO is providing are better strategies for peer selection. >> >>For instance, it is not ALTO that gets to decide which peer is >>hosting which content and what the contributions of that peer >>to the overlay are. However, it is ALTO's job to provide >>information to a querying peer allowing it to determine wisely >>where it will download the content from. > >Totally agree. > >>> I'm afraid that would be a mistake. It actually doesn't matter if we >>> don't agree today on the exact types of information that can be >>> shared. It is important that we have a protocol that allows peers to >>> publish ALTO related information. Having this protocol be >>> extensible would allow for any type of information to be carried in >>> it. >> >>So far, no one on the list has proposed that ALTO be a peer >>description and publication protocol. So based on the discussion >>we have had since (essentially the workshop in) May 2008 on the >>p2pi list, I would hesitate to add in the charter something that >>participants have not expressed any preference for (i.e., a >>deliverable on peers publishing their information.) > >IMHO, not every type of information can be carried in the ALTO protocol, but >only network policy and topology related (e.g. peer preference) information >is allowed. I don't think we are designing BitTorrent here. > >Regards! >Song Haibin > > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 14 22:46:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FDE3A6C48; Tue, 14 Oct 2008 22:46:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3FB3A6AA6; Tue, 14 Oct 2008 22:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.313 X-Spam-Level: X-Spam-Status: No, score=-105.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 w6sQ68yzOsxH; Tue, 14 Oct 2008 22:46:18 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9E5943A67EC; Tue, 14 Oct 2008 22:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224049637; x=1255585637; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Vijay=20K.=20Gurbani"=20|CC: =20IESG=20IESG=20,=20"ietf@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"p2pi@ietf.org "=20|Date:=20Tue,=2014=20Oct=202008=2022:4 7:10=20-0700|Subject:=20RE:=20[p2pi]=20WG=20Review:=20App lication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20[p2pi]=20WG=20Review:=20Application-Laye r=20Traffic=20Optimization=20(alto)|Thread-Index:=20AcktS 12p8CNpD/NcSNOhfnjH2AP+0wBOMgPw|Message-ID:=20|References:=20<20081006203532.B1D673A68AF@core3.amsl.c om>=0D=0A=20=0D=0A=20<48EFA1B7.7010508@alcat el-lucent.com>=0D=0A=20=0D=0A=20<48F36E15.20 00408@alcatel-lucent.com>|In-Reply-To:=20<48F36E15.200040 8@alcatel-lucent.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5405"=3B=20a=3D"10972222"; bh=EDPIyatAI7z6MAq5sLT0Ek7k2wxhQ70OxSAQcNxNd/o=; b=fRhcvPXbvVt3obSh4oGnMGOO+MWqFik8nWfdUohevkfZmd/+LaEDn0Jw ACPxG7H1dxlTxX/1hWDOrzq+fV27mmm7N2kxbBbbrsM2fu31MkDKwLu76 vrKoIjzW6CZ6Axp0l4XrrrUpeFgbQwYUsVdqjmYuV3cFe0/it4jl/5kJQ s=; X-IronPort-AV: E=McAfee;i="5300,2777,5405"; a="10972222" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2008 22:47:14 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9F5lEvO014440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 22:47:14 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9F5lDBE019813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Oct 2008 22:47:14 -0700 Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 22:47:13 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 22:47:13 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Tue, 14 Oct 2008 22:47:13 -0700 From: "Narayanan, Vidya" To: "Vijay K. Gurbani" Date: Tue, 14 Oct 2008 22:47:10 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AcktS12p8CNpD/NcSNOhfnjH2AP+0wBOMgPw Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> <48F36E15.2000408@alcatel-lucent.com> In-Reply-To: <48F36E15.2000408@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vijay, I am not at all talking about reinventing what BitTorrent can do or even remotely about any actual p2p application itself. I am only talking about peer selection. However, I think there is a critical difference between what I view as contributing to peer selection and what the current proposed charter does. Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. This functionality itself is application agnostic and requires an interoperable solution for it to be beneficial. This has nothing to do with content itself; it is purely about sharing information that helps with peer selection. Lastly, as long as this framework is made available, information can be shared among peers on an overlay in a distributed fashion and/or provided by a service provider host. Best regards, Vidya > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Monday, October 13, 2008 8:50 AM > To: Narayanan, Vidya > Cc: IESG IESG; ietf@ietf.org; p2pi@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Vidya: Thank you for your response and your time in helping > define the work. More inline. > > Narayanan, Vidya wrote: > > When we consider ALTO as a distributed service, there may not > > necessarily be "a" host that specifically resolves the ALTO queries. > > For instance, consider the case where ALTO is a service > offered in an > > overlay. There may be peers publishing information about > themselves > > on the overlay and other peers looking up such information. > These are > > not necessarily client-server style communications. In > fact, all that > > is important in this context is that the overlay acts as a > rendezvous > > for sharing such information. > > I think the disconnect we may be having is that you view ALTO > as a peer description protocol; it is not. Other protocols > like BitTorrent, for example, are more suited to this, and > they do exactly what you want. In a BitTorrent overlay > (swarm), the overlay knows exactly which peer is contributing > which content, which peer has which chunks, the > download/upload ratio, the time the peer joined the swarm, > whether the peer is choked or unchoked, whether the peer has > a public port, etc. ALTO is not out to replace BitTorrent. > What ALTO is providing are better strategies for peer selection. > > For instance, it is not ALTO that gets to decide which peer > is hosting which content and what the contributions of that > peer to the overlay are. However, it is ALTO's job to > provide information to a querying peer allowing it to > determine wisely where it will download the content from. > > > I'm afraid that would be a mistake. It actually doesn't > matter if we > > don't agree today on the exact types of information that can be > > shared. It is important that we have a protocol that > allows peers to > > publish ALTO related information. Having this protocol be > extensible > > would allow for any type of information to be carried in it. > > So far, no one on the list has proposed that ALTO be a peer > description and publication protocol. So based on the > discussion we have had since (essentially the workshop in) > May 2008 on the p2pi list, I would hesitate to add in the > charter something that participants have not expressed any > preference for (i.e., a deliverable on peers publishing their > information.) > > > Actually, I am saying that is exactly what is not needed. > I don't see > > the information types as something this effort will > necessarily nail > > down. > > I am confused; I thought earlier you were trying to make the > case that ALTO should provide even more specific information > that needs to be published? > > In the end, we do agree on that any protocol be extensible. > Whether that is extensible through a registry-like mechanism > or other means remains to be discussed in the WG, right? > > > I would like us to think beyond applications we see today. > Had TCP not > > been designed that way, we probably would have needed a > redesign of it > > for HTTP :) > > Protocols evolve, networks evolve. I am sure we were > prescient when we designed TCP such that HTTP could simply > use it. However, other realities of evolution did force us > to design SCTP, for instance. But regardless, the point is > that we should be general, and we are; but we have to do this > while drawing a fine line between research and engineering. > Some applications that are appearing on the horizon are > streaming media and P2PTV; for these we have opened up > channels with IRTF. So I don't see where we are constraining > ourselves in ALTO. > > > I can envision video applications using the P2PSIP framework, for > > instance. > > Yes, and as I wrote earlier, they can use ALTO to discover > the the peer they find optimal within their constraints and use it. > > > In any event, I still don't have a good understanding of > what it means > > to consider the needs of these various things - what does > it mean to > > say that we'll consider the needs of BitTorrent/CDN, etc.? > > Could you maybe give me an example of what it means? > > Look at the Ono work, which is a plug-in to BitTorrent. It > uses Akamai redirections to find the closest peer to download > content from. In a sense, ALTO is replacing that ad-hoc > lookup and providing a much more deterministic answer. That > is what we mean by the needs of "BitTorrent/CDN etc." > > > What I am saying is that it is not for us to determine the > usefulness > > of a particular piece of information. As long as the peers > or service > > providers are willing to share a piece of information, that can be > > consumed by other peers as they deem fit. So, I don't > think we should > > consider ourselves the gatekeeper for the types of > information shared. > > But we are not. As I made the point earlier, ALTO is not out > to replace BitTorrent. So replicating in ALTO the details > about peers that BitTorrent already has is > counter-productive. Instead, ALTO can focus on providing the > pieces that BitTorrent does not: > topology, policy, etc. That is where we will make a difference. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 > Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 15 08:20:52 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6053A69A0; Wed, 15 Oct 2008 08:20:52 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798C13A69A0; Wed, 15 Oct 2008 08:20:51 -0700 (PDT) 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=[AWL=0.000, 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 j1rY7COJQPya; Wed, 15 Oct 2008 08:20:50 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E91133A68CC; Wed, 15 Oct 2008 08:20:49 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9FFKmZk010124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 10:20:48 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9FFKlmi025935; Wed, 15 Oct 2008 10:20:48 -0500 (CDT) Message-ID: <48F60A4F.3010604@alcatel-lucent.com> Date: Wed, 15 Oct 2008 10:20:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: vidyan@qualcomm.com References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> <48F36E15.2000408@alcatel-lucent.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Narayanan, Vidya wrote: > Hi Vijay, I am not at all talking about reinventing what BitTorrent > can do or even remotely about any actual p2p application itself. I > am only talking about peer selection. However, I think there is a > critical difference between what I view as contributing to peer > selection and what the current proposed charter does. Vidya: Thank you for your response. I think we are converging to the crucial difference in this thread. This is a good thing. More inline. > Peer selection is important to ISPs from a network utilization > perspective and to peers themselves from a performance perspective. > That automatically makes peer selection a function of multiple > aspects - a) information that some service providers may decide to > share with the peers, b) information that peers decide to make > available about themselves to other peers for this purpose, and, c) > any measurements peers may do on their own. The current charter > definition (and from what I can tell based on your response below) > only seems to allow for a). I would agree that c) is out of scope of > ALTO and something that peers can additionally do. I strongly > believe that b) should be part of the ALTO work. I believe that incorporating (b) expands the charter quite a bit, whereas the consensus since the first BoF was for narrowing it down. I will also note that the feedback expressed on the list does not appear to view ALTO as a peer description protocol. To be sure, I am not unsympathetic to (b), it seems like a great problem to solve, it's just that ALTO may not be the best place to solve this problem. In the end, maybe the ADs can decide a way forward. > This functionality itself is application agnostic and requires an > interoperable solution for it to be beneficial. This has nothing to > do with content itself; it is purely about sharing information that > helps with peer selection. Protocols like BitTorrent already contain elements such that the peers know enough about other peers that the overlay is functioning. The information that BitTorrent (and other P2P overlays) do not have is topology and policies. This is where ALTO is urged to fill a crucial gap, at least initially. Since the IETF/MIT workshop, the problem outlined for what has become ALTO has been how to choose the peers wisely. We (i.e., the BoF/list participants) have been diligent to note that ALTO is not completely dependent on service providers; third parties can run ALTO servers as well; and these servers can use ad-hoc techniques like Ono (which was discussed yesterday on the list) or some form of Internet Coordinate Systems to derive a topology. We have also been diligent to note that ALTO is an additional service provided to an overlay; the overlay will continue to function without it (albeit in a bit of a sub-optimal manner.) We have also noted given a choice between a service provider run ALTO server and a third party ALTO server, that peers will naturally gravitate towards the ALTO server that provides them the best information over a long period of time. In other words, we have covered substantial grounds since the IETF/MIT workshop and the Dublin BoF based on the premise of the problem as the group has understood it. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 15 11:39:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F219828C27F; Wed, 15 Oct 2008 11:39:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DA53A67A8 for ; Wed, 15 Oct 2008 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 jcDnSEHVPvO0 for ; Wed, 15 Oct 2008 11:39:37 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 8CBF43A6893 for ; Wed, 15 Oct 2008 11:39:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2952916wfd.31 for ; Wed, 15 Oct 2008 11:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=lwL/uGDAHrJ9xAdO/MH9o42NiI+zJSLFb7ey2kPt+1s=; b=U7qa6vtBrsRb4uExm0zVDz40hMRBBmTMKA9rFoXHpI5NUsBLcuexEyYPBnWFqrJTd9 0Ey6ACiPoN0Zog69EXUcy3NQEsv3AA77TilwRUROaBaAPj5yrXE015Yo+A21oapX1JVy /WmIwRNMROIJR27agpnc8O20t+Zim9fhqUM4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=xC6cypa4YzwiVYBNhLPetFP83KwmnM7LOQWlUJNgKlxXJ0yOqufxCcF8xch5Im77An x0125/QoBA0wvHmOMhwssoHfKKSk0Q6+lxHZsBZUZr58YoGv0DpEqwzks0zFeQ+M8dNA fP/CjuPapRzGAv5C0cJCbeq9cJzVhD/OtMUPs= Received: by 10.140.249.20 with SMTP id w20mr980368rvh.21.1224095997421; Wed, 15 Oct 2008 11:39:57 -0700 (PDT) Received: by 10.140.173.21 with HTTP; Wed, 15 Oct 2008 11:39:57 -0700 (PDT) Message-ID: Date: Wed, 15 Oct 2008 11:39:57 -0700 From: "Lisa Dusseault" To: "Vijay K. Gurbani" In-Reply-To: <48F60A4F.3010604@alcatel-lucent.com> MIME-Version: 1.0 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> <48F36E15.2000408@alcatel-lucent.com> <48F60A4F.3010604@alcatel-lucent.com> Cc: "p2pi@ietf.org" , ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573615653==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0573615653== Content-Type: multipart/alternative; boundary="----=_Part_23982_13171991.1224095997399" ------=_Part_23982_13171991.1224095997399 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani wrote: > Narayanan, Vidya wrote: > > Peer selection is important to ISPs from a network utilization perspective >> and to peers themselves from a performance perspective. That automatically >> makes peer selection a function of multiple aspects - a) information that >> some service providers may decide to share with the peers, b) information >> that peers decide to make available about themselves to other peers for this >> purpose, and, c) any measurements peers may do on their own. The current >> charter definition (and from what I can tell based on your response below) >> only seems to allow for a). I would agree that c) is out of scope of >> ALTO and something that peers can additionally do. I strongly believe >> that b) should be part of the ALTO work. >> > > I believe that incorporating (b) expands the charter quite a bit, > whereas the consensus since the first BoF was for narrowing > it down. I will also note that the feedback expressed on the > list does not appear to view ALTO as a peer description protocol. > > To be sure, I am not unsympathetic to (b), it seems like a great > problem to solve, it's just that ALTO may not be the best place > to solve this problem. > > In the end, maybe the ADs can decide a way forward. > There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). Lisa ------=_Part_23982_13171991.1224095997399 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani <vkg@alcatel-lucent.com> wrote:
Narayanan, Vidya wrote:

Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own.  The current charter definition (and from what I can tell based on your response below) only seems to allow for a).  I would agree that c) is out of scope of
 ALTO and something that peers can additionally do.  I strongly believe that b) should be part of the ALTO work.

I believe that incorporating (b) expands the charter quite a bit,
whereas the consensus since the first BoF was for narrowing
it down.  I will also note that the feedback expressed on the
list does not appear to view ALTO as a peer description protocol.

To be sure, I am not unsympathetic to (b), it seems like a great
problem to solve, it's just that ALTO may not be the best place
to solve this problem.

In the end, maybe the ADs can decide a way forward.


There's plenty of work to do in a).  My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a).  Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG.  Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b).

Lisa 
 

------=_Part_23982_13171991.1224095997399-- --===============0573615653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0573615653==-- From p2pi-bounces@ietf.org Wed Oct 15 12:34:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828913A6C23; Wed, 15 Oct 2008 12:34:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243983A6C23; Wed, 15 Oct 2008 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 NGJmXJR-vbC0; Wed, 15 Oct 2008 12:34:37 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id BC69E3A6A51; Wed, 15 Oct 2008 12:34:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id DFB31E10B3F; Wed, 15 Oct 2008 15:35:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCiWnHyIcO6c; Wed, 15 Oct 2008 15:35:19 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 93D0DE10B19; Wed, 15 Oct 2008 15:35:19 -0400 (EDT) Date: Wed, 15 Oct 2008 15:35:19 -0400 (EDT) From: Laird Popkin To: Lisa Dusseault Message-ID: <1794728186.370661224099319579.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1138344074==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1138344074== Content-Type: multipart/alternative; boundary="----=_Part_16372_2030550209.1224099319578" ------=_Part_16372_2030550209.1224099319578 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree that (a) is where ALTO should focus.=20 To elaborate a bit, (a) can only be provided by the ISP by definition (nobo= dy else really knows the ISP's network and business policies), while (b) an= d (c) are, if I understand you correctly, both currently being done using i= nternal communications within the p2p applications using their existing pro= tocols. IMO, standardizing (a) is very important because it allows ISPs to = provide information to applications that that they can't otherwise get (e.g= . ISP policies) or can only derive in complex, inaccurate ways (e.g. using = hop counts to approximate network locality).=20 -=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks=20 =C2=A0=C2=A0mobile:=C2=A0646/465-0570=20 ----- Original Message -----=20 From: "Lisa Dusseault" =20 To: "Vijay K. Gurbani" =20 Cc: p2pi@ietf.org, ietf@ietf.org=20 Sent: Wednesday, October 15, 2008 2:39:57 PM (GMT-0500) America/New_York=20 Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto= )=20 On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani < vkg@alcatel-lucent.com = > wrote:=20 Narayanan, Vidya wrote:=20 Peer selection is important to ISPs from a network utilization perspective = and to peers themselves from a performance perspective. That automatically = makes peer selection a function of multiple aspects - a) information that s= ome service providers may decide to share with the peers, b) information th= at peers decide to make available about themselves to other peers for this = purpose, and, c) any measurements peers may do on their own. =C2=A0The curr= ent charter definition (and from what I can tell based on your response bel= ow) only seems to allow for a). =C2=A0I would agree that c) is out of scope= of=20 =C2=A0ALTO and something that peers can additionally do. =C2=A0I strongly b= elieve that b) should be part of the ALTO work.=20 I believe that incorporating (b) expands the charter quite a bit,=20 whereas the consensus since the first BoF was for narrowing=20 it down. =C2=A0I will also note that the feedback expressed on the=20 list does not appear to view ALTO as a peer description protocol.=20 To be sure, I am not unsympathetic to (b), it seems like a great=20 problem to solve, it's just that ALTO may not be the best place=20 to solve this problem.=20 In the end, maybe the ADs can decide a way forward.=20 There's plenty of work to do in a).=C2=A0 My recommendation based on estima= tion of appropriate scope as well as an estimation of the consensus here, w= ould be to do that first -- to have a charter that is scoped to (a).=C2=A0 = Then the possibilities for (b) include working in the P2P research group, i= ndividual submissions, and /or a new BoF/WG.=C2=A0 Another option would be = a future charter update for ALTO if it's successful and there's consensus f= or it to be the basis for (b).=20 Lisa=C2=A0=20 =C2=A0=20 _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_16372_2030550209.1224099319578 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree that (a) is where ALTO should focus.
To elaborate a bit, (a) can only be provided by the ISP by= definition (nobody else really knows the ISP's network and business polici= es), while (b) and (c) are, if I understand you correctly, both currently b= eing done using internal communications within the p2p applications using t= heir existing protocols. IMO, standardizing (a) is very important because i= t allows ISPs to provide information to applications that that they can't o= therwise get (e.g. ISP policies) or can only derive in complex, inaccurate = ways (e.g. using hop counts to approximate network locality).
-=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks
=C2=A0=C2= =A0mobile:=C2=A0646/465-0570

----- Original Message -----
From: "= Lisa Dusseault" <lisa.dusseault@gmail.com>
To: "Vijay K. Gurbani" <= ;vkg@alcatel-lucent.com>
Cc: p2pi@ietf.org, ietf@ietf.org
Sent: Wedne= sday, October 15, 2008 2:39:57 PM (GMT-0500) America/New_York
Subject: R= e: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

<= div dir=3D"ltr">

On Wed, Oct 15, 2008 at = 8:20 AM, Vijay K. Gurbani <vkg@alcatel-lucent.com> wrote:<= br>
Narayanan, Vidya wrote:

Peer select= ion is important to ISPs from a network utilization perspective and to peer= s themselves from a performance perspective. That automatically makes peer = selection a function of multiple aspects - a) information that some service= providers may decide to share with the peers, b) information that peers de= cide to make available about themselves to other peers for this purpose, an= d, c) any measurements peers may do on their own. =C2=A0The current charter= definition (and from what I can tell based on your response below) only se= ems to allow for a). =C2=A0I would agree that c) is out of scope of
=C2=A0ALTO and something that peers can additionally do. =C2=A0I strongly b= elieve that b) should be part of the ALTO work.

I believe that incorporating (b) expands the charter quite a bit,
whereas the consensus since the first BoF was for narrowing
it down. =C2=A0I will also note that the feedback expressed on the
list does not appear to view ALTO as a peer description protocol.

To be sure, I am not unsympathetic to (b), it seems like a great
problem to solve, it's just that ALTO may not be the best place
to solve this problem.

In the end, maybe the ADs can decide a way forward.

There's plenty of work to do in a).=C2=A0 My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a).=C2=A0 Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG.=C2=A0 Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b).

Lisa=C2=A0
=C2=A0


_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_16372_2030550209.1224099319578-- --===============1138344074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1138344074==-- From p2pi-bounces@ietf.org Wed Oct 15 16:47:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7948E3A6A31; Wed, 15 Oct 2008 16:47:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCA83A6A31; Wed, 15 Oct 2008 16:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 xxzsdOPBMvoZ; Wed, 15 Oct 2008 16:47:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 132833A69EC; Wed, 15 Oct 2008 16:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224114481; x=1255650481; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Lisa=20Dusseault=20,=0D=0A =20=20=20=20=20=20=20=20"Vijay=20K.=20Gurbani"=0D=0A=09|CC:=20"p2pi@ietf.org"=20,=20"ietf@ietf.org"=20|Date:=20Wed, =2015=20Oct=202008=2016:47:45=20-0700|Subject:=20RE:=20[p 2pi]=20WG=20Review:=20Application-Layer=20Traffic=20Optim ization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review:=20 Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQ |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=09=20=0D =0A=09=20<48EFA1B7.7010508@alcatel-lucent.com>=0D=0A=09 =20=0D=0A=09=20<48F36E15.2000408@alcatel-luc ent.com>=0D=0A=09=20=0D=0A=09=20<48F60A4F.30 10604@alcatel-lucent.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5406"=3B=20a=3D"10938205"; bh=xbuaznDPZnsHR1iB/XWI3zRuMaXH97o5Eo58e0lnCVY=; b=lSpIGYyLE4LuT+Q/VYfExdEzpfvmmAMsbI8vH0o4vtYHMzVdrORX4KAE F7boq1mCGYi1dvK6H8GzZEipit7tVhbzNPY1DKdN2zwj8Zv2rdJ4MEA5r +bUy+08b44nxFqd2nLPhcTy9R/xFYoRBieEQuQr7FdSBSpDky7BoIDQHK Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5406"; a="10938205" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2008 16:47:45 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9FNlij0000909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Oct 2008 16:47:45 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9FNliVR017553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Oct 2008 16:47:44 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 15 Oct 2008 16:47:44 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 15 Oct 2008 16:47:43 -0700 From: "Narayanan, Vidya" To: Lisa Dusseault , "Vijay K. Gurbani" Date: Wed, 15 Oct 2008 16:47:45 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQ Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EFA1B7.7010508@alcatel-lucent.com> <48F36E15.2000408@alcatel-lucent.com> <48F60A4F.3010604@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lisa, > > > There's plenty of work to do in a). My recommendation based > on estimation of appropriate scope as well as an estimation > of the consensus here, would be to do that first -- to have a > charter that is scoped to (a). Then the possibilities for > (b) include working in the P2P research group, individual > submissions, and /or a new BoF/WG. Another option would be a > future charter update for ALTO if it's successful and there's > consensus for it to be the basis for (b). > This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility. We keep talking about scope creep here, but, we seem to miss something critical. By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing. Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances. Let me provide some additional context here. One of the pieces of information that is important to allow wireless devices to participate in p2p networks is the basic fact that a given node is wireless. This may place some fundamentally different criteria on path selection decisions that cannot be deduced simply with topology information. For any forward looking work we do at the IETF, we must stop designing just for wired (and stationary) devices. These are the designs that tend to look horrible when adapted to the wireless (and mobile) world and I seriously hope that that is not where we are headed with this work. Best regards, Vidya > Lisa > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 16 01:45:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35463A6B64; Thu, 16 Oct 2008 01:45:04 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B923A6B4C; Thu, 16 Oct 2008 01:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2tKjW4b2W50I; Thu, 16 Oct 2008 01:45:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D21853A6B64; Thu, 16 Oct 2008 01:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1224146763; x=1255682763; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2pi@ietf.org"=20|CC:=20"ietf@ietf.org "=20|Date:=20Thu,=2016=20Oct=202008=2001:4 5:50=20-0700|Subject:=20Re:=20[p2pi]=20WG=20Review:=20App lication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20Re:=20[p2pi]=20WG=20Review:=20Applicatio n-Layer=20Traffic=20Optimization=0D=0A=20(alto) |Thread-Index:=20Ackva5czBEUA6wFMRt+cB2Kq3sElUw=3D=3D |Message-ID:=20<4A27D05E36DE7E47B96BCF7DD8F3FD7101D20307C 9@NASANEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5406"=3B=20a=3D"11030202"; bh=sV3j8XBJW9CUvS0sS5SBVujszQmfQyCctPlHVv5HYo4=; b=Pg1K9iU2s93Un/CyKcsrcaZulQfahvXeXd6VY4i0b1bglTZU6MReAbSs M0q3lOT/HtWpYjiXKbJEuGH/6+d7pW4Zag099geNkcglRTxdVTtozF0yL +Nk3ErgGZ2j6ljuodH/YBHB2EMPFTv+3if3O4P/+oC9XKn+A4gLpfD807 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5406"; a="11030202" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2008 01:45:53 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9G8jrQ0008364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Oct 2008 01:45:53 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9G8jqqx015024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Oct 2008 01:45:53 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.78]) by nasanexhc03.na.qualcomm.com ([172.30.33.34]) with mapi; Thu, 16 Oct 2008 01:45:52 -0700 From: "Das, Saumitra" To: "p2pi@ietf.org" Date: Thu, 16 Oct 2008 01:45:50 -0700 Thread-Topic: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackva5czBEUA6wFMRt+cB2Kq3sElUw== Message-ID: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D20307C9@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Citing one of the responses from Vijay on Oct 13 "For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from." I agree ALTO does not determine content location but given a set of content locations by an application would provide a ranked order of "good" peers to download this from. However, a fundamental issue to consider is that simply using ISP information is not enough for a querying peer to determine wisely what to do. Unless there is a performance perspective to the goodness of peers, is there a real incentive for applications to adopt looking up ALTO since they anyway need to do a bunch of performance measurements. Applications typically may be happy simply saturating download bandwidth and not much else. Providing more information in ALTO could be a path to incentivising the users of the service. What this more information is should be up for debate. We should also consider the more general question of when we are designing something for peer selection we are only designing a small piece of an information plane for the Internet. In this context, it may be useful to have information that can be aggregated across various applications and simply because specific BitTorrent clients may implement some such mechanisms does not mean that is a good design choice to leave it out of ALTO. An information plane (see the U Wash IPlane paper) of some kind may be something to consider given that we seem to solving only one part of the puzzle. Instead of each application building their own proprietary and application-specific information plane which is redundant and wasteful, such an information plane could potentially be something ALTO provides and can be reused across a wide range of services. Thanks, Saumitra Das _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 16 12:33:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8905B3A6A7D; Thu, 16 Oct 2008 12:33:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDD53A6A6B; Thu, 16 Oct 2008 12:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.37 X-Spam-Level: X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_FWDLOOK=1.666] 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 dSqo4+upn8Dn; Thu, 16 Oct 2008 12:33:23 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 8A8EE3A6452; Thu, 16 Oct 2008 12:33:23 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.61622455; Thu, 16 Oct 2008 15:34:07 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 15:34:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 15:34:06 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKA= References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> From: "Woundy, Richard" To: "Narayanan, Vidya" , "Lisa Dusseault" , "Vijay K. Gurbani" X-OriginalArrivalTime: 16 Oct 2008 19:34:07.0714 (UTC) FILETIME=[27F49420:01C92FC6] Cc: p2pi@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Vidya, >This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Personally, I can see that there is value in "b): information that peers decide to make available about themselves to other peers for this purpose". Your example below was information about whether a client is on a wireless network. In an earlier thread, I had suggested that clients may want to reveal their "available access bandwidth" in a similar fashion; see . So even as an "ISP person", I can see where you are coming from. But if I am interpreting RFC 2418 correctly , it is not sufficient to decide if "b)" is a worthy IETF activity, but that there are enough participants working on "b)" for an IETF effort to be successful. Quoting from parts of RFC 2418 section 2.1: "Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)?" "Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group?" "Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means." You said: >Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't. Are you volunteering to work on requirements and/or solutions for "b)"? Would others? (I may be interested and supportive in the future, although right now I am predictably focused on activities related to "a)".) If there isn't a quorum to work on "b)" right now, this could be revisited in the future with a re-charter of ALTO, when such a quorum does exist. If there is a quorum, it would be helpful to hear about it. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Narayanan, Vidya Sent: Wednesday, October 15, 2008 7:48 PM To: Lisa Dusseault; Vijay K. Gurbani Cc: p2pi@ietf.org; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Lisa, > > > There's plenty of work to do in a). My recommendation based > on estimation of appropriate scope as well as an estimation > of the consensus here, would be to do that first -- to have a > charter that is scoped to (a). Then the possibilities for > (b) include working in the P2P research group, individual > submissions, and /or a new BoF/WG. Another option would be a > future charter update for ALTO if it's successful and there's > consensus for it to be the basis for (b). > This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility. We keep talking about scope creep here, but, we seem to miss something critical. By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing. Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances. Let me provide some additional context here. One of the pieces of information that is important to allow wireless devices to participate in p2p networks is the basic fact that a given node is wireless. This may place some fundamentally different criteria on path selection decisions that cannot be deduced simply with topology information. For any forward looking work we do at the IETF, we must stop designing just for wired (and stationary) devices. These are the designs that tend to look horrible when adapted to the wireless (and mobile) world and I seriously hope that that is not where we are headed with this work. Best regards, Vidya > Lisa > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 17 13:56:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803CE28C122; Fri, 17 Oct 2008 13:56:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8666C3A6AF6; Fri, 17 Oct 2008 13:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-1.531, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 cNSRZax6lTEH; Fri, 17 Oct 2008 13:56:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6E1333A6AF4; Fri, 17 Oct 2008 13:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224277068; x=1255813068; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Woundy,=20Richard"=20,=0D=0A=20=20=20=20=20=20=20=20Lisa=20Dusseault=0D=0A =09,=0D=0A=20=20=20=20=20=20=20 =20"Vijay=20K.=20Gurbani"=20|CC: =20"p2pi@ietf.org"=20,=20"ietf@ietf.org" =20|Date:=20Fri,=2017=20Oct=202008=2013:57 :44=20-0700|Subject:=20RE:=20[p2pi]=20WG=20Review:=20Appl ication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20[p2pi]=20WG=20Review:=20Application-Laye r=20Traffic=20Optimization=20(alto)|Thread-Index:=20Acku9 XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKAANLNEEA=3D=3D |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com><48EFA1B7.70105 08@alcatel-lucent.com><48F36E15.2000408@alca tel-lucent.com><48F60A4F.3010604@alcatel-luc ent.com>=0D=0A=20=0D=0A=20<74CCBBDF76102 846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.co m>|In-Reply-To:=20<74CCBBDF76102846AFA7B29F3A98D3F6028962 CF@PACDCEXCMB06.cable.comcast.com>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5408"=3B=20a=3D"11032789"; bh=zI6K+SAqGQLmuVI4Ty5d+5Hm+O1VrpbotdNS79El8jc=; b=v96f3oOkBkplnYrdRR+Am5TBPtQyj4u5ReFq6nSnJ1rNxl9MyaKRVwkA 98MVSv8b4UZGssG7h81qfhgGQpe+MSt9UR4yfDhoTmAHYB+3/+2N/cU3j 0KMWkhGsEmVD99uDd7suX6QYnSp1V10FeXw7YTL1Vy1iGCbqlYnsdWM82 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5408"; a="11032789" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2008 13:57:47 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HKvluF009387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2008 13:57:47 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HKvkVP018631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Oct 2008 13:57:47 -0700 (PDT) Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 17 Oct 2008 13:57:46 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 17 Oct 2008 13:57:46 -0700 From: "Narayanan, Vidya" To: "Woundy, Richard" , Lisa Dusseault , "Vijay K. Gurbani" Date: Fri, 17 Oct 2008 13:57:44 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKAANLNEEA== Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org To answer your question about participation, I can definitely volunteer to work on the requirements and solution for this effort. We will try to produce a draft explaining the problem and need for peer participation in ALTO by the deadline for Minneapolis. With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, was brought into the IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now into a WG proposal for APP with little to no explanation to the wider audience on the rationale. So, it may be best if we didn't really get into the process discussion with this effort. I'm just hoping that at this stage, the ADs are going to hear all opinions and also use technical judgment on the relative points that are being made. Best regards, Vidya > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Thursday, October 16, 2008 12:34 PM > To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani > Cc: p2pi@ietf.org; ietf@ietf.org > Subject: RE: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Vidya, > > >This would be a big mistake on our part. b) is not a > research problem > and it is very much related to the same problem being solved in ALTO. > > Personally, I can see that there is value in "b): information > that peers decide to make available about themselves to other > peers for this purpose". Your example below was information > about whether a client is on a wireless network. In an > earlier thread, I had suggested that clients may want to > reveal their "available access bandwidth" in a similar > fashion; see > . So even as an "ISP person", I can see where you are coming > from. > > But if I am interpreting RFC 2418 correctly > , it is not sufficient to > decide if "b)" is a worthy IETF activity, but that there are > enough participants working on "b)" for an IETF effort to be > successful. Quoting from parts of RFC 2418 section 2.1: > > "Is there sufficient interest within the IETF in the working > group's topic with enough people willing to expend the effort > to produce the desired result (e.g., a protocol specification)?" > > "Is there enough expertise within the IETF in the working > group's topic, and are those people interested in > contributing in the working group?" > > "Does a base of interested consumers (end-users) appear to > exist for the planned work? Consumer interest can be > measured by participation of end-users within the IETF > process, as well as by less direct means." > > You said: > > >Given that Lisa is looking for solutions, I almost wish I have a > solution thought out :) But, I don't. > > Are you volunteering to work on requirements and/or solutions > for "b)"? > Would others? > > (I may be interested and supportive in the future, although > right now I am predictably focused on activities related to "a)".) > > If there isn't a quorum to work on "b)" right now, this could > be revisited in the future with a re-charter of ALTO, when > such a quorum does exist. > > If there is a quorum, it would be helpful to hear about it. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Narayanan, Vidya > Sent: Wednesday, October 15, 2008 7:48 PM > To: Lisa Dusseault; Vijay K. Gurbani > Cc: p2pi@ietf.org; ietf@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization > (alto) > > Lisa, > > > > > > > There's plenty of work to do in a). My recommendation based on > > estimation of appropriate scope as well as an estimation of the > > consensus here, would be to do that first -- to have a > charter that is > > scoped to (a). Then the possibilities for > > (b) include working in the P2P research group, individual > submissions, > > and /or a new BoF/WG. Another option would be a future > charter update > > for ALTO if it's successful and there's consensus for it to be the > > basis for (b). > > > > This would be a big mistake on our part. b) is not a > research problem and it is very much related to the same > problem being solved in ALTO. > Letting each p2p application come up with its own mechanism > of doing b) only kills the interoperability and > extensibility. We keep talking about scope creep here, but, > we seem to miss something critical. By not keeping the > related problems together in producing solutions, we are only > increasing the number of different mechanisms that are going > to be needed in future to provide this one service - I cannot > understand why that is a good thing. > > Without allowing for b), I think information that a) gives > you can be more or less useless in some circumstances. Let > me provide some additional context here. One of the pieces > of information that is important to allow wireless devices to > participate in p2p networks is the basic fact that a given > node is wireless. This may place some fundamentally > different criteria on path selection decisions that cannot be > deduced simply with topology information. > > For any forward looking work we do at the IETF, we must stop > designing just for wired (and stationary) devices. These are > the designs that tend to look horrible when adapted to the > wireless (and mobile) world and I seriously hope that that is > not where we are headed with this work. > > Best regards, > Vidya > > > Lisa > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 17 14:31:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707CA28C12A; Fri, 17 Oct 2008 14:31:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CDE73A6A22; Fri, 17 Oct 2008 14:31:31 -0700 (PDT) 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=[AWL=0.000, 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 kvgwhpN0MEUE; Fri, 17 Oct 2008 14:31:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1732A28C130; Fri, 17 Oct 2008 14:30:54 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9HLVt7H026415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2008 16:31:55 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9HLVsr8007451; Fri, 17 Oct 2008 16:31:55 -0500 (CDT) Message-ID: <48F9044C.2050905@alcatel-lucent.com> Date: Fri, 17 Oct 2008 16:31:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Narayanan, Vidya wrote: > With respect to process, I think this one takes the cake among > abominations. Having been at the IETF long enough and having > participated in several BoFs, I'm quite familiar with RFC2418 and the > process. Here we have an effort that started with a closed/gated > workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04758.html). The initial notes from the workshop are also archived at http://www.ietf.org/mail-archive/web/p2pi/current/msg00025.html. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 17 16:19:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280BC3A6ABC; Fri, 17 Oct 2008 16:19:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175D23A6ABC; Fri, 17 Oct 2008 16:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, 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 AL6wDAJqtjjq; Fri, 17 Oct 2008 16:19:18 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F17983A68A1; Fri, 17 Oct 2008 16:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224285623; x=1255821623; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Vijay=20K.=20Gurbani"=20|CC: =20"p2pi@ietf.org"=20,=20"ietf@ietf.org" =20|Date:=20Fri,=2017=20Oct=202008=2016:20 :20=20-0700|Subject:=20RE:=20[p2pi]=20WG=20Review:=20Appl ication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20[p2pi]=20WG=20Review:=20Application-Laye r=20Traffic=20Optimization=20(alto)|Thread-Index:=20Ackwn 91I9Fis9hGmQvaznG1hB7edkgAAh9HQ|Message-ID:=20|References:=20<20081006203532.B1D673A68AF@core3.amsl.c om><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com>=0D=0A=20=0D=0A=20<74CCBBDF76102846AFA7B29F3A98D3F6028962C F@PACDCEXCMB06.cable.comcast.com>=0D=0A=20 =0D=0A=20<48F9044C.2050905@alcatel-lucent.com> |In-Reply-To:=20<48F9044C.2050905@alcatel-lucent.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5408"=3B=20a=3D"11037864"; bh=AMIq0HXAp+vXwziFhEdNlBVqXrLKqqH0FkfCX4DkTlM=; b=qacybkZD/96mSMmfs5ITjwvKTG5NMreU5Z5ifPjTPLySqoodzM70RDRQ sUIk7D86+WzVs1IK8pBI8SH8mCWr0Z3d1+MI9iKuQdrrum9GwP4ss1rE9 7MO1q99ZPxhUGVfu3BOs0IJw9+3g1L9njkWW9WK0nk8Kw7Tdg7jYmqlRA k=; X-IronPort-AV: E=McAfee;i="5300,2777,5408"; a="11037864" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2008 16:20:23 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HNKM9p011345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2008 16:20:22 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HNKMBi000319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Oct 2008 16:20:22 -0700 (PDT) Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 17 Oct 2008 16:20:22 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Fri, 17 Oct 2008 16:20:20 -0700 From: "Narayanan, Vidya" To: "Vijay K. Gurbani" Date: Fri, 17 Oct 2008 16:20:20 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackwn91I9Fis9hGmQvaznG1hB7edkgAAh9HQ Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> <48F9044C.2050905@alcatel-lucent.com> In-Reply-To: <48F9044C.2050905@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Friday, October 17, 2008 2:32 PM > To: Narayanan, Vidya > Cc: p2pi@ietf.org; ietf@ietf.org > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Narayanan, Vidya wrote: > > With respect to process, I think this one takes the cake among > > abominations. Having been at the IETF long enough and having > > participated in several BoFs, I'm quite familiar with > RFC2418 and the > > process. Here we have an effort that started with a closed/gated > > workshop outside the IETF, > > Actually, this is not so. The workshop *was* sponsored by > IETF; the RAI area, to be more precise (please see > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04758.html). > My point is that this was a closed effort - it was not a meeting that was open to all for attendence. The fact that the RAI ADs decided to do this doesn't automatically make it "IETF sponsored". Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF. All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts. But, let's get past that itself and focus on how to make the best of the effort going forward. Regards, Vidya > The initial notes from the workshop are also archived at > http://www.ietf.org/mail-archive/web/p2pi/current/msg00025.html. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 > Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Oct 19 10:22:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3C33A6805; Sun, 19 Oct 2008 10:22:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70403A6805; Sun, 19 Oct 2008 10:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, 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 v6rMhSRc67fc; Sun, 19 Oct 2008 10:22:27 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 8B4993A67B2; Sun, 19 Oct 2008 10:22:26 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Oct 2008 19:23:12 +0200 Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Oct 2008 19:23:12 +0200 Received: from [172.16.82.10] ([163.162.180.246]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Oct 2008 19:23:11 +0200 Message-ID: <48FB6CFD.1070505@telecomitalia.it> Date: Sun, 19 Oct 2008 19:23:09 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: "Narayanan, Vidya" References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> <48F9044C.2050905@alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 19 Oct 2008 17:23:11.0775 (UTC) FILETIME=[5CB0AAF0:01C9320F] Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2035033653==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2035033653== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050102060205040904050309" This is a cryptographically signed message in MIME format. --------------ms050102060205040904050309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Narayanan, Vidya wrote: >>> With respect to process, I think this one takes the cake among >>> abominations. Having been at the IETF long enough and having >>> participated in several BoFs, I'm quite familiar with RFC2418 and >>> the process. Here we have an effort that started with a >>> closed/gated workshop outside the IETF, >> Actually, this is not so. The workshop *was* sponsored by IETF; >> the RAI area, to be more precise (please see >> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg >> 04758.html). > > My point is that this was a closed effort - it was not a meeting that > was open to all for attendence. The fact that the RAI ADs decided to > do this doesn't automatically make it "IETF sponsored". Not to > mention that the topics covered by this workshop or the scope of it > was not really open to discussion at the IETF. All of this makes it > sqauarely an effort outside the IETF and let's not try to pretend it > was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico --------------ms050102060205040904050309 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTkxNzIzMDlaMCMG CSqGSIb3DQEJBDEWBBTkYatKNxKsufBS14zSeKszAsbIBTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABUAIOVwiL+V 9Zg68rGuPCS7XKLSMbNlyxz70nyRGveBfNxDAG+iYiV3zmkian1KI91WzrTqSI4Hhf5xd0XC wAdXV73yvpLybIDIZb6yBLllMUMPVoLCO5MF5YSQ6M0DdIXn+vPRpY8Ph8JRA+PZoYLwXicJ AlJq7dgrNaYJUO7US97yFtzYcgWoBo9B94WzmiyfDJPQTkVCih8PT0IvaPEgE1YlIAfri696 5LNFc5fPhn6EfiP3FsStxbFjXMOjuWHuyYwZJ7r5T6ei6Xd/yOjPP5MYYSdDQv5l1GBnABbF FQi2wDxVJEF/Eyt1D2SSsJOeXsdczShYavPt8z/Dg20AAAAAAAA= --------------ms050102060205040904050309-- --===============2035033653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============2035033653==-- From p2pi-bounces@ietf.org Mon Oct 20 07:22:43 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C7D3A6960; Mon, 20 Oct 2008 07:22:42 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA85A3A68D0; Mon, 20 Oct 2008 07:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Q1bscITF0A4l; Mon, 20 Oct 2008 07:22:40 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 36F363A69BC; Mon, 20 Oct 2008 07:22:40 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:23:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 15:23:53 +0100 Message-ID: In-Reply-To: <48FB6CFD.1070505@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckyD27gXZ63y3rKSYe8zbdaJVD7qgArhQMQ References: <20081006203532.B1D673A68AF@core3.amsl.com><48EFA1B7.7010508@alcatel-lucent.com><48F36E15.2000408@alcatel-lucent.com><48F60A4F.3010604@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F6028962CF@PACDCEXCMB06.cable.comcast.com> <48F9044C.2050905@alcatel-lucent.com> <48FB6CFD.1070505@telecomitalia.it> From: To: , X-OriginalArrivalTime: 20 Oct 2008 14:23:51.0298 (UTC) FILETIME=[795BEE20:01C932BF] Cc: p2pi@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Just catching up on some of the traffic in this list. I think the openness of the ALTO effort is highlighted by the fact that currently this is the busiest out of the 8 IETF lists I subscribe to... In the IETF vigorous mailing activity is a better signal than any other of the level of interest in a topic and thus the level of involvement in the wider community. Regarding the workshop, it was pretty open. It was widely advertised, albeit at short notice. Seemingly the majority of submissions were accepted (impressive given the short time available in the workshop). Copies of all the documents and presentations are available and the output was to convince several ADs of the need for new work at the IETF (hence two BoFs and probably eventually 2 WGs). As to including your point b). Lisa correctly pointed out that the main reason the BoF in Dublin failed was a lack of focus in ALTO. What you are proposing sounds like an interesting work item for a different WG or more likely an IRTF RG given you admit you don't know of any proposals out there currently. However adding it to ALTO would just scupper the next BoF and thus kill the work completely. I think Lars summed up the ideal aims of ALTO best: "The intent here isn't that ALTO would pick the globally optimal peers for you, the intent is that it'll help an application reach a good set of peers a bit more quickly." In other words ALTO will be great so long as it is lightweight and has sensible ambitions! Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Enrico Marocco Sent: 19 October 2008 18:23 To: Narayanan, Vidya Cc: p2pi@ietf.org; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Narayanan, Vidya wrote: >>> With respect to process, I think this one takes the cake among >>> abominations. Having been at the IETF long enough and having >>> participated in several BoFs, I'm quite familiar with RFC2418 and >>> the process. Here we have an effort that started with a >>> closed/gated workshop outside the IETF, >> Actually, this is not so. The workshop *was* sponsored by IETF; the >> RAI area, to be more precise (please see >> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg >> 04758.html). > > My point is that this was a closed effort - it was not a meeting that > was open to all for attendence. The fact that the RAI ADs decided to > do this doesn't automatically make it "IETF sponsored". Not to > mention that the topics covered by this workshop or the scope of it > was not really open to discussion at the IETF. All of this makes it > sqauarely an effort outside the IETF and let's not try to pretend it > was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Oct 20 07:26:06 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540633A6A6D; Mon, 20 Oct 2008 07:26:06 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D893A69BC; Mon, 20 Oct 2008 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 ZwcOuLxmc3Ow; Mon, 20 Oct 2008 07:26:04 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2705F3A6AC2; Mon, 20 Oct 2008 07:26:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D9FDDE10BB4; Mon, 20 Oct 2008 10:27:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDUN1IU9adr0; Mon, 20 Oct 2008 10:27:03 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 9B8FAE10A85; Mon, 20 Oct 2008 10:27:03 -0400 (EDT) Date: Mon, 20 Oct 2008 10:27:03 -0400 (EDT) From: Laird Popkin To: Enrico Marocco Message-ID: <989249016.379371224512823605.JavaMail.root@dkny.pando.com> In-Reply-To: <48FB6CFD.1070505@telecomitalia.it> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'd like to second this - the P2Pi workshop was open and well publicized. While I've not been involved in the IETF for a long time, I heard about it through several channels, submitted a paper, presented, etc. Of course, I can't prove that someone else didn't feel excluded, but from my perspective the process has certainly appeared open. Does anyone else feel like this process hasn't been open to all interested parties? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Enrico Marocco" To: "Vidya Narayanan" Cc: p2pi@ietf.org, ietf@ietf.org Sent: Sunday, October 19, 2008 1:23:09 PM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Narayanan, Vidya wrote: >>> With respect to process, I think this one takes the cake among >>> abominations. Having been at the IETF long enough and having >>> participated in several BoFs, I'm quite familiar with RFC2418 and >>> the process. Here we have an effort that started with a >>> closed/gated workshop outside the IETF, >> Actually, this is not so. The workshop *was* sponsored by IETF; >> the RAI area, to be more precise (please see >> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg >> 04758.html). > > My point is that this was a closed effort - it was not a meeting that > was open to all for attendence. The fact that the RAI ADs decided to > do this doesn't automatically make it "IETF sponsored". Not to > mention that the topics covered by this workshop or the scope of it > was not really open to discussion at the IETF. All of this makes it > sqauarely an effort outside the IETF and let's not try to pretend it > was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 06:16:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033B528C12D; Tue, 21 Oct 2008 06:16:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9709328C125 for ; Tue, 21 Oct 2008 06:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 EiBPiwK6oxGl for ; Tue, 21 Oct 2008 06:16:22 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 7DD2028C12D for ; Tue, 21 Oct 2008 06:16:12 -0700 (PDT) Received: by gxk9 with SMTP id 9so5388298gxk.13 for ; Tue, 21 Oct 2008 06:17:13 -0700 (PDT) Received: by 10.142.54.17 with SMTP id c17mr3727571wfa.278.1224595032823; Tue, 21 Oct 2008 06:17:12 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 32sm17308422wfc.12.2008.10.21.06.17.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 06:17:11 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: tana@ietf.org, p2pi@ietf.org, TSV Area Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 06:17:09 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [p2pi] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2133770622==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2133770622== Content-Type: multipart/alternative; boundary=Apple-Mail-173--672790031 --Apple-Mail-173--672790031 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit At the BoF in Dublin, we observed strong interest and consensus that the TANA work should go forward as a working group. Does the following proposed charter, based on the BoF description, capture what the community was interested in? Thanks, -- Stas Techniques for Advanced Networking Applications (TANA) WG Chair(s): TBD Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Lars Eggert Mailing Lists: General Discussion: tana@ietf.org To Subscribe: tana-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/tana/ Description of Working Group: The TANA WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without ECN fill the buffer at the head of the bottleneck link. This increases the delay experienced by other applications. In the best case, with an ideally sized buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. TANA is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best- effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck, * eliminate long standing queues and thus keep delay low when no other traffic is present, * quickly yield to regular best-effort traffic that uses standard TCP congestion control, * add little to the queueing delays induced by TCP traffic, * operate well in today's typical networks with FIFO queueing with drop-tail discipline, * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent transport connections to one peer and/or to different peers. Standard Internet congestion control result in different transport connections sharing bottleneck capacity. When an application uses several unchoked and not rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. (3) The WG will discuss how to best take into account prior work in the area. The outcome will be either incorporated into the document specifying the experimental congestion control algorithm or into a separate document summarizing prior work. Goals and Milestones TBD Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC TBD Submit "Transport for Advanced Networking Applications (TANA)" to the IESG for consideration as an Experimental RFC Internet-Drafts Transport for Advanced Networking Applications (TANA) Problem Statement http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt No Requests for Comments -- Stanislav Shalunov --Apple-Mail-173--672790031 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
At the BoF in Dublin, we = observed strong interest and consensus that the TANA work should go = forward as a working group.  Does the following proposed charter, = based on the BoF description, capture what the community was interested = in?

Thanks,  -- = Stas



Techniques = for Advanced Networking Applications (TANA) = WG

Chair(s):
TBD

Transport Area Director(s):
* = Magnus Westerlund <magnus.westerlund@ericsson.= com>
* Lars Eggert <lars.eggert@nokia.com>

Tr= ansport Area Advisor:
* Lars Eggert <lars.eggert@nokia.com>

Ma= iling Lists:

General Discussion: tana@ietf.org
To Subscribe: tana-request@ietf.org
In = Body: (un)subscribe
Archive: http://www.ietf.org/ma= il-archive/web/tana/

Description of Working Group:

The = TANA WG is chartered to standardize a congestion control mechanism that = should saturate the bottleneck, maintain low delay, and yield to = standard TCP.

Applications that transmit large amounts of data = for a long time with congestion-limited TCP, but without ECN fill the = buffer at the head of the bottleneck link. This increases the delay = experienced by other applications. In the best case, with an ideally = sized buffer of one RTT, the delay doubles. In some cases, the extra = delay may be much larger. This is a particularly acute and common case = is when P2P applications upload over thin home uplinks: delays in these = cases can sometimes be of the order of seconds.

The IETF's = standard end-to-end transport protocols have not been designed to = minimize the extra delay introduced by them into the
network. TCP, as = a side effect of filling the buffer until it experiences drop-tail loss, = effectively maximizes the delay. While this works well for applications = that are not delay-sensitive, it harms interactive applications that = share the same bottleneck. VoIP and games are particularly affected, but = even web browsing may become problematic.

TANA is a = transport-area WG that will focus on broadly applicable techniques that = allow large amounts of data to be consistently transmitted without = substantially affecting the delays experienced by other users and = applications.

The WG will work on the following:

(1) An = experimental congestion control algorithm for less-than-best-effort = "background" transmissions, i.e., an algorithm that attempts to scavenge = otherwise idle bandwidth for its transmissions in a way that minimizes = interference with regular best-effort traffic.

Desired features = of such an algorithm are:
* saturate the bottleneck,
* eliminate = long standing queues and thus keep delay low when no other traffic is = present,
* quickly yield to regular best-effort traffic that uses = standard TCP congestion control,
* add little to the queueing delays = induced by TCP traffic,
* operate well in today's typical networks = with FIFO queueing with drop-tail discipline,
* where available, use = explicit congestion notification (ECN), active queue management (AQM), = and/or end-to-end differentiated services (DiffServ).

Application = of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is = expected to occur in the working groups that maintain those = protocols.

(2) A document that clarifies the current practices of = application design and reasons behind them and discusses the tradeoffs = surrounding the use of many concurrent transport connections to one peer = and/or to different peers.

Standard Internet congestion control = result in different transport connections sharing bottleneck capacity. = When an application uses several unchoked and not rate-limited transport = connections to transfer through a bottleneck, it may obtain a larger = fraction of the bottleneck than if it had used fewer connections. = Although capacity is the most commonly considered bottleneck resource, = middlebox state table entries are also an important resource for an end = system communication. Other resource types may exist, and the guidelines = are expected to comprehensively discuss them.

Applications use a = variety of techniques to mitigate these concerns.  These techniques = have not always been reviewed by the IETF and their interaction with TCP = dynamics is poorly understood.  The WG document the known = techniques, discussing the consequences and, where appropriate, provide = guidance to application designers.

(3) The WG will discuss how to = best take into account prior work in the area.  The outcome will be = either incorporated into the document specifying the experimental = congestion control algorithm or into a separate document summarizing = prior work.



Goals and Milestones

TBD  Submit = "Multiple Transport Connections in Applications Design" to the IESG for = consideration as an Informational RFC
TBD  Submit "Transport for = Advanced Networking Applications (TANA)" to the IESG for consideration = as an Experimental RFC


Internet-Drafts

Transport for = Advanced Networking Applications (TANA) Problem Statement
http://www.ietf.org/internet-drafts/draft-shalunov-tana-pr= oblem-statement-01.txt

No Requests for = Comments




= --Apple-Mail-173--672790031-- --===============2133770622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============2133770622==-- From p2pi-bounces@ietf.org Tue Oct 21 07:59:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD113A6B2F; Tue, 21 Oct 2008 07:59:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9AC3A6B2F; Tue, 21 Oct 2008 07:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Q4VmkYeOGie1; Tue, 21 Oct 2008 07:59:39 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 326DB3A6943; Tue, 21 Oct 2008 07:59:39 -0700 (PDT) Received: from [172.17.157.161] ([12.157.84.6]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9LF0gXa083618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2008 18:00:44 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> From: Lars Eggert To: "ext Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 11:00:42 -0400 References: X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8459/Tue Oct 21 15:24:15 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Tue, 21 Oct 2008 18:00:51 +0300 (EEST) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-10-21, at 10:12, ext Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > The charter, as written looks reasonable to me. I just hate the name > :). the name was an ad hoc creation, and when it was picked, some of the stuff that ended up being ALTO was part of the TANA scope - so it needed to be broader. If we can come up with a better name I'm all ears (and you make several good suggestions below). What I'd like to avoid is a long discussion about a text string, when what I'd rather like to see is a discussion on whether the work we're going to attempt is reasonable. Lars > It should really be something like: > "Minimizing Impact of Large Transfers" (MILT) > "Concurrent Realtime And Bulk Applications" (CRABA) > "Fast Transfers Adding Minimal Latency" (FTAML) > "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- > probably not a good one as it looks too much like "barfing" :) I'm pretty sure CRABA would also have interesting soundex matches... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 08:05:43 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC85C3A6B3E; Tue, 21 Oct 2008 08:05:43 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2D03A6958; Tue, 21 Oct 2008 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3d0DTJC1xSvc; Tue, 21 Oct 2008 08:05:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 738073A6B62; Tue, 21 Oct 2008 08:05:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,458,1220227200"; d="scan'208";a="94037519" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2008 15:06:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9LF6MCh026645; Tue, 21 Oct 2008 08:06:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9LF6L7L013874; Tue, 21 Oct 2008 15:06:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 08:06:09 -0700 Received: from [10.32.241.78] ([10.32.241.78]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 08:06:08 -0700 Message-Id: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> From: Bruce Davie To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 11:06:07 -0400 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 21 Oct 2008 15:06:09.0289 (UTC) FILETIME=[8C885F90:01C9338E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9991; t=1224601582; x=1225465582; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[tsv-area]=20TANA=20proposed=20charter |Sender:=20; bh=dKEr0iN5SnUHv5Ghow0fLlx4AGMnFQmjV5iSE0L8oZo=; b=iJex+MU/6q6FoXF4SfLf6U/zOR9y0dWTO9o+oG4JTybpcXJoLNQOyBxjeV ssscRz2CRg4GqZpMTmyhRC80ycRIILgtnzjhLczH9EI+6m0zNXCxmVPj2GJu C97uAJTaGy/JLG1MXrzRBvHRBHcdOqOhDZX7r+haB4LfNg4x3s3QE=; Authentication-Results: sj-dkim-1; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'll start by saying that I support the WG and think the new charter is pretty good. I have a few suggestions for small changes. > Applications that transmit large amounts of data for a long > time with congestion-limited TCP, but without ECN fill the > buffer at the head of the bottleneck link. Replace ECN with Active Queue Management (AQM) > This increases the > delay experienced by other applications. It would be more accurate to say "In the absence of any form of isolation in the queues, this increases..." > In the best case, > with an ideally sized buffer of one RTT, the delay doubles. In > some cases, the extra delay may be much larger. Since there isn't complete agreement on the ideal size of a buffer, just say: "If the buffer size is one RTT, the delay doubles...." > This is a > particularly acute and common case is when P2P applications > upload over thin home uplinks: delays in these cases can > sometimes be of the order of seconds. [snip] > The WG will work on the following: > > (1) An experimental congestion control algorithm for > less-than-best-effort "background" transmissions, i.e., an > algorithm that attempts to scavenge otherwise idle bandwidth > for its transmissions in a way that minimizes interference > with regular best-effort traffic. > > Desired features of such an algorithm are: > * saturate the bottleneck, > * eliminate long standing queues and thus keep delay low when > no other traffic is present, > * quickly yield to regular best-effort traffic that uses > standard TCP congestion control, perhaps it would be more precise to say: "quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control" > * add little to the queueing delays induced by TCP traffic, > * operate well in today's typical networks with FIFO queueing > with drop-tail discipline, suggest deleting "today's typical" > * where available, use explicit congestion notification (ECN), > active queue management (AQM), and/or end-to-end > differentiated services (DiffServ). [snip] > (2) A document that clarifies the current practices of > application design and reasons behind them and discusses the > tradeoffs surrounding the use of many concurrent transport > connections to one peer and/or to different peers. This is just a bit confusingly worded and could be interpreted very broadly. I would suggest: "(2) A document that discusses the tradeoffs surrounding the use of many concurrent transport connections to one peer and/or to different peers and recommends best practices for applications in this regard." Finally, I hate the name, because it is so completely undescriptive of the WG. I like all of Wesley's suggestions better, MILT probably being the best. Bruce On Oct 21, 2008, at 10:12 AM, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > The charter, as written looks reasonable to me. I just hate the name > :). > > Even though you explained it before, "Advanced Network Applications" > still bothers me as it's completely unspecific. Furthermore, I think > that "Techniques" isn't well-scoped enough to limit the work properly > as it seems to be focused on congestion control techniques, and not > NAT traversal techniques, search techniques, etc. > > The way that the problem statement was described, I think what's > really > meant is "bulk transfer applications that want to be a good neighbor > to > real-time or other applications". I guess the challenge is that this > doesn't produce a pronouncable acronym like TANA :). > > It should really be something like: > "Minimizing Impact of Large Transfers" (MILT) > "Concurrent Realtime And Bulk Applications" (CRABA) > "Fast Transfers Adding Minimal Latency" (FTAML) > "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- > probably not a good one as it looks too much like "barfing" :) > > But if nobody else has a problem with the TANA name, I'll keep my > mouth > shut so we don't waste time and energy. There are bigger fish to fry! > > > > >> -----Original Message----- >> From: tsv-area-bounces@ietf.org >> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Stanislav Shalunov >> Sent: Tuesday, October 21, 2008 9:17 AM >> To: tana@ietf.org; p2pi@ietf.org; TSV Area >> Subject: [tsv-area] TANA proposed charter >> >> At the BoF in Dublin, we observed strong interest and >> consensus that the TANA work should go forward as a working >> group. Does the following proposed charter, based on the BoF >> description, capture what the community was interested in? >> >> Thanks, -- Stas >> >> >> >> Techniques for Advanced Networking Applications (TANA) WG >> >> Chair(s): >> TBD >> >> Transport Area Director(s): >> * Magnus Westerlund >> * Lars Eggert >> >> Transport Area Advisor: >> * Lars Eggert >> >> Mailing Lists: >> >> General Discussion: tana@ietf.org >> To Subscribe: tana-request@ietf.org >> In Body: (un)subscribe >> Archive: http://www.ietf.org/mail-archive/web/tana/ >> >> Description of Working Group: >> >> The TANA WG is chartered to standardize a congestion control >> mechanism that should saturate the bottleneck, maintain low >> delay, and yield to standard TCP. >> >> Applications that transmit large amounts of data for a long >> time with congestion-limited TCP, but without ECN fill the >> buffer at the head of the bottleneck link. This increases the >> delay experienced by other applications. In the best case, >> with an ideally sized buffer of one RTT, the delay doubles. In >> some cases, the extra delay may be much larger. This is a >> particularly acute and common case is when P2P applications >> upload over thin home uplinks: delays in these cases can >> sometimes be of the order of seconds. >> >> The IETF's standard end-to-end transport protocols have not >> been designed to minimize the extra delay introduced by them into the >> network. TCP, as a side effect of filling the buffer until it >> experiences drop-tail loss, effectively maximizes the delay. >> While this works well for applications that are not >> delay-sensitive, it harms interactive applications that share >> the same bottleneck. VoIP and games are particularly affected, >> but even web browsing may become problematic. >> >> TANA is a transport-area WG that will focus on broadly >> applicable techniques that allow large amounts of data to be >> consistently transmitted without substantially affecting the >> delays experienced by other users and applications. >> >> The WG will work on the following: >> >> (1) An experimental congestion control algorithm for >> less-than-best-effort "background" transmissions, i.e., an >> algorithm that attempts to scavenge otherwise idle bandwidth >> for its transmissions in a way that minimizes interference >> with regular best-effort traffic. >> >> Desired features of such an algorithm are: >> * saturate the bottleneck, >> * eliminate long standing queues and thus keep delay low when >> no other traffic is present, >> * quickly yield to regular best-effort traffic that uses >> standard TCP congestion control, >> * add little to the queueing delays induced by TCP traffic, >> * operate well in today's typical networks with FIFO queueing >> with drop-tail discipline, >> * where available, use explicit congestion notification (ECN), >> active queue management (AQM), and/or end-to-end >> differentiated services (DiffServ). >> >> Application of this algorithm to existing transport protocols >> (TCP, SCTP, DCCP) is expected to occur in the working groups >> that maintain those protocols. >> >> (2) A document that clarifies the current practices of >> application design and reasons behind them and discusses the >> tradeoffs surrounding the use of many concurrent transport >> connections to one peer and/or to different peers. >> >> Standard Internet congestion control result in different >> transport connections sharing bottleneck capacity. When an >> application uses several unchoked and not rate-limited >> transport connections to transfer through a bottleneck, it may >> obtain a larger fraction of the bottleneck than if it had used >> fewer connections. Although capacity is the most commonly >> considered bottleneck resource, middlebox state table entries >> are also an important resource for an end system >> communication. Other resource types may exist, and the >> guidelines are expected to comprehensively discuss them. >> >> Applications use a variety of techniques to mitigate these >> concerns. These techniques have not always been reviewed by >> the IETF and their interaction with TCP dynamics is poorly >> understood. The WG document the known techniques, discussing >> the consequences and, where appropriate, provide guidance to >> application designers. >> >> (3) The WG will discuss how to best take into account prior >> work in the area. The outcome will be either incorporated >> into the document specifying the experimental congestion >> control algorithm or into a separate document summarizing prior work. >> >> >> >> Goals and Milestones >> >> TBD Submit "Multiple Transport Connections in Applications >> Design" to the IESG for consideration as an Informational RFC >> TBD Submit "Transport for Advanced Networking Applications >> (TANA)" to the IESG for consideration as an Experimental RFC >> >> >> Internet-Drafts >> >> Transport for Advanced Networking Applications (TANA) Problem >> Statement >> http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem >> -statement-01.txt >> >> No Requests for Comments >> >> >> >> -- >> Stanislav Shalunov >> >> Hacking Startups >> >> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 08:39:41 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DC728C0D0; Tue, 21 Oct 2008 08:39:41 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92163A67C0; Tue, 21 Oct 2008 08:39:39 -0700 (PDT) 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 Js2ewUE69X6V; Tue, 21 Oct 2008 08:39:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C60DC3A6AE9; Tue, 21 Oct 2008 08:39:38 -0700 (PDT) Received: from [70.213.149.171] (171.sub-70-213-149.myvzw.com [70.213.149.171]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m9LFeIkM004639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 08:40:22 -0700 (PDT) Message-ID: <48FDF7E2.7050603@isi.edu> Date: Tue, 21 Oct 2008 08:40:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lars Eggert References: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> In-Reply-To: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org, tana@ietf.org, TSV Area , "ext Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > On 2008-10-21, at 10:12, ext Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> The charter, as written looks reasonable to me. I just hate the name >> :). > > the name was an ad hoc creation, and when it was picked, some of the > stuff that ended up being ALTO was part of the TANA scope - so it needed > to be broader. > > If we can come up with a better name I'm all ears (and you make several > good suggestions below). What I'd like to avoid is a long discussion > about a text string, when what I'd rather like to see is a discussion on > whether the work we're going to attempt is reasonable. > > Lars > >> It should really be something like: >> "Minimizing Impact of Large Transfers" (MILT) >> "Concurrent Realtime And Bulk Applications" (CRABA) >> "Fast Transfers Adding Minimal Latency" (FTAML) >> "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- >> probably not a good one as it looks too much like "barfing" :) FWIW, it seems like "background TCP" is what you want (BTCP); granted, that's already a spec'd protocol ;-) Maybe, more generally, Background Congestion Control (BACK-CC)? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj99+EACgkQE5f5cImnZrvY9ACgxGAeY/J4lMtZvxEht+/gxdfx KDUAniB8eeoRz0Z4HDyDBCGbKAHtAVvn =KTqj -----END PGP SIGNATURE----- _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 08:59:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAE83A6B60; Tue, 21 Oct 2008 08:59:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601BB3A6B3E; Tue, 21 Oct 2008 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.404 X-Spam-Level: X-Spam-Status: No, score=-103.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 fXXfM5X0nRrm; Tue, 21 Oct 2008 08:59:27 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 2D3AE3A67C0; Tue, 21 Oct 2008 08:59:27 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13464649; Tue, 21 Oct 2008 12:00:40 -0400 Message-Id: <0D46DABA-A743-48AF-8A9C-723A93FC0F0B@multicasttech.com> From: Marshall Eubanks To: Joe Touch In-Reply-To: <48FDF7E2.7050603@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 12:00:37 -0400 References: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> <48FDF7E2.7050603@isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "ext Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 11:40 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Lars Eggert wrote: >> Hi, >> >> On 2008-10-21, at 10:12, ext Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >>> The charter, as written looks reasonable to me. I just hate the >>> name >>> :). >> >> the name was an ad hoc creation, and when it was picked, some of the >> stuff that ended up being ALTO was part of the TANA scope - so it >> needed >> to be broader. >> >> If we can come up with a better name I'm all ears (and you make >> several >> good suggestions below). What I'd like to avoid is a long discussion >> about a text string, when what I'd rather like to see is a >> discussion on >> whether the work we're going to attempt is reasonable. >> >> Lars >> >>> It should really be something like: >>> "Minimizing Impact of Large Transfers" (MILT) >>> "Concurrent Realtime And Bulk Applications" (CRABA) >>> "Fast Transfers Adding Minimal Latency" (FTAML) >>> "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- >>> probably not a good one as it looks too much like "barfing" :) > > FWIW, it seems like "background TCP" is what you want (BTCP); granted, > that's already a spec'd protocol ;-) > > Maybe, more generally, Background Congestion Control (BACK-CC)? > Background Congestion Control of File Flows (BACK-OFF) ? Regards Marshall > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkj99+EACgkQE5f5cImnZrvY9ACgxGAeY/J4lMtZvxEht+/gxdfx > KDUAniB8eeoRz0Z4HDyDBCGbKAHtAVvn > =KTqj > -----END PGP SIGNATURE----- > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 09:22:29 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2603C3A6B5A; Tue, 21 Oct 2008 09:22:29 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA443A6B60; Tue, 21 Oct 2008 09:22:27 -0700 (PDT) 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 5iinyOGRCwF0; Tue, 21 Oct 2008 09:22:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 65DE33A6B46; Tue, 21 Oct 2008 09:22:23 -0700 (PDT) Received: from [70.213.149.171] (171.sub-70-213-149.myvzw.com [70.213.149.171]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m9LGN4SH019262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 09:23:07 -0700 (PDT) Message-ID: <48FE01E8.1090402@isi.edu> Date: Tue, 21 Oct 2008 09:23:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Marshall Eubanks References: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> <48FDF7E2.7050603@isi.edu> <0D46DABA-A743-48AF-8A9C-723A93FC0F0B@multicasttech.com> In-Reply-To: <0D46DABA-A743-48AF-8A9C-723A93FC0F0B@multicasttech.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "ext Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marshall Eubanks wrote: > On Oct 21, 2008, at 11:40 AM, Joe Touch wrote: ... > FWIW, it seems like "background TCP" is what you want (BTCP); granted, > that's already a spec'd protocol ;-) > > Maybe, more generally, Background Congestion Control (BACK-CC)? > > >> Background Congestion Control of File Flows (BACK-OFF) ? Maybe omit 'file' (there could be utility to non-file background transfers), i.e.: Backgrounds OF Flows (BACK-OFF) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj+AegACgkQE5f5cImnZrudEQCg/Mu+10EQi8OkzJDLq79PfPjb rnAAn1LIuK9YJvDF5lvBG9w9puKGXHzZ =QFUA -----END PGP SIGNATURE----- _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 09:31:07 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF6A3A67C0; Tue, 21 Oct 2008 09:31:07 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7348428C10A; Tue, 21 Oct 2008 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, 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 jmEs6gxtQqqW; Tue, 21 Oct 2008 09:31:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 509F43A67C0; Tue, 21 Oct 2008 09:31:05 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LGW6GB025397; Tue, 21 Oct 2008 09:32:06 -0700 (PDT) Message-Id: <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> From: Nicholas Weaver To: Bruce Davie In-Reply-To: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 09:32:06 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, TSV Area , tana@ietf.org, Nicholas Weaver , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Overall, I like the charter. The one problem I have, however, is not technical but the economic model. One can do a fairly decent (not great, but OK) approximation today by using a delay-based (eg, TCP-vegas) congestion control, as its designed to minimize queues and tends to get outcompeted by TCP reno (the two big-desired). Especially since intuition suggests that you could do this "single- ended", have the TCP stack on ONE side do delay-based estimation in both directions, and request window resizing to control the other side's sending rate. Yet why would a bulk-data content provider want to USE it? If the business model is "Video or other bulk data NOW", you don't want it friendlier than TCP, you only want to make sure you don't kill the queues on a customer's access device (if P2P). Thus the goal is ONLY to minimize queues, because being friendlier than TCP otherwise might get your data squeezed out in the rest of the network. If anything, you might want to be more HOSTILE, because you have a minimum aggregate data rate (averaged out over say 10-30 seconds of buffer) you need to keep a realtime display going. If the business model is "Video or other bulk data OVERNIGHT", then you are competing with the US Postal Service for legal content, which is pretty darn cheap for bandwidth. I'd really like a "Less Than Best Effort" data class/congestion control that does not populate queues and yields completely (on the order of a couple of RTTs) to conventional TCP. But I really wonder who'd use it? On Oct 21, 2008, at 8:06 AM, Bruce Davie wrote: > I'll start by saying that I support the WG and think the new charter > is pretty good. I have a few suggestions for small changes. > >> Applications that transmit large amounts of data for a long >> time with congestion-limited TCP, but without ECN fill the >> buffer at the head of the bottleneck link. > Replace ECN with Active Queue Management (AQM) I'd actually say "ECN or Active Queue Management" >> In the best case, >> with an ideally sized buffer of one RTT, the delay doubles. In >> some cases, the extra delay may be much larger. > > Since there isn't complete agreement on the ideal size of a buffer, > just say: > > "If the buffer size is one RTT, the delay doubles...." Especially since the bottleneck devices in question are sometimes obscenely overbuffered. >> (1) An experimental congestion control algorithm for >> less-than-best-effort "background" transmissions, i.e., an >> algorithm that attempts to scavenge otherwise idle bandwidth >> for its transmissions in a way that minimizes interference >> with regular best-effort traffic. >> >> Desired features of such an algorithm are: >> * saturate the bottleneck, >> * eliminate long standing queues and thus keep delay low when >> no other traffic is present, >> * quickly yield to regular best-effort traffic that uses >> standard TCP congestion control, > > perhaps it would be more precise to say: > "quickly yield to traffic sharing the same bottleneck queue that > uses standard TCP congestion control" One question is "How MUCH yielding". Should the nicer-than-TCP flow go to 0? Or should there be some equilibrium value (eg, with 2 flows, one TCP, one friendly-bulk-data, should it be something like 75/25?) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 10:05:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1294528C146; Tue, 21 Oct 2008 10:05:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100F328C149 for ; Tue, 21 Oct 2008 10:05:44 -0700 (PDT) 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=[AWL=0.000, 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 G1lpODRq3SHX for ; Tue, 21 Oct 2008 10:05:43 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id CECEC3A68C6 for ; Tue, 21 Oct 2008 10:05:42 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so441094yxg.49 for ; Tue, 21 Oct 2008 10:06:51 -0700 (PDT) Received: by 10.142.162.5 with SMTP id k5mr3847144wfe.260.1224608811421; Tue, 21 Oct 2008 10:06:51 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 22sm18620114wfg.13.2008.10.21.10.06.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 10:06:50 -0700 (PDT) Message-Id: <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> From: Stanislav Shalunov To: Nicholas Weaver In-Reply-To: <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 10:06:48 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> X-Mailer: Apple Mail (2.929.2) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 9:32 AM, Nicholas Weaver wrote: > Overall, I like the charter. > > > The one problem I have, however, is not technical but the economic > model. > > One can do a fairly decent (not great, but OK) approximation today > by using a delay-based (eg, TCP-vegas) congestion control, as its > designed to minimize queues and tends to get outcompeted by TCP reno > (the two big-desired). > > Especially since intuition suggests that you could do this "single- > ended", have the TCP stack on ONE side do delay-based estimation in > both directions, and request window resizing to control the other > side's sending rate. > > Yet why would a bulk-data content provider want to USE it? This is a great question and it deserves a more detailed answer than this, but let me try, briefly, to provide one reason to use it: Because the user wants to use the Internet while P2P app is doing whatever it is doing. Or the user will uninstall the app. The content provider serves at the leisure of the user. The user is willing to share uplink capacity as long as the sharing is largely invisible. The user will be upset by uploads that affect the user's ability to use the network for interactive applications and web browsing. (There are other scenarios, particularly with shared congestion and traffic management, that generally push the content provider to be nicer, so the above is just one example.) -- Stas > > > > If the business model is "Video or other bulk data NOW", you don't > want it friendlier than TCP, you only want to make sure you don't > kill the queues on a customer's access device (if P2P). Thus the > goal is ONLY to minimize queues, because being friendlier than TCP > otherwise might get your data squeezed out in the rest of the network. > > If anything, you might want to be more HOSTILE, because you have a > minimum aggregate data rate (averaged out over say 10-30 seconds of > buffer) you need to keep a realtime display going. > > > If the business model is "Video or other bulk data OVERNIGHT", then > you are competing with the US Postal Service for legal content, > which is pretty darn cheap for bandwidth. > > > I'd really like a "Less Than Best Effort" data class/congestion > control that does not populate queues and yields completely (on the > order of a couple of RTTs) to conventional TCP. But I really wonder > who'd use it? > > > On Oct 21, 2008, at 8:06 AM, Bruce Davie wrote: > >> I'll start by saying that I support the WG and think the new >> charter is pretty good. I have a few suggestions for small changes. >> >>> Applications that transmit large amounts of data for a long >>> time with congestion-limited TCP, but without ECN fill the >>> buffer at the head of the bottleneck link. >> Replace ECN with Active Queue Management (AQM) > > I'd actually say "ECN or Active Queue Management" > >>> In the best case, >>> with an ideally sized buffer of one RTT, the delay doubles. In >>> some cases, the extra delay may be much larger. >> >> Since there isn't complete agreement on the ideal size of a buffer, >> just say: >> >> "If the buffer size is one RTT, the delay doubles...." > > Especially since the bottleneck devices in question are sometimes > obscenely overbuffered. > >>> (1) An experimental congestion control algorithm for >>> less-than-best-effort "background" transmissions, i.e., an >>> algorithm that attempts to scavenge otherwise idle bandwidth >>> for its transmissions in a way that minimizes interference >>> with regular best-effort traffic. >>> >>> Desired features of such an algorithm are: >>> * saturate the bottleneck, >>> * eliminate long standing queues and thus keep delay low when >>> no other traffic is present, >>> * quickly yield to regular best-effort traffic that uses >>> standard TCP congestion control, >> >> perhaps it would be more precise to say: >> "quickly yield to traffic sharing the same bottleneck queue that >> uses standard TCP congestion control" > > One question is "How MUCH yielding". Should the nicer-than-TCP flow > go to 0? Or should there be some equilibrium value (eg, with 2 > flows, one TCP, one friendly-bulk-data, should it be something like > 75/25?) > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 10:10:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9402028C15A; Tue, 21 Oct 2008 10:10:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F68C3A6B76 for ; Tue, 21 Oct 2008 10:10:27 -0700 (PDT) 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=[AWL=0.000, 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 oKtnDvAqNKSX for ; Tue, 21 Oct 2008 10:10:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 7322E3A6B7A for ; Tue, 21 Oct 2008 10:10:26 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2745609wfd.31 for ; Tue, 21 Oct 2008 10:11:40 -0700 (PDT) Received: by 10.114.161.11 with SMTP id j11mr6589641wae.105.1224609100480; Tue, 21 Oct 2008 10:11:40 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 30sm10676803yxk.4.2008.10.21.10.11.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 10:11:40 -0700 (PDT) Message-Id: <8A620FD1-9B69-4E5A-BBFD-90975DFA783F@shlang.com> From: Stanislav Shalunov To: Ted Faber In-Reply-To: <20081021165051.GA64367@zod.isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 10:11:37 -0700 References: <20081021165051.GA64367@zod.isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 9:50 AM, Ted Faber wrote: > [The TANA name] should change. Would it be sufficient to change the name on the documents and not in the mailing list and the WG name? The WG name will go after we're done. The documents will remain. This would also allow us to choose the names when the document bodies are already written -- always a plus for relevance... -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 10:20:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2AAC3A6B7F; Tue, 21 Oct 2008 10:20:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729AA3A6B74; Tue, 21 Oct 2008 10:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 1RDC-L+0E4Ld; Tue, 21 Oct 2008 10:19:58 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id A31E33A6953; Tue, 21 Oct 2008 10:19:58 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9LHKgUn019027; Tue, 21 Oct 2008 13:20:42 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9LHKg5B025191; Tue, 21 Oct 2008 13:20:42 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m9LHKgWu025188; Tue, 21 Oct 2008 13:20:42 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 21 Oct 2008 13:20:42 -0400 (EDT) From: Salman Abdul Baset To: Stanislav Shalunov In-Reply-To: <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: p2pi@ietf.org, TSV Area , tana@ietf.org, Nicholas Weaver , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >> Yet why would a bulk-data content provider want to USE it? > > This is a great question and it deserves a more detailed answer than this, > but let me try, briefly, to provide one reason to use it: > > Because the user wants to use the Internet while P2P app is doing whatever it > is doing. Or the user will uninstall the app. To add: Some traffic is more important than others. A rough ordering is: VoIP > interactive > video-streaming > file-transfer > p2p The general recommendation by VoIP providers is to manually shutdown the p2p application(s) so as not to affect the calls. This manual shutdown is quite annoying for a user. -s > The content provider serves at the leisure of the user. The user is willing > to share uplink capacity as long as the sharing is largely invisible. The > user will be upset by uploads that affect the user's ability to use the > network for interactive applications and web browsing. > > (There are other scenarios, particularly with shared congestion and traffic > management, that generally push the content provider to be nicer, so the > above is just one example.) > > -- Stas > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 10:24:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF9628C14F; Tue, 21 Oct 2008 10:24:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4272028C147 for ; Tue, 21 Oct 2008 10:24:16 -0700 (PDT) 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=[AWL=0.000, 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 q6JJDE9Hj3IC for ; Tue, 21 Oct 2008 10:24:15 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 9C1BB3A6B7F for ; Tue, 21 Oct 2008 10:24:15 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so1244891wag.5 for ; Tue, 21 Oct 2008 10:25:29 -0700 (PDT) Received: by 10.114.181.13 with SMTP id d13mr6612094waf.101.1224609929308; Tue, 21 Oct 2008 10:25:29 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 4sm10703836yxq.9.2008.10.21.10.25.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 10:25:28 -0700 (PDT) Message-Id: <6A64CD99-C966-48A6-B69B-F165A4A6396A@shlang.com> From: Stanislav Shalunov To: Salman Abdul Baset In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 10:25:26 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, TSV Area , tana@ietf.org, Nicholas Weaver , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 10:20 AM, Salman Abdul Baset wrote: > The general recommendation by VoIP providers is to manually shutdown > the p2p application(s) so as not to affect the calls. This manual > shutdown is quite annoying for a user. Yep. This shutdown is a form of crude and manual congestion control, where the user moves the dial that the computer should be moving. Another example of that are max upload/download limits that P2P users are routinely expected to set if they want to use the net while running the app. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 10:40:38 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FED28C162; Tue, 21 Oct 2008 10:40:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFF23A6AC1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.54 X-Spam-Level: X-Spam-Status: No, score=-5.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, 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 ym1k5k-bK06S; Tue, 21 Oct 2008 10:40:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2412C3A68E1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LHfkrN004602; Tue, 21 Oct 2008 10:41:46 -0700 (PDT) Message-Id: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Stanislav Shalunov In-Reply-To: <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 10:41:46 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> X-Mailer: Apple Mail (2.929.2) Cc: tana@ietf.org, Nicholas Weaver , p2pi@ietf.org, TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 10:06 AM, Stanislav Shalunov wrote: >> Yet why would a bulk-data content provider want to USE it? > > This is a great question and it deserves a more detailed answer than > this, but let me try, briefly, to provide one reason to use it: > > Because the user wants to use the Internet while P2P app is doing > whatever it is doing. Or the user will uninstall the app. > > The content provider serves at the leisure of the user. The user is > willing to share uplink capacity as long as the sharing is largely > invisible. The user will be upset by uploads that affect the user's > ability to use the network for interactive applications and web > browsing. > > (There are other scenarios, particularly with shared congestion and > traffic management, that generally push the content provider to be > nicer, so the above is just one example.) However, the "Internet Not Working" effect is a subpiece of the overall problem: It is buffer occupancy on end-user buffers where the buffers are on the order of 1+ RTT (often 1+ Second!). Otherwise, the incentives are to be as UN-friendly as possible, as the externalities of congestion, EXCEPT at the access-link device, are applied to other users. Thus the P2P application provider can use existing RTT-based congestion control techniques to look for a greater than .25 RTT increase in delay, and respond to it by shrinking window sizes until the RTT drops and at-that-point, call it good. In fact, simply feed this into bandwidth estimation: Do an initial uncongested bandwidth estimation on startup (packet-pair measurement) to other peers (eliminates the "select a bandwidth" checkbox, bonus!), attempt to allocate to the whole pipe-5% with your TCP flows, and do an immediate backoff/slow ramp-back when you see RTTs increasing to MULTIPLE peers. Although a new class of congestion control that would do a true end-to- end job would be a better solution, the partial solution is complete from the P2P application provider's viewpoint: it fixes the "We break the net for everything else" effect on the user, while still keeping the very agressive (many-flow TCP) properties of P2P for the rest of the network. Or at least until you bribe the NAT box vendors to implement some active queue management. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 11:18:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC8528C14F; Tue, 21 Oct 2008 11:18:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743493A6AC1 for ; Tue, 21 Oct 2008 11:18:25 -0700 (PDT) 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=[AWL=0.000, 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 BqgpsuMHKqf0 for ; Tue, 21 Oct 2008 11:18:24 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 7D83A3A69E3 for ; Tue, 21 Oct 2008 11:18:24 -0700 (PDT) Received: by gxk9 with SMTP id 9so6024701gxk.13 for ; Tue, 21 Oct 2008 11:19:38 -0700 (PDT) Received: by 10.142.11.2 with SMTP id 2mr3885757wfk.307.1224613177818; Tue, 21 Oct 2008 11:19:37 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 24sm18782522wfc.6.2008.10.21.11.19.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 11:19:37 -0700 (PDT) Message-Id: <9DADA2F7-08E4-444F-817E-3357F53ECA41@shlang.com> From: Stanislav Shalunov To: Nicholas Weaver In-Reply-To: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 11:19:34 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.929.2) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 10:41 AM, Nicholas Weaver wrote: > do an immediate backoff/slow ramp-back when you see RTTs increasing > to MULTIPLE peers. Very true, and a special case of more general, and applicable to TCP, etc.: Any delay-based congestion control can be modified to key off the min delay to multiple peers, effectively ignoring far-away congestion. Any loss-based congestion control can be modified to key off the min loss to multiple peers, effectively ignoring far-away congestion. Any congestion control based on a numeric measure of congestion can be modified to key off the min measure of congestion to multiple peers, effectively ignoring far-away congestion. ("Far-away" = beyond the point of divergence of paths of the different flows.) In practice, I don't believe there are interesting benefits for doing so for P2P apps. For swarms that have a fighting chance, even the nicest behaviors yield excellent results. The main reason to get poor results is very small swarm size. Regardless -- congestion control on the Internet is done by endpoints. In the end-to-end framework, we can't do very much about noncooperative endpoints, but, luckily for us, there are relatively few of those. Making the congestion control mechanisms of cooperative endpoints more suitable for their goals can yield great benefits. Most P2P apps want to be cooperative as far as congestion control goes. In fact, you don't often see non-P2P apps that come with the expectation that users will manually set the right rate limits on them and prominently accessible UI for doing so. (The point of these rate limits is, of course, to send at a rate lower than would normally be produced by the nicest of congestion control mechanisms.) Thank you, -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 11:32:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D553A6B8C; Tue, 21 Oct 2008 11:32:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752E13A6B8C; Tue, 21 Oct 2008 11:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, 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 O9YZ9Nu+E26e; Tue, 21 Oct 2008 11:32:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3DCEB3A6B89; Tue, 21 Oct 2008 11:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224614038; x=1256150038; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Nicholas=20Weaver=20,=0D=0A =20=20=20=20=20=20=20=20Stanislav=20Shalunov=0D=0A=09|CC:=20"tana@ietf.org"=20 ,=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20 =20=20=20=20TSV=20Area=0D=0A=09,=20Bru ce=20Davie=20,=0D=0A=20=20=20=20=20=20 =20=20"Eddy,=20Wesley=20M.=0D=0A=20(GRC-RCN0)[VZ]"=20|Date:=20Tue,=2021=20Oct=202008=2011: 33:26=20-0700|Subject:=20RE:=20[tana]=20[p2pi]=20[tsv-are a]=20TANA=20proposed=20charter|Thread-Topic:=20[tana]=20[ p2pi]=20[tsv-area]=20TANA=20proposed=20charter |Thread-Index:=20AckzpE8VwMHEv0SxSwWTvEiWLooraAAAjXkQ |Message-ID:=20|References:=20=0D=0A=09=0D=0A =09<36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com>=0D=0A =09<9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.ed u>=0D=0A=09<19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.c om>=0D=0A=20<4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Be rkeley.EDU>|In-Reply-To:=20<4D4C2826-077A-4948-9A92-5EC39 3DC88AF@ICSI.Berkeley.EDU>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5411"=3B=20a=3D"11136557"; bh=FIa8oFeNU858lLORm50NuJDqbULtULi9XlS8t1y84gU=; b=Hlu9+4W2zzqc4Ct7utS8DUuQzvdClrvkUvcBZBxHSdF6rXDusQxhaZqS ac0JJjQLna8/ymfCab0UXWda/OMVD5qYjD8ZItfpWK11rHz76pbbhlZ0B Oe4db305n/ZvKICdJqxUZuoNvWol+s1A1RFC5CRUGELcalbendDMkU8M8 U=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11136557" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 11:33:30 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LIXUGf031892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 11:33:30 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LIXTaD007182 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 11:33:29 -0700 Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 11:33:29 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 11:33:29 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 21 Oct 2008 11:33:28 -0700 From: "Narayanan, Vidya" To: Nicholas Weaver , Stanislav Shalunov Date: Tue, 21 Oct 2008 11:33:26 -0700 Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: AckzpE8VwMHEv0SxSwWTvEiWLooraAAAjXkQ Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> In-Reply-To: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: TSV Area , "tana@ietf.org" , "p2pi@ietf.org" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'll start by saying that I do like the charter and believe that it is scoped correctly. I do, however, share some of the concerns that Nicholas has raised. We are talking about bulk data p2p transfers here, not necessarily just limited to file transfers. This does mean p2p models of video, games that exchange large amounts of data (e.g., World of Warcraft), large medical data (e.g., high resolution imaging) transfer, etc. fall into this category. Of course, for some of these applications, the answer may simply be that TANA is not applicable and hence, should not be used. However, I do think there are more grades to this. Another interesting piece of data is that for the first time in many years, http has overtaken p2p traffic in some markets, primarily driven by video download applications such as YouTube. Thanks to http being the common firewall transport mechanism, much of the video now runs over TCP. So, is it really as cut and dry as the bulk data P2P traffic needing to yield to Internet traffic? As long as it is about some background file transfer, perhaps that philosophy will just work. But, if the P2P app is also a video app, the answer is probably more complex. There is no doubt that this charter is attempting to tackle a very important issue. But, it would be good to think about what grades we may need to address here. Regards, Vidya > -----Original Message----- > From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On > Behalf Of Nicholas Weaver > Sent: Tuesday, October 21, 2008 10:42 AM > To: Stanislav Shalunov > Cc: tana@ietf.org; Nicholas Weaver; p2pi@ietf.org; TSV Area; > Bruce Davie; Eddy, Wesley M. (GRC-RCN0)[VZ] > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > > On Oct 21, 2008, at 10:06 AM, Stanislav Shalunov wrote: > >> Yet why would a bulk-data content provider want to USE it? > > > > This is a great question and it deserves a more detailed > answer than > > this, but let me try, briefly, to provide one reason to use it: > > > > Because the user wants to use the Internet while P2P app is doing > > whatever it is doing. Or the user will uninstall the app. > > > > The content provider serves at the leisure of the user. > The user is > > willing to share uplink capacity as long as the sharing is largely > > invisible. The user will be upset by uploads that affect > the user's > > ability to use the network for interactive applications and web > > browsing. > > > > (There are other scenarios, particularly with shared congestion and > > traffic management, that generally push the content provider to be > > nicer, so the above is just one example.) > > However, the "Internet Not Working" effect is a subpiece of > the overall problem: It is buffer occupancy on end-user > buffers where the > buffers are on the order of 1+ RTT (often 1+ Second!). Otherwise, > the incentives are to be as UN-friendly as possible, as the > externalities of congestion, EXCEPT at the access-link > device, are applied to other users. > > Thus the P2P application provider can use existing RTT-based > congestion control techniques to look for a greater than .25 > RTT increase in delay, and respond to it by shrinking window > sizes until the RTT drops and at-that-point, call it good. > > In fact, simply feed this into bandwidth estimation: Do an > initial uncongested bandwidth estimation on startup > (packet-pair measurement) to other peers (eliminates the > "select a bandwidth" checkbox, bonus!), attempt to allocate > to the whole pipe-5% with your TCP flows, and do an immediate > backoff/slow ramp-back when you see RTTs increasing to MULTIPLE peers. > > Although a new class of congestion control that would do a > true end-to- end job would be a better solution, the partial > solution is complete from the P2P application provider's > viewpoint: it fixes the "We break the net for everything > else" effect on the user, while still keeping the very > agressive (many-flow TCP) properties of P2P for the rest of > the network. > > Or at least until you bribe the NAT box vendors to implement > some active queue management. > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 11:49:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39ED028C133; Tue, 21 Oct 2008 11:49:36 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A0B3A6AA1; Tue, 21 Oct 2008 11:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, 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 ENSoIUxlL4CM; Tue, 21 Oct 2008 11:49:33 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 8A9EC3A6985; Tue, 21 Oct 2008 11:49:33 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LInifF012737; Tue, 21 Oct 2008 11:50:45 -0700 (PDT) Message-Id: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "Narayanan, Vidya" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 11:50:44 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.929.2) Cc: "tana@ietf.org" , Nicholas Weaver , "p2pi@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 11:33 AM, Narayanan, Vidya wrote: > I'll start by saying that I do like the charter and believe that it > is scoped correctly. > > I do, however, share some of the concerns that Nicholas has raised. > We are talking about bulk data p2p transfers here, not necessarily > just limited to file transfers. This does mean p2p models of video, > games that exchange large amounts of data (e.g., World of Warcraft), > large medical data (e.g., high resolution imaging) transfer, etc. > fall into this category. Of course, for some of these applications, > the answer may simply be that TANA is not applicable and hence, > should not be used. However, I do think there are more grades to > this. Well, it also depends too: The medical data is point to point, not P2P. A single TCP flow works well, and by being on real network, shouldn't experience the buffer issues present in home gateways, and by being a single flow, doesn't have the congestion-monopolization properties that P2P transfer programs have. Warcraft is not using P2P for playing, rather it is using P2P to save money in the data transfer of "patches", which include large amounts of content (textures, models, etc) (thus my rant on cost shifting). > Another interesting piece of data is that for the first time in many > years, http has overtaken p2p traffic in some markets, primarily > driven by video download applications such as YouTube. Thanks to > http being the common firewall transport mechanism, much of the > video now runs over TCP. So, is it really as cut and dry as the > bulk data P2P traffic needing to yield to Internet traffic? As long > as it is about some background file transfer, perhaps that > philosophy will just work. But, if the P2P app is also a video app, > the answer is probably more complex. Additionally, on the video apps, to my mind these are often badly done, and badly done in a way that the transport layer can do nothing about. Take YouTube for example. Its flash-based structure is not suitable (deliberately so!) for significant offline viewing. Yet its buffer strategy is "Fill-er-up completely", when many viewers will not stick around to watch the whole thing: a substantial waste although it does improve seek time. (Comedy Central's, OTOH, has a maximum buffer of about 10 seconds, so "stop in the middle" doesn't waste bandwidth). Yet all of these apps don't also properly recognize "I don't have ENOUGH bandwidth to keep up with realtime", and so don't (aren't capable of in flash?) of switching to a lower-bitrate encoded source. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 11:53:06 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA903A6B93; Tue, 21 Oct 2008 11:53:06 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154383A6B92; Tue, 21 Oct 2008 11:53:05 -0700 (PDT) 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 Q2jdwZx3Ky6b; Tue, 21 Oct 2008 11:53:04 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 283C93A6985; Tue, 21 Oct 2008 11:53:03 -0700 (PDT) Received: from 31-34-135.wireless.csail.mit.edu (31-34-135.wireless.csail.mit.edu [128.31.34.135]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9LIrt0h084372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2008 21:53:57 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: "ext Narayanan, Vidya" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 14:53:22 -0400 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8461/Tue Oct 21 17:16:58 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Tue, 21 Oct 2008 21:54:10 +0300 (EEST) Cc: "tana@ietf.org" , Nicholas Weaver , "p2pi@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, the goal for TANA and ALTO was to identify some subsets of the overall problem space that are sufficiently well understood that we can start to architect solutions. (And limit ourselves to those subsets where the IETF would be an appropriate body for this work.) There are certainly other parts of this problem that may be ripe for discussion in the IETF, and chartering TANA and ALTO by no means precludes this discussion from happening. I fully expect the IETF to take on additional work related to this general problem space in the future - we just had to start somewhere, and TANA and ALTO is where we started. I'd strongly encourage folks that want to push forward additional proposals for the IETF to take on in this space! Lars On 2008-10-21, at 14:33, ext Narayanan, Vidya wrote: > I'll start by saying that I do like the charter and believe that it > is scoped correctly. > > I do, however, share some of the concerns that Nicholas has raised. > We are talking about bulk data p2p transfers here, not necessarily > just limited to file transfers. This does mean p2p models of video, > games that exchange large amounts of data (e.g., World of Warcraft), > large medical data (e.g., high resolution imaging) transfer, etc. > fall into this category. Of course, for some of these applications, > the answer may simply be that TANA is not applicable and hence, > should not be used. However, I do think there are more grades to > this. > > Another interesting piece of data is that for the first time in many > years, http has overtaken p2p traffic in some markets, primarily > driven by video download applications such as YouTube. Thanks to > http being the common firewall transport mechanism, much of the > video now runs over TCP. So, is it really as cut and dry as the > bulk data P2P traffic needing to yield to Internet traffic? As long > as it is about some background file transfer, perhaps that > philosophy will just work. But, if the P2P app is also a video app, > the answer is probably more complex. > > There is no doubt that this charter is attempting to tackle a very > important issue. But, it would be good to think about what grades > we may need to address here. > > Regards, > Vidya _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 12:02:50 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACFB28C193; Tue, 21 Oct 2008 12:02:50 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD0628C14F; Tue, 21 Oct 2008 12:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, 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 uIFfg0b701+Z; Tue, 21 Oct 2008 12:02:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id EEB0A28C18C; Tue, 21 Oct 2008 12:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224615842; x=1256151842; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Nicholas=20Weaver=20|CC:=20 Stanislav=20Shalunov=20,=20TSV=20Are a=20,=0D=0A=20=20=20=20=20=20=20=20"ta na@ietf.org"=20,=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"Eddy,=0D=0A=20W esley=20M.=20(GRC-RCN0)[VZ]"=20 |Date:=20Tue,=2021=20Oct=202008=2012:03:08=20-0700 |Subject:=20RE:=20[p2pi]=20[tana]=20=20[tsv-area]=20TANA =20proposed=20charter|Thread-Topic:=20[p2pi]=20[tana]=20 =20[tsv-area]=20TANA=20proposed=20charter|Thread-Index: =20AckzrfLmZQY1ELVSTK+ZxrtKaRzi3AAAJHvQ|Message-ID:=20|References:=20=0D=0A=20=0D=0A=20<36BFC323-FDD5- 42DD-9A17-F32DDE7DDF5E@cisco.com>=0D=0A=20<9F472A6A-F3F3- 4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu>=0D=0A=20<19AE9A F4-E857-41EF-BF3E-B831F4EB8159@shlang.com>=0D=0A=20<4D4C2 826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>=0D=0A =20=0D=0A=20<086D03E5-61BE-43F5-A750-3539AF4 7F13E@ICSI.Berkeley.EDU>|In-Reply-To:=20<086D03E5-61BE-43 F5-A750-3539AF47F13E@ICSI.Berkeley.EDU>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5411"=3B=20a=3D"11137989"; bh=pMsdqib3xWLoENWmNPVCW/coPYThR7bWJ2JURv7zS5Q=; b=y8f53DHbMg00fnY0YGYlSXWrLG9o01I7JiSRLBm4IttOgUadaUYjcNa2 eR4HCTXQRv9/jGNYGpZxUHynuWGl34Clwi+FMUvTekGQJfvY9STdNfMcf YMuRbRpoAcRKgnTYcx/dqZiydxqPkpSRYVXh0mpU5v0BYTYEgjY/H7EZR U=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11137989" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 12:03:42 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJ3fDb026723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 12:03:41 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJ3efc024820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 12:03:40 -0700 (PDT) Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:03:08 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:03:08 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 21 Oct 2008 12:03:07 -0700 From: "Narayanan, Vidya" To: Nicholas Weaver Date: Tue, 21 Oct 2008 12:03:08 -0700 Thread-Topic: [p2pi] [tana] [tsv-area] TANA proposed charter Thread-Index: AckzrfLmZQY1ELVSTK+ZxrtKaRzi3AAAJHvQ Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> In-Reply-To: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "tana@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > -----Original Message----- > From: Nicholas Weaver [mailto:nweaver@ICSI.Berkeley.EDU] > Sent: Tuesday, October 21, 2008 11:51 AM > To: Narayanan, Vidya > Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; > tana@ietf.org; p2pi@ietf.org; Eddy, Wesley M. (GRC-RCN0)[VZ] > Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter > > > On Oct 21, 2008, at 11:33 AM, Narayanan, Vidya wrote: > > > I'll start by saying that I do like the charter and believe > that it is > > scoped correctly. > > > > I do, however, share some of the concerns that Nicholas has > raised. > > We are talking about bulk data p2p transfers here, not necessarily > > just limited to file transfers. This does mean p2p models > of video, > > games that exchange large amounts of data (e.g., World of > Warcraft), > > large medical data (e.g., high resolution imaging) transfer, etc. > > fall into this category. Of course, for some of these > applications, > > the answer may simply be that TANA is not applicable and > hence, should > > not be used. However, I do think there are more grades to this. > > Well, it also depends too: > > The medical data is point to point, not P2P. A single TCP > flow works well, and by being on real network, shouldn't > experience the buffer issues present in home gateways, and by > being a single flow, doesn't have the > congestion-monopolization properties that P2P transfer programs have. > > Warcraft is not using P2P for playing, rather it is using P2P > to save money in the data transfer of "patches", which > include large amounts of content (textures, models, etc) > (thus my rant on cost shifting). > I was not necessarily talking about the application models that exist today alone, but, was trying to see how future-proof this work can be. But, world of warcraft is probably not the right example here :) Vidya _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 12:06:10 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF4A28C0E7; Tue, 21 Oct 2008 12:06:10 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDE73A6AC1; Tue, 21 Oct 2008 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.116 X-Spam-Level: X-Spam-Status: No, score=-105.116 tagged_above=-999 required=5 tests=[AWL=1.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 viE22v5ZaO8p; Tue, 21 Oct 2008 12:06:07 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B0B443A6A42; Tue, 21 Oct 2008 12:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224616042; x=1256152042; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Lars=20Eggert=20|CC:=20Nicholas =20Weaver=20,=0D=0A=20=20=20 =20=20=20=20=20Stanislav=20Shalunov=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20TSV=20Area=20,=20"tana@ietf.org"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"Eddy,=20Wesley=20M .=0D=0A=20(GRC-RCN0)[VZ]"=20,=0D =0A=20=20=20=20=20=20=20=20Bruce=20Davie=20|Date:=20Tue,=2021=20Oct=202008=2012:07:19=20-0700 |Subject:=20RE:=20[tana]=20[p2pi]=20[tsv-area]=20TANA=20p roposed=20charter|Thread-Topic:=20[tana]=20[p2pi]=20[tsv- area]=20TANA=20proposed=20charter|Thread-Index:=20Ackzrnc owLH5GLYYTk2utGnctUsH/QAATLuw|Message-ID:=20 |References:=20=0D=0A=20=0D=0A=20<36BFC323-FDD5-42DD-9A17- F32DDE7DDF5E@cisco.com>=0D=0A=20<9F472A6A-F3F3-4616-9ACE- 4BD24D77FBCD@icsi.berkeley.edu>=0D=0A=20<19AE9AF4-E857-41 EF-BF3E-B831F4EB8159@shlang.com>=0D=0A=20<4D4C2826-077A-4 948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>=0D=0A=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5411"=3B=20a=3D"11213213"; bh=Zb9i0J8JBwxcJjwnsrd5DgI4zq0slw08U8CJa+Lzkt4=; b=LiWGwcFSlBFGClGE2Jf9NBBXmhNcP5fgQzPikMsjMdTMC7tcvBJVUApo nHn2TJsLBpJUWg9n3fFVMxo4hVb6mVp7hNG2jgnOfFE7mFC9QiA1ujXHn kNR8t1gXDReAi27Fq7kZRP76uqMsG3mJ8/zAw6VF2GljGzBiyr/1KpLVq s=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11213213" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 12:07:22 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJ7LGF027492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 12:07:22 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJ7GYd025826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 12:07:21 -0700 (PDT) Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:07:20 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:07:20 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 21 Oct 2008 12:07:19 -0700 From: "Narayanan, Vidya" To: Lars Eggert Date: Tue, 21 Oct 2008 12:07:19 -0700 Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: AckzrncowLH5GLYYTk2utGnctUsH/QAATLuw Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tana@ietf.org" , Nicholas Weaver , "p2pi@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Speaking for TANA, I do think it is nicely scoped to a good problem. I was bringing up some points to consider within the scope of the current charter - or, are you saying that the current charter is only meant to be scoped to file transfer applications? Vidya > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Tuesday, October 21, 2008 11:53 AM > To: Narayanan, Vidya > Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; > tana@ietf.org; p2pi@ietf.org; Eddy, Wesley M. (GRC-RCN0)[VZ]; > Bruce Davie > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > Hi, > > the goal for TANA and ALTO was to identify some subsets of > the overall problem space that are sufficiently well > understood that we can start to architect solutions. (And > limit ourselves to those subsets where the IETF would be an > appropriate body for this work.) > > There are certainly other parts of this problem that may be > ripe for discussion in the IETF, and chartering TANA and ALTO > by no means precludes this discussion from happening. I fully > expect the IETF to take on additional work related to this > general problem space in the future - we just had to start > somewhere, and TANA and ALTO is where we started. > > I'd strongly encourage folks that want to push forward > additional proposals for the IETF to take on in this space! > > Lars > > On 2008-10-21, at 14:33, ext Narayanan, Vidya wrote: > > I'll start by saying that I do like the charter and believe > that it is > > scoped correctly. > > > > I do, however, share some of the concerns that Nicholas has > raised. > > We are talking about bulk data p2p transfers here, not necessarily > > just limited to file transfers. This does mean p2p models > of video, > > games that exchange large amounts of data (e.g., World of > Warcraft), > > large medical data (e.g., high resolution imaging) transfer, etc. > > fall into this category. Of course, for some of these > applications, > > the answer may simply be that TANA is not applicable and > hence, should > > not be used. However, I do think there are more grades to this. > > > > Another interesting piece of data is that for the first > time in many > > years, http has overtaken p2p traffic in some markets, primarily > > driven by video download applications such as YouTube. > Thanks to http > > being the common firewall transport mechanism, much of the > video now > > runs over TCP. So, is it really as cut and dry as the bulk > data P2P > > traffic needing to yield to Internet traffic? As long as > it is about > > some background file transfer, perhaps that philosophy will > just work. > > But, if the P2P app is also a video app, the answer is > probably more > > complex. > > > > There is no doubt that this charter is attempting to tackle a very > > important issue. But, it would be good to think about what > grades we > > may need to address here. > > > > Regards, > > Vidya > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 12:09:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7292D28C195; Tue, 21 Oct 2008 12:09:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0988A28C115; Tue, 21 Oct 2008 12:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2dLUNXVjrSZ6; Tue, 21 Oct 2008 12:09:18 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 0F6E628C12C; Tue, 21 Oct 2008 12:09:17 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 21 Oct 2008 12:10:13 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 12:10:11 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Oct 2008 15:10:10 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Oct 2008 19:10:10 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 21 Oct 2008 12:10:06 -0700 From: Reinaldo Penno To: Stanislav Shalunov , , , TSV Area Message-ID: Thread-Topic: [p2pi] TANA proposed charter Thread-Index: AckzsKCxhNKFLvjOA0yzFk1DaglkbQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 21 Oct 2008 19:10:10.0382 (UTC) FILETIME=[A34DDEE0:01C933B0] Subject: Re: [p2pi] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0471364895==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0471364895== Content-type: multipart/alternative; boundary="B_3307435807_26597219" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3307435807_26597219 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I support this WG and intend to submit a draft on P2P multiple connections before the deadline. Thanks, Reinaldo On 10/21/08 6:17 AM, "Stanislav Shalunov" wrote: > At the BoF in Dublin, we observed strong interest and consensus that the TANA > work should go forward as a working group. Does the following proposed > charter, based on the BoF description, capture what the community was > interested in? > > Thanks, -- Stas > > > > Techniques for Advanced Networking Applications (TANA) WG > > Chair(s): > TBD > > Transport Area Director(s): > * Magnus Westerlund > * Lars Eggert > > Transport Area Advisor: > * Lars Eggert > > Mailing Lists: > > General Discussion: tana@ietf.org > To Subscribe: tana-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/tana/ > > Description of Working Group: > > The TANA WG is chartered to standardize a congestion control mechanism that > should saturate the bottleneck, maintain low delay, and yield to standard TCP. > > Applications that transmit large amounts of data for a long time with > congestion-limited TCP, but without ECN fill the buffer at the head of the > bottleneck link. This increases the delay experienced by other applications. > In the best case, with an ideally sized buffer of one RTT, the delay doubles. > In some cases, the extra delay may be much larger. This is a particularly > acute and common case is when P2P applications upload over thin home uplinks: > delays in these cases can sometimes be of the order of seconds. > > The IETF's standard end-to-end transport protocols have not been designed to > minimize the extra delay introduced by them into the > network. TCP, as a side effect of filling the buffer until it experiences > drop-tail loss, effectively maximizes the delay. While this works well for > applications that are not delay-sensitive, it harms interactive applications > that share the same bottleneck. VoIP and games are particularly affected, but > even web browsing may become problematic. > > TANA is a transport-area WG that will focus on broadly applicable techniques > that allow large amounts of data to be consistently transmitted without > substantially affecting the delays experienced by other users and > applications. > > The WG will work on the following: > > (1) An experimental congestion control algorithm for less-than-best-effort > "background" transmissions, i.e., an algorithm that attempts to scavenge > otherwise idle bandwidth for its transmissions in a way that minimizes > interference with regular best-effort traffic. > > Desired features of such an algorithm are: > * saturate the bottleneck, > * eliminate long standing queues and thus keep delay low when no other traffic > is present, > * quickly yield to regular best-effort traffic that uses standard TCP > congestion control, > * add little to the queueing delays induced by TCP traffic, > * operate well in today's typical networks with FIFO queueing with drop-tail > discipline, > * where available, use explicit congestion notification (ECN), active queue > management (AQM), and/or end-to-end differentiated services (DiffServ). > > Application of this algorithm to existing transport protocols (TCP, SCTP, > DCCP) is expected to occur in the working groups that maintain those > protocols. > > (2) A document that clarifies the current practices of application design and > reasons behind them and discusses the tradeoffs surrounding the use of many > concurrent transport connections to one peer and/or to different peers. > > Standard Internet congestion control result in different transport connections > sharing bottleneck capacity. When an application uses several unchoked and not > rate-limited transport connections to transfer through a bottleneck, it may > obtain a larger fraction of the bottleneck than if it had used fewer > connections. Although capacity is the most commonly considered bottleneck > resource, middlebox state table entries are also an important resource for an > end system communication. Other resource types may exist, and the guidelines > are expected to comprehensively discuss them. > > Applications use a variety of techniques to mitigate these concerns. These > techniques have not always been reviewed by the IETF and their interaction > with TCP dynamics is poorly understood. The WG document the known techniques, > discussing the consequences and, where appropriate, provide guidance to > application designers. > > (3) The WG will discuss how to best take into account prior work in the area. > The outcome will be either incorporated into the document specifying the > experimental congestion control algorithm or into a separate document > summarizing prior work. > > > > Goals and Milestones > > TBD Submit "Multiple Transport Connections in Applications Design" to the > IESG for consideration as an Informational RFC > TBD Submit "Transport for Advanced Networking Applications (TANA)" to the > IESG for consideration as an Experimental RFC > > > Internet-Drafts > > Transport for Advanced Networking Applications (TANA) Problem Statement > http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.t > xt > > No Requests for Comments > > > > > -- > Stanislav Shalunov > > > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi --B_3307435807_26597219 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [p2pi] TANA proposed charter I support this WG and intend to submit a draft on P2P multiple connections= before the deadline.

Thanks,

Reinaldo


On 10/21/08 6:17 AM, "Stanislav Shalunov" <shalunov@shlang.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>At the BoF in Dublin, we observed strong interes= t and consensus that the TANA work should go forward as a working group. &nb= sp;Does the following proposed charter, based on the BoF description, captur= e what the community was interested in?

Thanks,  -- Stas



Techniques for Advanced Networking Applications (TANA) WG

Chair(s):
TBD

Transport Area Director(s):
* Magnus Westerlund <magnus.wes= terlund@ericsson.com>
* Lars Eggert <lars.eggert@nokia.com= >

Transport Area Advisor:
* Lars Eggert <lars.eggert@nokia.com= >

Mailing Lists:

General Discussion: tana@ietf.org
To Subscribe: tana-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ie= tf.org/mail-archive/web/tana/

Description of Working Group:

The TANA WG is chartered to standardize a congestion control mechanism that= should saturate the bottleneck, maintain low delay, and yield to standard T= CP.

Applications that transmit large amounts of data for a long time with conge= stion-limited TCP, but without ECN fill the buffer at the head of the bottle= neck link. This increases the delay experienced by other applications. In th= e best case, with an ideally sized buffer of one RTT, the delay doubles. In = some cases, the extra delay may be much larger. This is a particularly acute= and common case is when P2P applications upload over thin home uplinks: del= ays in these cases can sometimes be of the order of seconds.

The IETF's standard end-to-end transport protocols have not been designed t= o minimize the extra delay introduced by them into the
network. TCP, as a side effect of filling the buffer until it experiences d= rop-tail loss, effectively maximizes the delay. While this works well for ap= plications that are not delay-sensitive, it harms interactive applications t= hat share the same bottleneck. VoIP and games are particularly affected, but= even web browsing may become problematic.

TANA is a transport-area WG that will focus on broadly applicable technique= s that allow large amounts of data to be consistently transmitted without su= bstantially affecting the delays experienced by other users and applications= .

The WG will work on the following:

(1) An experimental congestion control algorithm for less-than-best-effort = "background" transmissions, i.e., an algorithm that attempts to sc= avenge otherwise idle bandwidth for its transmissions in a way that minimize= s interference with regular best-effort traffic.

Desired features of such an algorithm are:
* saturate the bottleneck,
* eliminate long standing queues and thus keep delay low when no other traf= fic is present,
* quickly yield to regular best-effort traffic that uses standard TCP conge= stion control,
* add little to the queueing delays induced by TCP traffic,
* operate well in today's typical networks with FIFO queueing with drop-tai= l discipline,
* where available, use explicit congestion notification (ECN), active queue= management (AQM), and/or end-to-end differentiated services (DiffServ).

Application of this algorithm to existing transport protocols (TCP, SCTP, D= CCP) is expected to occur in the working groups that maintain those protocol= s.

(2) A document that clarifies the current practices of application design a= nd reasons behind them and discusses the tradeoffs surrounding the use of ma= ny concurrent transport connections to one peer and/or to different peers.
Standard Internet congestion control result in different transport connecti= ons sharing bottleneck capacity. When an application uses several unchoked a= nd not rate-limited transport connections to transfer through a bottleneck, = it may obtain a larger fraction of the bottleneck than if it had used fewer = connections. Although capacity is the most commonly considered bottleneck re= source, middlebox state table entries are also an important resource for an = end system communication. Other resource types may exist, and the guidelines= are expected to comprehensively discuss them.

Applications use a variety of techniques to mitigate these concerns.  = These techniques have not always been reviewed by the IETF and their interac= tion with TCP dynamics is poorly understood.  The WG document the known= techniques, discussing the consequences and, where appropriate, provide gui= dance to application designers.

(3) The WG will discuss how to best take into account prior work in the are= a.  The outcome will be either incorporated into the document specifyin= g the experimental congestion control algorithm or into a separate document = summarizing prior work.



Goals and Milestones

TBD  Submit "Multiple Transport Connections in Applications Desig= n" to the IESG for consideration as an Informational RFC
TBD  Submit "Transport for Advanced Networking Applications (TANA= )" to the IESG for consideration as an Experimental RFC


Internet-Drafts

Transport for Advanced Networking Applications (TANA) Problem Statement
http://www.ietf.org/internet-drafts/draft-shalunov-tana-prob= lem-statement-01.txt

No Requests for Comments



 
--
 Stan= islav Shalunov <http://shlang.com/> <= BR>
  <http:/= /feeds.feedburner.com/~r/shlang/~6/1>
 


___________= ____________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/m= ailman/listinfo/p2pi
--B_3307435807_26597219-- --===============0471364895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0471364895==-- From p2pi-bounces@ietf.org Tue Oct 21 12:13:52 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C2128C197; Tue, 21 Oct 2008 12:13:52 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C07B28C133; Tue, 21 Oct 2008 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, 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 NkfJBB+TFnkV; Tue, 21 Oct 2008 12:13:50 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A01463A6B8E; Tue, 21 Oct 2008 12:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224616505; x=1256152505; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Nicholas=20Weaver=20|CC:=20 Stanislav=20Shalunov=20,=20TSV=20Are a=20,=0D=0A=20=20=20=20=20=20=20=20"ta na@ietf.org"=20,=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"Eddy,=0D=0A=20W esley=20M.=20(GRC-RCN0)[VZ]"=20 |Date:=20Tue,=2021=20Oct=202008=2012:14:59=20-0700 |Subject:=20RE:=20[p2pi]=20[tana]=20=20[tsv-area]=20TANA =20proposed=20charter|Thread-Topic:=20[p2pi]=20[tana]=20 =20[tsv-area]=20TANA=20proposed=20charter|Thread-Index: =20AckzrfLmZQY1ELVSTK+ZxrtKaRzi3AAAzvAQ|Message-ID:=20|References:=20=0D=0A=20=0D=0A=20<36BFC323-FDD5- 42DD-9A17-F32DDE7DDF5E@cisco.com>=0D=0A=20<9F472A6A-F3F3- 4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu>=0D=0A=20<19AE9A F4-E857-41EF-BF3E-B831F4EB8159@shlang.com>=0D=0A=20<4D4C2 826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>=0D=0A =20=0D=0A=20<086D03E5-61BE-43F5-A750-3539AF4 7F13E@ICSI.Berkeley.EDU>|In-Reply-To:=20<086D03E5-61BE-43 F5-A750-3539AF47F13E@ICSI.Berkeley.EDU>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5411"=3B=20a=3D"11138575"; bh=QcMH0hJrvEfcNxe4JVHsvQrP4SKDea3A34EYOc91c5M=; b=UPF/epjAejIOanMqNqDqTKu2xS8PA4S7oWN0KQawih8jsgjGdSHAQCfS n1RKjWm6WFHWtefRa3oGRX4MyVTu18gnc/VngcPFl19zYp5LvskV2ELkw fPbis+jslNQa2/8YjOm0oVNLrf554ultPKyyUWwK7/nIONFQ2mHLon72R o=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11138575" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 12:15:04 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJF3X3029344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 12:15:04 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJF2Nx028013 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 12:15:03 -0700 (PDT) Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:15:02 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:15:01 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 21 Oct 2008 12:15:00 -0700 From: "Narayanan, Vidya" To: Nicholas Weaver Date: Tue, 21 Oct 2008 12:14:59 -0700 Thread-Topic: [p2pi] [tana] [tsv-area] TANA proposed charter Thread-Index: AckzrfLmZQY1ELVSTK+ZxrtKaRzi3AAAzvAQ Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> In-Reply-To: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "tana@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Re-sending due to some earlier errors.. Sorry about the multiple copies to some of you. > -----Original Message----- > From: Nicholas Weaver [mailto:nweaver@ICSI.Berkeley.EDU] > Sent: Tuesday, October 21, 2008 11:51 AM > To: Narayanan, Vidya > Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; tana@ietf.org; > p2pi@ietf.org; Eddy, Wesley M. (GRC-RCN0)[VZ] > Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter > > > On Oct 21, 2008, at 11:33 AM, Narayanan, Vidya wrote: > > > I'll start by saying that I do like the charter and believe > that it is > > scoped correctly. > > > > I do, however, share some of the concerns that Nicholas has > raised. > > We are talking about bulk data p2p transfers here, not necessarily > > just limited to file transfers. This does mean p2p models > of video, > > games that exchange large amounts of data (e.g., World of > Warcraft), > > large medical data (e.g., high resolution imaging) transfer, etc. > > fall into this category. Of course, for some of these > applications, > > the answer may simply be that TANA is not applicable and > hence, should > > not be used. However, I do think there are more grades to this. > > Well, it also depends too: > > The medical data is point to point, not P2P. A single TCP flow works > well, and by being on real network, shouldn't experience the buffer > issues present in home gateways, and by being a single flow, doesn't > have the congestion-monopolization properties that P2P transfer > programs have. > > Warcraft is not using P2P for playing, rather it is using P2P to save > money in the data transfer of "patches", which include large amounts > of content (textures, models, etc) (thus my rant on cost shifting). > I was not necessarily talking about the application models that exist today alone, but, was trying to see how future-proof this work can be. But, world of warcraft is probably not the right example here :) Vidya _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 12:14:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478D728C133; Tue, 21 Oct 2008 12:14:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E657E3A6B8F; Tue, 21 Oct 2008 12:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.16 X-Spam-Level: X-Spam-Status: No, score=-103.16 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, 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 mexPmLHSJ6No; Tue, 21 Oct 2008 12:14:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E9D8428C133; Tue, 21 Oct 2008 12:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224616540; x=1256152540; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Lars=20Eggert=20|CC:=20Nicholas =20Weaver=20,=0D=0A=20=20=20 =20=20=20=20=20Stanislav=20Shalunov=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20TSV=20Area=20,=20"tana@ietf.org"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"Eddy,=20Wesley=20M .=0D=0A=20(GRC-RCN0)[VZ]"=20,=0D =0A=20=20=20=20=20=20=20=20Bruce=20Davie=20|Date:=20Tue,=2021=20Oct=202008=2012:15:35=20-0700 |Subject:=20RE:=20[tana]=20[p2pi]=20[tsv-area]=20TANA=20p roposed=20charter|Thread-Topic:=20[tana]=20[p2pi]=20[tsv- area]=20TANA=20proposed=20charter|Thread-Index:=20Ackzrnc owLH5GLYYTk2utGnctUsH/QAAtshA|Message-ID:=20 |References:=20=0D=0A=20=0D=0A=20<36BFC323-FDD5-42DD-9A17- F32DDE7DDF5E@cisco.com>=0D=0A=20<9F472A6A-F3F3-4616-9ACE- 4BD24D77FBCD@icsi.berkeley.edu>=0D=0A=20<19AE9AF4-E857-41 EF-BF3E-B831F4EB8159@shlang.com>=0D=0A=20<4D4C2826-077A-4 948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>=0D=0A=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5411"=3B=20a=3D"11138589"; bh=bUpkV2bTYyapoNgSmzBcFK9J4dXniZHce9MA7YZGScY=; b=ZUe6z59i2b5D0NRMo2+WpB8RlvtCDfChgCp1zcVIbOXaL0L5BUiqRSaM 5Lz3OI+sLq7oCkJ00yaNsRb8TD0O62l9XMNC2LuulV5YDbcO8hb2XOCn5 zm06buYewoFEwmfrKPDAXmVH9swenwnPkBYX0Tj55DO5lfk22MHm1biuU 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11138589" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 12:15:39 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJFdYO029396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 12:15:39 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LJFcDK022058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 12:15:38 -0700 Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:15:38 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:15:38 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 21 Oct 2008 12:15:37 -0700 From: "Narayanan, Vidya" To: Lars Eggert Date: Tue, 21 Oct 2008 12:15:35 -0700 Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: AckzrncowLH5GLYYTk2utGnctUsH/QAAtshA Message-ID: References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu> <19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tana@ietf.org" , Nicholas Weaver , "p2pi@ietf.org" , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Speaking for TANA, I do think it is nicely scoped to a good problem. I was bringing up some points to consider within the scope of the current charter - or, are you saying that the current charter is only meant to be scoped to file transfer applications? Vidya > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Tuesday, October 21, 2008 11:53 AM > To: Narayanan, Vidya > Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; tana@ietf.org; > p2pi@ietf.org; Eddy, Wesley M. (GRC-RCN0)[VZ]; Bruce Davie > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > Hi, > > the goal for TANA and ALTO was to identify some subsets of the overall > problem space that are sufficiently well understood that we can start > to architect solutions. (And limit ourselves to those subsets where > the IETF would be an appropriate body for this work.) > > There are certainly other parts of this problem that may be ripe for > discussion in the IETF, and chartering TANA and ALTO by no means > precludes this discussion from happening. I fully expect the IETF to > take on additional work related to this general problem space in the > future - we just had to start somewhere, and TANA and ALTO is where we > started. > > I'd strongly encourage folks that want to push forward additional > proposals for the IETF to take on in this space! > > Lars > > On 2008-10-21, at 14:33, ext Narayanan, Vidya wrote: > > I'll start by saying that I do like the charter and believe > that it is > > scoped correctly. > > > > I do, however, share some of the concerns that Nicholas has > raised. > > We are talking about bulk data p2p transfers here, not necessarily > > just limited to file transfers. This does mean p2p models > of video, > > games that exchange large amounts of data (e.g., World of > Warcraft), > > large medical data (e.g., high resolution imaging) transfer, etc. > > fall into this category. Of course, for some of these > applications, > > the answer may simply be that TANA is not applicable and > hence, should > > not be used. However, I do think there are more grades to this. > > > > Another interesting piece of data is that for the first > time in many > > years, http has overtaken p2p traffic in some markets, primarily > > driven by video download applications such as YouTube. > Thanks to http > > being the common firewall transport mechanism, much of the > video now > > runs over TCP. So, is it really as cut and dry as the bulk > data P2P > > traffic needing to yield to Internet traffic? As long as > it is about > > some background file transfer, perhaps that philosophy will > just work. > > But, if the P2P app is also a video app, the answer is > probably more > > complex. > > > > There is no doubt that this charter is attempting to tackle a very > > important issue. But, it would be good to think about what > grades we > > may need to address here. > > > > Regards, > > Vidya > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:12:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F46E3A6B97; Tue, 21 Oct 2008 13:12:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09893A6A15; Tue, 21 Oct 2008 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 nh3272aEtcfv; Tue, 21 Oct 2008 13:12:29 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 711FD3A6B52; Tue, 21 Oct 2008 13:12:29 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13467101; Tue, 21 Oct 2008 16:13:43 -0400 Message-Id: From: Marshall Eubanks To: Stanislav Shalunov In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 16:13:41 -0400 References: X-Mailer: Apple Mail (2.929.2) Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I think that over all this is a decent charter and I support and hope to participate in this work. Some comments and nits follow. (I, by the way, have no trouble with the proposed name.) Regards Marshall On Oct 21, 2008, at 9:17 AM, Stanislav Shalunov wrote: > At the BoF in Dublin, we observed strong interest and consensus that > the TANA work should go forward as a working group. Does the > following proposed charter, based on the BoF description, capture > what the community was interested in? > > Thanks, -- Stas > > > > Techniques for Advanced Networking Applications (TANA) WG > > Chair(s): > TBD > > Transport Area Director(s): > * Magnus Westerlund > * Lars Eggert > > Transport Area Advisor: > * Lars Eggert > > Mailing Lists: > > General Discussion: tana@ietf.org > To Subscribe: tana-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/tana/ > > Description of Working Group: > > The TANA WG is chartered to standardize a congestion control > mechanism that should saturate the bottleneck, maintain low delay, > and yield to standard TCP. > Should this read "should saturate bottlenecks while retaining fairness" ? > Applications that transmit large amounts of data for a long time > with congestion-limited TCP, but without ECN fill the buffer at the > head of s/ECN/ECN, / > the bottleneck link. This increases the delay experienced by other > applications. In the best case, with an ideally sized buffer of one > RTT, the delay doubles. In some cases, the extra delay may be much > larger. This is a particularly acute and common case is when P2P > applications upload over thin home uplinks: delays in these cases > can sometimes be of the order of seconds. > > The IETF's standard end-to-end transport protocols have not been > designed to minimize the extra delay introduced by them into the > network. TCP, as a side effect of filling the buffer until it > experiences drop-tail loss, effectively maximizes the delay. While > this works well for applications that are not delay-sensitive, it > harms interactive applications that share the same bottleneck. VoIP > and games are particularly affected, but even web browsing may > become problematic. > > TANA is a transport-area WG that will focus on broadly applicable > techniques that allow large amounts of data to be consistently > transmitted without substantially affecting the delays experienced > by other users and applications. > > The WG will work on the following: > > (1) An experimental congestion control algorithm for less-than-best- > effort "background" transmissions, i.e., an algorithm that attempts > to scavenge otherwise idle bandwidth for its transmissions in a way > that minimizes interference with regular best-effort traffic. > > Desired features of such an algorithm are: > * saturate the bottleneck, > * eliminate long standing queues and thus keep delay low when no > other traffic is present, > * quickly yield to regular best-effort traffic that uses standard > TCP congestion control, > * add little to the queueing delays induced by TCP traffic, > * operate well in today's typical networks with FIFO queueing with > drop-tail discipline, > * where available, use explicit congestion notification (ECN), > active queue management (AQM), and/or end-to-end differentiated > services (DiffServ). > > Application of this algorithm to existing transport protocols (TCP, > SCTP, DCCP) is expected to occur in the working groups that maintain > those protocols. Are there FEC issues here ? I see possibly a couple : - FEC may have fairness / congestion control issues in this context as it involves bandwidth usage that scales with the underlying application, and yet may be separately controlled. In general it is assumed that, say, a 30% FEC is "OK" if the underlying application uses congestion control, but if you are trying to saturate a bottleneck that may not be true if the FEC is added on top of the saturating flow. - in a scavenger service it might be very useful to have a mechanism to distinguish between control and other critical data, which might benefit from FEC, and the mass of the data, which might not need or warrant FEC. Some standardized means of signaling this might be useful. > > > (2) A document that clarifies the current practices of application > design and reasons behind them and discusses the tradeoffs > surrounding the use of many concurrent transport connections to one > peer and/or to different peers. > > Standard Internet congestion control result in different transport > connections sharing bottleneck capacity. When an application uses > several unchoked and not rate-limited transport connections to > transfer through a bottleneck, it may obtain a larger fraction of > the bottleneck than if it had used fewer connections. The above wording is not clear to me. Are you referring to TCP in the above sentence ? If so, be specific. > Although capacity is the most commonly considered bottleneck > resource, middlebox state table entries are also an important > resource for an end system communication. > Other resource types may exist, and the guidelines are expected to > comprehensively discuss them. > > Applications use a variety of techniques to mitigate these > concerns. These techniques have not always been reviewed by the > IETF and their interaction with TCP dynamics is poorly understood. > The WG document the known techniques, discussing the consequences > and, where appropriate, s/The WG document/The WG will document/ > provide guidance to application designers. > > (3) The WG will discuss how to best take into account prior work in > the area. The outcome will be either incorporated into the document > specifying the experimental congestion control algorithm or into a > separate document summarizing prior work. > > > > Goals and Milestones > > TBD Submit "Multiple Transport Connections in Applications Design" > to the IESG for consideration as an Informational RFC > TBD Submit "Transport for Advanced Networking Applications (TANA)" > to the IESG for consideration as an Experimental RFC > > > Internet-Drafts > > Transport for Advanced Networking Applications (TANA) Problem > Statement > http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt > > No Requests for Comments > > > > -- > Stanislav Shalunov > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:25:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14CF28C1AE; Tue, 21 Oct 2008 13:25:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7248528C158; Tue, 21 Oct 2008 13:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[AWL=0.993, BAYES_00=-2.599, 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 pJRLMJ9RoB4g; Tue, 21 Oct 2008 13:25:37 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3FB543A6804; Tue, 21 Oct 2008 13:25:37 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LKQkYl025369; Tue, 21 Oct 2008 13:26:51 -0700 (PDT) Message-Id: <1B953601-8833-4AB0-B4AE-4D517F4243F2@icsi.berkeley.edu> From: Nicholas Weaver To: Ted Faber In-Reply-To: <20081021202327.GE64367@zod.isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 13:26:46 -0700 References: <20081021165051.GA64367@zod.isi.edu> <8A620FD1-9B69-4E5A-BBFD-90975DFA783F@shlang.com> <20081021202327.GE64367@zod.isi.edu> X-Mailer: Apple Mail (2.929.2) Cc: tana@ietf.org, Nicholas Weaver , p2pi@ietf.org, TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Why not: Scavenger Network Congestion Protocols? Since this is the real description of what the group is trying to do is congestion control protocols for scavenger services. On Oct 21, 2008, at 1:23 PM, Ted Faber wrote: > On Tue, Oct 21, 2008 at 10:11:37AM -0700, Stanislav Shalunov wrote: >> On Oct 21, 2008, at 9:50 AM, Ted Faber wrote: >>> [The TANA name] should change. >> >> >> Would it be sufficient to change the name on the documents and not in >> the mailing list and the WG name? >> >> The WG name will go after we're done. The documents will remain. >> This would also allow us to choose the names when the document bodies >> are already written -- always a plus for relevance... > > If you want people who are interested in congestion control to take > part > in your group, "Techniques for Advanced Networking Applications" > will do > nothing to attract their attention. It is completely generic phrase. > It could refer to UTF encoding strategies or peer-to-peer load > balancing. > > It may not be important to you to attract congestion control > expertise. > If it is, I recommend changing the name to something that will get > busy congestion control people to read past the name. > > YMMV. > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F0128C1A5; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747F93A693C for ; Mon, 29 Sep 2008 10:54:54 -0700 (PDT) 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 89NRjwnzRdRc for ; Mon, 29 Sep 2008 10:54:53 -0700 (PDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id A78673A6AF4 for ; Mon, 29 Sep 2008 10:54:53 -0700 (PDT) Received: from gateout02 (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 26D284BD187; Mon, 29 Sep 2008 17:54:29 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02 via smtad (C8.MAIN.3.45U) with ESMTP id XID753miCR3d2592Xo2; Mon, 29 Sep 2008 17:54:29 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID753miCR3d2592Xo2 Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 11:54:28 -0600 Message-Id: From: Lisa Dusseault To: p2pi@ietf.org, Dave Ward Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 10:54:27 -0700 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 29 Sep 2008 17:54:29.0084 (UTC) FILETIME=[6B6449C0:01C9225C] X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Subject: [p2pi] ASN utility X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org When the IESG looked at the proposed ALTO charter last week, Dave had some comments about ASNs which I'd like to follow up on by dragging Dave into the conversation. What I understand the ASN related suggestions so far to be, is to have the ALTO server return a list of ASN numbers to prefer or avoid. This sort of information could only be provided by an ISP-operated ALTO server. A peer, armed with this information, can do whatever they do today to figure out which IP address falls in which ASN. The P4P and Yale folks claim that returning a preference of ASNs helped their application tremendously. Dave, was your concern about discovering ASN being unnecessary, or about ranking of ASNs being unhelpful? Can you restate? Thanks, Lisa _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E7F28C1B8; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC693A6870; Mon, 29 Sep 2008 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NPUh4UpZGwRR; Mon, 29 Sep 2008 10:59:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6CFD13A6AD8; Mon, 29 Sep 2008 10:59:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,333,1220227200"; d="scan'208";a="22620573" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2008 17:59:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8THxkBa015728; Mon, 29 Sep 2008 13:59:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8THxkg1029412; Mon, 29 Sep 2008 17:59:46 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 13:59:46 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 13:59:46 -0400 In-Reply-To: <3AEC1BB7-D5EE-4E83-A5FB-18615D0D3DAB@osafoundation.org> References: <3AEC1BB7-D5EE-4E83-A5FB-18615D0D3DAB@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <9428A91F-D7AC-4C91-85CF-4A5EB3721589@cisco.com> From: David Ward Date: Mon, 29 Sep 2008 12:59:42 -0500 To: Lisa Dusseault X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 29 Sep 2008 17:59:46.0403 (UTC) FILETIME=[28875330:01C9225D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3146; t=1222711186; x=1223575186; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20ASN=20utility |Sender:=20 |To:=20Lisa=20Dusseault=20; bh=Y8YIyPUdAxuZpE5Fwd1oHlwafm7CD5GA/ZELeobJZRs=; b=bDiMxCrLzP8sY1m2ColGrK/43EzucxVmcaHJxHE+gJXw2ZknO2YsdV4K4k lV6lp6yfPmEx31XNShOgggxHByC7AopkoMZriTY/HYMjIOSt15+z1PbhVoyW qH2dxOYhcy; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: p2pi@ietf.org, IESG IESG Subject: Re: [p2pi] ASN utility X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lisa - My issue is that the charter has ASN as a viable item to return to a query without limiting how the ASN is to be gleaned. The solution you state below "avoid this ASN" is a bit different than an dynamically generated, ordered list of preferred ASN based on current routing "proximity" or "reachability." In addition, information about specific attributes and topologic information could be useful, e.g. AS path list (vs just AS origin information) for transit "hints." There could be a query "give me prefixes and/or ASN that are tagged w/ X community" (where the community represents SP preference. Another easy one to think about "give me servers|prefixes in AS X that don't traverse AS Y." There is obviously a large amount of routing data (passed in routing protocols along w/ other attributes associated with the prefix, peer, AS, exit point, policy, cost, topologic location, etc) that could be used in the future for very interesting preference schemes. Generally this information is passed in BGP or other routing/ signaling protocols. That would mean that the ALTO server would need to be a peer or member of the routing system to get this information and routing protocol extensions (e.g. BGP) may be necessary. Therefore, this interaction and these extensions would be in or out of charter. I was confused how far this would go. If instead you want to limit the server to passing "policy and preference information" which in this case is akin to a list of hand configured objects (e.g. list of ASN you want some client to prefer) that has no other relationship to the routing system, then let's put that in the charter. I assume the client in this case would get the ASN, "query" some looking-glass server and make decisions. I think there are a lot of very interesting services to think about when the ALTO server *is* a peer of the routing system but, if the WG doesn't want to go down this path ... I'd just like it clarified in the charter. If you want it watered down further, I'd like it stated in the charter that the outcome of the framework document will make it clear and please mention that it is specifically to be worked on. -DWard On Sep 29, 2008, at 12:38 PM, Lisa Dusseault wrote: > > When the IESG looked at the proposed ALTO charter last week, Dave > had some comments about ASNs which I'd like to follow up on by > dragging Dave into the conversation. > > What I understand the ASN related suggestions so far to be, is to > have the ALTO server return a list of ASN numbers to prefer or > avoid. This sort of information could only be provided by an ISP- > operated ALTO server. A peer, armed with this information, can do > whatever they do today to figure > out which IP address falls in which ASN. The P4P and Yale folks > claim that returning a preference of ASNs helped their application > tremendously. > > Dave, was your concern about discovering ASN being unnecessary, or > about ranking of ASNs being unhelpful? Can you recap? > > Thanks, > Lisa _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDB728C1BE; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC69E3A6BA1; Mon, 13 Oct 2008 05:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Hf45rhrvz8dl; Mon, 13 Oct 2008 05:22:44 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 930253A6B9B; Mon, 13 Oct 2008 05:22:41 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9DCNK6e030841; Mon, 13 Oct 2008 15:23:20 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9DCNJlJ030838; Mon, 13 Oct 2008 15:23:20 +0300 Date: Mon, 13 Oct 2008 15:23:19 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com> Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.93.3/8414/Sun Oct 12 06:30:50 2008 on otso.netcore.fi X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: p2pi@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Mon, 6 Oct 2008, IESG Secretary wrote: > - A requirements document. This document will list requirements for > the ALTO service, identifying, for example, what kind of information > P2P applications will need for optimizing their choices. ... I believe this work could be useful and would provide an improvement over existing p2p usage and traffic management. I'd be more comfortable with this effort if a recharter (this is a rather lightweight process) was needed after finishing the problem statement and the requirements. It would also encourage that people actually put some serious work on those before diving into solutions :-) There are significant design issues that will come up in the protocols and I'd expect that it would be helpful if those had already been dealt with in the requirements phase. For example, the current req document has: REQ. 4: ALTO Clients MUST be able to find out where to send ALTO queries. .. and the charter lists DHCP option or SRV record as examples. Both of these have issues in certain contexts. For example, must this discovery mechanism work across unmodified NAT boxes? DHCP option doesn't; SRV record in many contexts doesn't either (or otherwise you'll end up with the same "how to you discover the domain name under which you should look?" problem). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB3128C1C2; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0D13A6862; Tue, 14 Oct 2008 11:16:43 -0700 (PDT) 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 9CNUlqFbjFpX; Tue, 14 Oct 2008 11:16:42 -0700 (PDT) Received: from lear.cavebear.com (lear.cavebear.com [64.62.206.88]) by core3.amsl.com (Postfix) with ESMTP id 91C273A67F8; Tue, 14 Oct 2008 11:16:42 -0700 (PDT) Received: from hari-seldon.cavebear.com (dsl-63-249-89-222.cruzio.com [63.249.89.222]) (authenticated bits=0) by lear.cavebear.com (8.14.2/8.14.2) with ESMTP id m9EIGi8c015668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 11:16:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cavebear.com; s=04142008; t=1224008222; bh=epirsfWnlQP87xZrmV32qmXSF0QdzoOmMgrJIK 9THEw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=a Q6Kc+ebUJQ64CdR5/+rTuam9tVK9E31ThXA65lcrmN7QhYCTXdqVo/pBLuOMKBdftMI 5NDz/vhaqBSF4qR3g+hdCcsTupMu4uKpLZfcXXWN6fFWJZlzcBVpRqrO+DGsmsjTkF8 Jg6A5OWL7uyBSRkCREvo6PNlEOdnXDQ+JWps= Message-ID: <48F4E20B.8000609@cavebear.com> Date: Tue, 14 Oct 2008 11:16:43 -0700 From: Karl Auerbach User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Lars Eggert References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> In-Reply-To: <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: "p2pi@ietf.org" , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lars Eggert wrote: > FYI, there's at least one more proposal in this space: the Ono stuff > from Northwestern > (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). There was a > paper at SIGCOMM this year, and their system has the interesting feature > that it simply freeloads of Akamai's DNS entries in order to determine > who's close to whom. No "ALTO boxes" needed. Since you mentioned DNS as a proximity tool, I thought I'd go slightly awry and point out a bit of work I did a while back that, while not at itself at the application level, did try to address some application layer optimizations concerns that we had when I was working on binding video clients to video services. The main idea was that neither hop count, asn-path length, ICMP-Echo time, DNS answer time, nor TCP-connect-time are very good indicators of internet proximity for the purposes of applications that are going to make different kinds of demands and need different levels of service. And because such proximity questions are likely to be asked frequently, the cost of asking the question, and the delay incurred in asking that question, ought to be low. So what I did was to try to blend the notions of potential bandwidth and packet size dynamics (from the old integrated services work) with some ideas from the old multicast mtrace protocol. What I came up, and it was far, far from complete, was something that needed to live inside the router infrastructure, although not on any fast-path part of any router. I called the thing the "Fast Path Characterization Protocol". (The name may be misleading, the implementation was intended to find a path quickly, *not* that it would sit in any router fast-path switching logic.) So, here it is, 8+ years old: http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html --karl-- _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF5C28C1C6; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3802A3A6B71; Tue, 21 Oct 2008 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 SEXv1YHX-tjW; Tue, 21 Oct 2008 07:11:35 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 511523A6B67; Tue, 21 Oct 2008 07:11:35 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id B0E683281B2; Tue, 21 Oct 2008 09:12:14 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m9LECDGD030701; Tue, 21 Oct 2008 09:12:13 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 09:12:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 09:12:10 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsv-area] TANA proposed charter Thread-Index: Ackzf4E2/A548ra5Q0e9PUcmoA3VPAAAl5uw References: From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Stanislav Shalunov" , , , "TSV Area" X-OriginalArrivalTime: 21 Oct 2008 14:12:11.0822 (UTC) FILETIME=[02DA1CE0:01C93387] X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org The charter, as written looks reasonable to me. I just hate the name :). Even though you explained it before, "Advanced Network Applications" still bothers me as it's completely unspecific. Furthermore, I think that "Techniques" isn't well-scoped enough to limit the work properly as it seems to be focused on congestion control techniques, and not NAT traversal techniques, search techniques, etc. The way that the problem statement was described, I think what's really meant is "bulk transfer applications that want to be a good neighbor to real-time or other applications". I guess the challenge is that this doesn't produce a pronouncable acronym like TANA :). It should really be something like: "Minimizing Impact of Large Transfers" (MILT) "Concurrent Realtime And Bulk Applications" (CRABA) "Fast Transfers Adding Minimal Latency" (FTAML) "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- probably not a good one as it looks too much like "barfing" :) But if nobody else has a problem with the TANA name, I'll keep my mouth shut so we don't waste time and energy. There are bigger fish to fry! >-----Original Message----- >From: tsv-area-bounces@ietf.org >[mailto:tsv-area-bounces@ietf.org] On Behalf Of Stanislav Shalunov >Sent: Tuesday, October 21, 2008 9:17 AM >To: tana@ietf.org; p2pi@ietf.org; TSV Area >Subject: [tsv-area] TANA proposed charter > >At the BoF in Dublin, we observed strong interest and >consensus that the TANA work should go forward as a working >group. Does the following proposed charter, based on the BoF >description, capture what the community was interested in? > >Thanks, -- Stas > > > >Techniques for Advanced Networking Applications (TANA) WG > >Chair(s): >TBD > >Transport Area Director(s): >* Magnus Westerlund >* Lars Eggert > >Transport Area Advisor: >* Lars Eggert > >Mailing Lists: > >General Discussion: tana@ietf.org >To Subscribe: tana-request@ietf.org >In Body: (un)subscribe >Archive: http://www.ietf.org/mail-archive/web/tana/ > >Description of Working Group: > >The TANA WG is chartered to standardize a congestion control >mechanism that should saturate the bottleneck, maintain low >delay, and yield to standard TCP. > >Applications that transmit large amounts of data for a long >time with congestion-limited TCP, but without ECN fill the >buffer at the head of the bottleneck link. This increases the >delay experienced by other applications. In the best case, >with an ideally sized buffer of one RTT, the delay doubles. In >some cases, the extra delay may be much larger. This is a >particularly acute and common case is when P2P applications >upload over thin home uplinks: delays in these cases can >sometimes be of the order of seconds. > >The IETF's standard end-to-end transport protocols have not >been designed to minimize the extra delay introduced by them into the >network. TCP, as a side effect of filling the buffer until it >experiences drop-tail loss, effectively maximizes the delay. >While this works well for applications that are not >delay-sensitive, it harms interactive applications that share >the same bottleneck. VoIP and games are particularly affected, >but even web browsing may become problematic. > >TANA is a transport-area WG that will focus on broadly >applicable techniques that allow large amounts of data to be >consistently transmitted without substantially affecting the >delays experienced by other users and applications. > >The WG will work on the following: > >(1) An experimental congestion control algorithm for >less-than-best-effort "background" transmissions, i.e., an >algorithm that attempts to scavenge otherwise idle bandwidth >for its transmissions in a way that minimizes interference >with regular best-effort traffic. > >Desired features of such an algorithm are: >* saturate the bottleneck, >* eliminate long standing queues and thus keep delay low when >no other traffic is present, >* quickly yield to regular best-effort traffic that uses >standard TCP congestion control, >* add little to the queueing delays induced by TCP traffic, >* operate well in today's typical networks with FIFO queueing >with drop-tail discipline, >* where available, use explicit congestion notification (ECN), >active queue management (AQM), and/or end-to-end >differentiated services (DiffServ). > >Application of this algorithm to existing transport protocols >(TCP, SCTP, DCCP) is expected to occur in the working groups >that maintain those protocols. > >(2) A document that clarifies the current practices of >application design and reasons behind them and discusses the >tradeoffs surrounding the use of many concurrent transport >connections to one peer and/or to different peers. > >Standard Internet congestion control result in different >transport connections sharing bottleneck capacity. When an >application uses several unchoked and not rate-limited >transport connections to transfer through a bottleneck, it may >obtain a larger fraction of the bottleneck than if it had used >fewer connections. Although capacity is the most commonly >considered bottleneck resource, middlebox state table entries >are also an important resource for an end system >communication. Other resource types may exist, and the >guidelines are expected to comprehensively discuss them. > >Applications use a variety of techniques to mitigate these >concerns. These techniques have not always been reviewed by >the IETF and their interaction with TCP dynamics is poorly >understood. The WG document the known techniques, discussing >the consequences and, where appropriate, provide guidance to >application designers. > >(3) The WG will discuss how to best take into account prior >work in the area. The outcome will be either incorporated >into the document specifying the experimental congestion >control algorithm or into a separate document summarizing prior work. > > > >Goals and Milestones > >TBD Submit "Multiple Transport Connections in Applications >Design" to the IESG for consideration as an Informational RFC >TBD Submit "Transport for Advanced Networking Applications >(TANA)" to the IESG for consideration as an Experimental RFC > > >Internet-Drafts > >Transport for Advanced Networking Applications (TANA) Problem Statement >http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem >-statement-01.txt > >No Requests for Comments > > > >-- >Stanislav Shalunov > >Hacking Startups > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F5B28C1CB; Tue, 21 Oct 2008 13:28:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615303A6A92; Tue, 21 Oct 2008 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lT0BiFYV9aUC; Tue, 21 Oct 2008 09:03:50 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9094C3A69D9; Tue, 21 Oct 2008 09:03:50 -0700 (PDT) Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 21 Oct 2008 09:05:04 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.54.46.186]) with mapi; Tue, 21 Oct 2008 09:05:04 -0700 From: Murari Sridharan To: Lars Eggert , "ext Eddy, Wesley M. (GRC-RCN0)[VZ]" Date: Tue, 21 Oct 2008 09:05:02 -0700 Thread-Topic: [tsv-area] TANA proposed charter Thread-Index: Ackzje0SmIwJ7D23Qcy0xOrkwgQaQwACGOVg Message-ID: References: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> In-Reply-To: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: "p2pi@ietf.org" , "tana@ietf.org" , TSV Area Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Isn't the goal here to achieve lower than best-effort, so essentially "Low Priority TCP", assuming non-TCP traffic flows E2E we can make it more general and call it "Congestion control for low priority flows" Murari -----Original Message----- From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Tuesday, October 21, 2008 11:01 AM To: ext Eddy, Wesley M. (GRC-RCN0)[VZ] Cc: TSV Area; tana@ietf.org; p2pi@ietf.org Subject: Re: [tsv-area] TANA proposed charter Hi, On 2008-10-21, at 10:12, ext Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > The charter, as written looks reasonable to me. I just hate the name > :). the name was an ad hoc creation, and when it was picked, some of the stuff that ended up being ALTO was part of the TANA scope - so it needed to be broader. If we can come up with a better name I'm all ears (and you make several good suggestions below). What I'd like to avoid is a long discussion about a text string, when what I'd rather like to see is a discussion on whether the work we're going to attempt is reasonable. Lars > It should really be something like: > "Minimizing Impact of Large Transfers" (MILT) > "Concurrent Realtime And Bulk Applications" (CRABA) > "Fast Transfers Adding Minimal Latency" (FTAML) > "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- > probably not a good one as it looks too much like "barfing" :) I'm pretty sure CRABA would also have interesting soundex matches... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:28:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B34328C1CF; Tue, 21 Oct 2008 13:28:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6453A6B75; Tue, 21 Oct 2008 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 oplXI0TCk1gL; Tue, 21 Oct 2008 09:51:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 628DB3A6B74; Tue, 21 Oct 2008 09:51:13 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9LGorKW004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 09:50:54 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m9LGopJr017639; Tue, 21 Oct 2008 09:50:51 -0700 (PDT) (envelope-from faber) Date: Tue, 21 Oct 2008 09:50:51 -0700 From: Ted Faber To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" Message-ID: <20081021165051.GA64367@zod.isi.edu> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022310765==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2022310765== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wr= ote: > But if nobody else has a problem with the TANA name, I'll keep my mouth > shut so we don't waste time and energy. There are bigger fish to fry! It should change. I care about congestion control and nothing in the expansion of TANA indicated it was about congestion (to me). --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj+CGoACgkQaUz3f+Zf+XvQvwCcCrijia6+t0KYzP+J9GCxfKIc 1EkAniIYfFOhQfVjVitTZevQVU/GwHhY =h4jB -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- --===============2022310765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============2022310765==-- From p2pi-bounces@ietf.org Tue Oct 21 13:28:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3122D28C1D4; Tue, 21 Oct 2008 13:28:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A836A3A68F9; Tue, 21 Oct 2008 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 D9fJvdZKxmWJ; Tue, 21 Oct 2008 13:23:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id ABDB03A679F; Tue, 21 Oct 2008 13:23:31 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9LKNRoZ014524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 13:23:28 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m9LKNR8d021691; Tue, 21 Oct 2008 13:23:27 -0700 (PDT) (envelope-from faber) Date: Tue, 21 Oct 2008 13:23:27 -0700 From: Ted Faber To: Stanislav Shalunov Message-ID: <20081021202327.GE64367@zod.isi.edu> References: <20081021165051.GA64367@zod.isi.edu> <8A620FD1-9B69-4E5A-BBFD-90975DFA783F@shlang.com> Mime-Version: 1.0 In-Reply-To: <8A620FD1-9B69-4E5A-BBFD-90975DFA783F@shlang.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700 Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1725363828==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1725363828== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qOrJKOH36bD5yhNe" Content-Disposition: inline --qOrJKOH36bD5yhNe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2008 at 10:11:37AM -0700, Stanislav Shalunov wrote: > On Oct 21, 2008, at 9:50 AM, Ted Faber wrote: > >[The TANA name] should change. >=20 >=20 > Would it be sufficient to change the name on the documents and not in =20 > the mailing list and the WG name? >=20 > The WG name will go after we're done. The documents will remain. =20 > This would also allow us to choose the names when the document bodies =20 > are already written -- always a plus for relevance... If you want people who are interested in congestion control to take part in your group, "Techniques for Advanced Networking Applications" will do nothing to attract their attention. It is completely generic phrase. It could refer to UTF encoding strategies or peer-to-peer load balancing. It may not be important to you to attract congestion control expertise. If it is, I recommend changing the name to something that will get busy congestion control people to read past the name. YMMV. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --qOrJKOH36bD5yhNe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj+Oj8ACgkQaUz3f+Zf+Xs5RgCfZN0O0fqsbs7d2npezDyGKm2+ /RMAn2tjQ9M2BETgtv3KfVVgi0DdjKhl =fo/Q -----END PGP SIGNATURE----- --qOrJKOH36bD5yhNe-- --===============1725363828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1725363828==-- From p2pi-bounces@ietf.org Tue Oct 21 13:28:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACAA28C1B6; Tue, 21 Oct 2008 13:28:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713593A6B46 for ; Tue, 21 Oct 2008 09:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 gilDvbz3Mr0T for ; Tue, 21 Oct 2008 09:28:26 -0700 (PDT) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by core3.amsl.com (Postfix) with ESMTP id 4DA313A6B3E for ; Tue, 21 Oct 2008 09:28:26 -0700 (PDT) Received: (qmail 2408 invoked from network); 21 Oct 2008 16:23:01 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Oct 2008 16:23:01 -0000 Message-ID: <48FE01E5.5000302@asomi.com> Date: Tue, 21 Oct 2008 09:23:01 -0700 From: Caitlin Bestler User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Murari Sridharan References: <71ACFD76-A76F-4CCD-B675-BA5A984976BE@nokia.com> In-Reply-To: X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:45 -0700 Cc: TSV Area , "tana@ietf.org" , "p2pi@ietf.org" , "ext Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Murari Sridharan wrote: > Isn't the goal here to achieve lower than best-effort, so essentially "Low Priority TCP", > assuming non-TCP traffic flows E2E we can make it more general and call it "Congestion control > for low priority flows" > > Murari > A successful algorithm here would not necessarily "lower than" best-effort, because the "low priority' flow could actually achieve higher throughput than a conventional TCP flow. I believe that the key phrase in the proposed charter is very much on target -- that the "TANA flows" rapidly yield to conventional TCP. It is possible to both rapidly yield *and* to rapidly claim bandwidth that conventional TCP algorithms would have left unused. The extent to which a given algorithm can rapidly claim bandwidth without imperiling existing TCP traffic is of course something that the WG would have to review. But given the charter objective of "saturation" it is important to understand that this is not necessarily "low priority" traffic. It is undoubtedly very jitter-tolerant traffic that can be quite elastic in its bandwidth utilization for any short period of time. ----- Caitlin Bestler cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:31:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFCB3A68D3; Tue, 21 Oct 2008 13:31:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDB33A68D3; Tue, 21 Oct 2008 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Xd-we4JyHAH9; Tue, 21 Oct 2008 13:30:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DBF3E3A689E; Tue, 21 Oct 2008 13:30:58 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9LKVfm5018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 13:31:42 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m9LKVeEK021934; Tue, 21 Oct 2008 13:31:40 -0700 (PDT) (envelope-from faber) Date: Tue, 21 Oct 2008 13:31:40 -0700 From: Ted Faber To: Nicholas Weaver Message-ID: <20081021203140.GH64367@zod.isi.edu> References: <20081021165051.GA64367@zod.isi.edu> <8A620FD1-9B69-4E5A-BBFD-90975DFA783F@shlang.com> <20081021202327.GE64367@zod.isi.edu> <1B953601-8833-4AB0-B4AE-4D517F4243F2@icsi.berkeley.edu> Mime-Version: 1.0 In-Reply-To: <1B953601-8833-4AB0-B4AE-4D517F4243F2@icsi.berkeley.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: p2pi@ietf.org, tana@ietf.org, TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684561254==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0684561254== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtJ+CqYNzKB4ukR4" Content-Disposition: inline --vtJ+CqYNzKB4ukR4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2008 at 01:26:46PM -0700, Nicholas Weaver wrote: > Why not: >=20 > Scavenger Network Congestion Protocols? My ears would prick up for that. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --vtJ+CqYNzKB4ukR4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj+PCwACgkQaUz3f+Zf+XviBgCfQ7zYoZ2EuIiVBY2YnDAkjRKR NjQAn2PrYRV7kUXr/jhKjEkpfbwIis6M =oQ1Q -----END PGP SIGNATURE----- --vtJ+CqYNzKB4ukR4-- --===============0684561254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0684561254==-- From p2pi-bounces@ietf.org Tue Oct 21 13:37:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307DC28C1AA; Tue, 21 Oct 2008 13:37:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420AB28C1AA for ; Tue, 21 Oct 2008 13:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 N+wnzL38Mynh for ; Tue, 21 Oct 2008 13:37:18 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 5007E28C1A3 for ; Tue, 21 Oct 2008 13:37:18 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13467391; Tue, 21 Oct 2008 16:38:33 -0400 Message-Id: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com> From: Marshall Eubanks To: Lisa Dusseault In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 16:38:30 -0400 References: X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org Subject: Re: [p2pi] ASN utility X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: > > > When the IESG looked at the proposed ALTO charter last week, Dave > had some comments about ASNs which I'd like to follow up on by > dragging Dave into the conversation. > > What I understand the ASN related suggestions so far to be, is to > have the ALTO server return a list of ASN numbers to prefer or > avoid. This sort of information could only be provided by an ISP- > operated ALTO server. Are you sure about that ? A peer can (for example) query route views, or I (or a host of others) can send it BGP / address block tables. It would not be hard to collate address information with ASN and ASN paths and draw conclusions. I don't see why an ISP is necessarily involved. Regards Marshall > A peer, armed with this information, can do whatever they do today > to figure > out which IP address falls in which ASN. The P4P and Yale folks > claim that returning a preference of ASNs helped their application > tremendously. > > Dave, was your concern about discovering ASN being unnecessary, or > about ranking of ASNs being unhelpful? Can you restate? > > Thanks, > Lisa > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:42:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DAE3A6B96; Tue, 21 Oct 2008 13:42:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AA03A6B94; Tue, 21 Oct 2008 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=0.962, BAYES_00=-2.599, 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 OHlELgnjjYIm; Tue, 21 Oct 2008 13:42:33 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 623543A6804; Tue, 21 Oct 2008 13:42:33 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LKhUDf027272; Tue, 21 Oct 2008 13:43:31 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Karl Auerbach In-Reply-To: <48F4E20B.8000609@cavebear.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 13:43:30 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <48F4E20B.8000609@cavebear.com> X-Mailer: Apple Mail (2.929.2) Cc: "p2pi@ietf.org" , Nicholas Weaver , IESG IESG , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hey, stupid thought... Could you do proximity based on "who's your DNS resolver"? Do a few name lookups: one to register YOU as using YOUR DNS resolver to the remote coordinator, and one to get "who are other peers using the same resolver"? An ugly, UGLY hack, but it might be interesting to think about. Has anyone done this already? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 13:50:18 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBEC28C192; Tue, 21 Oct 2008 13:50:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7CAD3A679F for ; Tue, 21 Oct 2008 13:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 IG+mXbdPQlkz for ; Tue, 21 Oct 2008 13:50:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 346453A6B94 for ; Tue, 21 Oct 2008 13:50:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,460,1220227200"; d="scan'208";a="25179414" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2008 20:51:29 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9LKpTk3022233; Tue, 21 Oct 2008 16:51:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9LKpTnI006968; Tue, 21 Oct 2008 20:51:29 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 16:51:29 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 16:50:46 -0400 In-Reply-To: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com> References: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <10062CD4-88B8-47EC-8809-D02486A3D05D@cisco.com> From: David Ward Date: Tue, 21 Oct 2008 15:50:40 -0500 To: Marshall Eubanks X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 21 Oct 2008 20:50:46.0105 (UTC) FILETIME=[B0E01C90:01C933BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1727; t=1224622289; x=1225486289; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[p2pi]=20ASN=20utility |Sender:=20 |To:=20Marshall=20Eubanks=20; bh=q08cCYE058djRDBMPQjp54f/T17xAYh/7l8PffnO3Gs=; b=jIxw+1eOS3PC1lTo1KxKM5QvN4arQzRbJC7qa704eCnsX4GVcdL6wIqWQ8 jMKYSncbwuvkdffregIqiRRD0KAw3WW6s9ecqHnxY+i7usc4W8klzz155yHq aZwofebcj6; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: p2pi@ietf.org, Lisa Dusseault Subject: Re: [p2pi] ASN utility X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Marshall - I mentioned that this is one deployment model and is as it works today but, the charter is unclear if they want to support any other model. I do think it is considerably harder to deduce a current AS_path from simple prefix -> ASN information. -DWard On Oct 21, 2008, at 3:38 PM, Marshall Eubanks wrote: > > On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: > >> >> >> When the IESG looked at the proposed ALTO charter last week, Dave >> had some comments about ASNs which I'd like to follow up on by >> dragging Dave into the conversation. >> >> What I understand the ASN related suggestions so far to be, is to >> have the ALTO server return a list of ASN numbers to prefer or >> avoid. This sort of information could only be provided by an ISP- >> operated ALTO server. > > Are you sure about that ? > > A peer can (for example) query route views, or I (or a host of > others) can send it BGP / address block tables. It would not be > hard to collate address information with ASN and ASN paths and draw > conclusions. I don't see why an ISP is necessarily involved. > > Regards > Marshall > > > >> A peer, armed with this information, can do whatever they do today >> to figure >> out which IP address falls in which ASN. The P4P and Yale folks >> claim that returning a preference of ASNs helped their application >> tremendously. >> >> Dave, was your concern about discovering ASN being unnecessary, or >> about ranking of ASNs being unhelpful? Can you restate? >> >> Thanks, >> Lisa >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 14:05:04 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9363A6B7F; Tue, 21 Oct 2008 14:05:04 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7643A6B7F for ; Tue, 21 Oct 2008 14:05:03 -0700 (PDT) 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=[AWL=0.000, 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 WEhLqtaAl-4a for ; Tue, 21 Oct 2008 14:05:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7C19C3A6774 for ; Tue, 21 Oct 2008 14:05:01 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9LL5eCK000394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 16:05:41 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9LL5elr025734; Tue, 21 Oct 2008 16:05:40 -0500 (CDT) Message-ID: <48FE4424.2000309@alcatel-lucent.com> Date: Tue, 21 Oct 2008 16:05:40 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nicholas Weaver References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <48F4E20B.8000609@cavebear.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nicholas Weaver wrote: > Hey, stupid thought... > = > Could you do proximity based on "who's your DNS resolver"? Do a few = > name lookups: one to register YOU as using YOUR DNS resolver to the = > remote coordinator, and one to get "who are other peers using the same = > resolver"? > = > An ugly, UGLY hack, but it might be interesting to think about. > = > Has anyone done this already? Doesn't Ono [1] do that? Or am I missing something? CDNs also use DNS redirects to redirect clients to nearest servers. [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems, Proc. of ACM SIGCOMM 2008, August 2008. Thanks, - vijay -- = Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 14:08:04 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FF73A68FC; Tue, 21 Oct 2008 14:08:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95EB3A6774 for ; Tue, 21 Oct 2008 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 ENf9dRoODtcs for ; Tue, 21 Oct 2008 14:08:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3606B3A68FC for ; Tue, 21 Oct 2008 14:08:00 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9LL97PP029552; Tue, 21 Oct 2008 14:09:07 -0700 (PDT) Message-Id: <7307B5F6-254F-4A22-8C68-93A83D09E6A7@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "Vijay K. Gurbani" In-Reply-To: <48FE4424.2000309@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 14:09:07 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <48F4E20B.8000609@cavebear.com> <48FE4424.2000309@alcatel-lucent.com> X-Mailer: Apple Mail (2.929.2) Cc: "p2pi@ietf.org" , Nicholas Weaver Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Ono is leveraging off Akamai's DNS information: You do a few queries = to akamai'ed (and other CDN'ed) domains, and use the results as a = coordinate space. The question is the simpler coordinate: "who's MY resolver and who = else uses it". On Oct 21, 2008, at 2:05 PM, Vijay K. Gurbani wrote: > Nicholas Weaver wrote: >> Hey, stupid thought... >> Could you do proximity based on "who's your DNS resolver"? Do a = >> few name lookups: one to register YOU as using YOUR DNS resolver to = >> the remote coordinator, and one to get "who are other peers using = >> the same resolver"? >> An ugly, UGLY hack, but it might be interesting to think about. >> Has anyone done this already? > > Doesn't Ono [1] do that? Or am I missing something? CDNs also > use DNS redirects to redirect clients to nearest servers. > > [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: > A practical approach to reducing cross-ISP traffic in P2P > systems, Proc. of ACM SIGCOMM 2008, August 2008. > > Thanks, > > - vijay > -- = > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 14:32:22 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7442F3A6BB1; Tue, 21 Oct 2008 14:32:22 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46293A6804; Tue, 21 Oct 2008 14:32:20 -0700 (PDT) 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=-1.045, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, 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 pEuQE7hbSvrF; Tue, 21 Oct 2008 14:32:19 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 01F723A657C; Tue, 21 Oct 2008 14:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1224624814; x=1256160814; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2pi@ietf.org"=20|CC:=20"tana@ietf.org "=20,=20"tsv-area@ietf.org"=20|Date:=20Tue,=2021=20Oct=202008=2014:33:02=20-0700 |Subject:=20Re:=20[p2pi]=20[tsv-area]=20TANA=20proposed =20charter|Thread-Topic:=20[p2pi]=20[tsv-area]=20TANA=20p roposed=20charter|Thread-Index:=20AckzwOk1PC7juYL5Tt+kh3H ucqkfGwAAp4lA|Message-ID:=20<4A27D05E36DE7E47B96BCF7DD8F3 FD7101D352FD26@NASANEXMB04.na.qualcomm.com>|References: =20 |In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5411"=3B=20a=3D"11144656"; bh=0VBiy7y2rOjJKXx0DDiMXgRTrfbHLCnFlvxhBoRcnWM=; b=vK/5tep4yEsHqNTWmvu8aVRmxs11gQd60oR6e9mtUvVNJ3hcNitqxvgL ++55iBkR8y/oxeMeByrM9FoQQsavV7NLnPGG7QRt101UAYai3vAq1asmN Fib3geao5A+TN77wy2//bLq4gW7hjF+FX32+e9+I9JV5J3KwF476g2AkV o=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11144656" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 14:33:17 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LLXH9g018743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 14:33:17 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LLVFf4020451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 14:33:16 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.85]) by nasanexhc01.na.qualcomm.com ([172.30.37.21]) with mapi; Tue, 21 Oct 2008 14:33:09 -0700 From: "Das, Saumitra" To: "p2pi@ietf.org" Date: Tue, 21 Oct 2008 14:33:02 -0700 Thread-Topic: [p2pi] [tsv-area] TANA proposed charter Thread-Index: AckzwOk1PC7juYL5Tt+kh3HucqkfGwAAp4lA Message-ID: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tana@ietf.org" , "tsv-area@ietf.org" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Overall the problem is scoped well. Just a few clarifications about "(2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent transport connections to one peer and/or to different peers." This seems a bit too broad. Multiple transport connections to a single peer/server is often used in applications like FDM and other download accelerators. Are we talking about how multiple TANA flows will share a bottleneck in this context or in general about how current TCP flows do this and best practices for that such as how many connections to open depending on network characteristics? When we talk about connections to different peers in multi-source downloads what exactly are the tradeoffs we are talking about: is it the impact on ISPs, or that the application could try to choose peers whose AS path or routing path is maximally disjoint. And again is this about how TANA flows would work connecting to multiple peers while sharing a common bottleneck at the client or really about multiple TCP flows to different peers and how to choose the peers such that you reduce common bottlenecks in the network. Maybe the multiple connections work item needs to be elaborated upon to give the correct context. Also, I think the name change is useful since there is not inkling that this really is about congestion control. Scavenger Network Congestion Protocols sounds good. Thanks Saumitra www.saumitra.info -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of p2pi-request@ietf.org Sent: Tuesday, October 21, 2008 2:05 PM To: p2pi@ietf.org Subject: p2pi Digest, Vol 7, Issue 27 Send p2pi mailing list submissions to p2pi@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/p2pi or, via email, send a message with subject or body 'help' to p2pi-request@ietf.org You can reach the person managing the list at p2pi-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of p2pi digest..." Today's Topics: 1. Re: [tsv-area] TANA proposed charter (Ted Faber) 2. Re: [tsv-area] TANA proposed charter (Ted Faber) 3. Re: [tsv-area] TANA proposed charter (Caitlin Bestler) 4. Re: [tana] [tsv-area] TANA proposed charter (Ted Faber) 5. Re: ASN utility (Marshall Eubanks) 6. Re: WG Review: Application-Layer Traffic Optimization (alto) (Nicholas Weaver) 7. Re: ASN utility (David Ward) 8. Re: WG Review: Application-Layer Traffic Optimization (alto) (Vijay K. Gurbani) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Oct 2008 09:50:51 -0700 From: Ted Faber Subject: Re: [p2pi] [tsv-area] TANA proposed charter To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" Cc: TSV Area , tana@ietf.org, p2pi@ietf.org Message-ID: <20081021165051.GA64367@zod.isi.edu> Content-Type: text/plain; charset="us-ascii" On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > But if nobody else has a problem with the TANA name, I'll keep my mouth > shut so we don't waste time and energy. There are bigger fish to fry! It should change. I care about congestion control and nothing in the expansion of TANA indicated it was about congestion (to me). -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : ------------------------------ Message: 2 Date: Tue, 21 Oct 2008 13:23:27 -0700 From: Ted Faber Subject: Re: [p2pi] [tsv-area] TANA proposed charter To: Stanislav Shalunov Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Message-ID: <20081021202327.GE64367@zod.isi.edu> Content-Type: text/plain; charset="us-ascii" On Tue, Oct 21, 2008 at 10:11:37AM -0700, Stanislav Shalunov wrote: > On Oct 21, 2008, at 9:50 AM, Ted Faber wrote: > >[The TANA name] should change. > > > Would it be sufficient to change the name on the documents and not in > the mailing list and the WG name? > > The WG name will go after we're done. The documents will remain. > This would also allow us to choose the names when the document bodies > are already written -- always a plus for relevance... If you want people who are interested in congestion control to take part in your group, "Techniques for Advanced Networking Applications" will do nothing to attract their attention. It is completely generic phrase. It could refer to UTF encoding strategies or peer-to-peer load balancing. It may not be important to you to attract congestion control expertise. If it is, I recommend changing the name to something that will get busy congestion control people to read past the name. YMMV. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : ------------------------------ Message: 3 Date: Tue, 21 Oct 2008 09:23:01 -0700 From: Caitlin Bestler Subject: Re: [p2pi] [tsv-area] TANA proposed charter To: Murari Sridharan Cc: TSV Area , "tana@ietf.org" , "p2pi@ietf.org" , "ext Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Message-ID: <48FE01E5.5000302@asomi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Murari Sridharan wrote: > Isn't the goal here to achieve lower than best-effort, so essentially "Low Priority TCP", > assuming non-TCP traffic flows E2E we can make it more general and call it "Congestion control > for low priority flows" > > Murari > A successful algorithm here would not necessarily "lower than" best-effort, because the "low priority' flow could actually achieve higher throughput than a conventional TCP flow. I believe that the key phrase in the proposed charter is very much on target -- that the "TANA flows" rapidly yield to conventional TCP. It is possible to both rapidly yield *and* to rapidly claim bandwidth that conventional TCP algorithms would have left unused. The extent to which a given algorithm can rapidly claim bandwidth without imperiling existing TCP traffic is of course something that the WG would have to review. But given the charter objective of "saturation" it is important to understand that this is not necessarily "low priority" traffic. It is undoubtedly very jitter-tolerant traffic that can be quite elastic in its bandwidth utilization for any short period of time. ----- Caitlin Bestler cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf ------------------------------ Message: 4 Date: Tue, 21 Oct 2008 13:31:40 -0700 From: Ted Faber Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter To: Nicholas Weaver Cc: p2pi@ietf.org, tana@ietf.org, TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Message-ID: <20081021203140.GH64367@zod.isi.edu> Content-Type: text/plain; charset="us-ascii" On Tue, Oct 21, 2008 at 01:26:46PM -0700, Nicholas Weaver wrote: > Why not: > > Scavenger Network Congestion Protocols? My ears would prick up for that. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 16:38:30 -0400 From: Marshall Eubanks Subject: Re: [p2pi] ASN utility To: Lisa Dusseault Cc: p2pi@ietf.org Message-ID: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: > > > When the IESG looked at the proposed ALTO charter last week, Dave > had some comments about ASNs which I'd like to follow up on by > dragging Dave into the conversation. > > What I understand the ASN related suggestions so far to be, is to > have the ALTO server return a list of ASN numbers to prefer or > avoid. This sort of information could only be provided by an ISP- > operated ALTO server. Are you sure about that ? A peer can (for example) query route views, or I (or a host of others) can send it BGP / address block tables. It would not be hard to collate address information with ASN and ASN paths and draw conclusions. I don't see why an ISP is necessarily involved. Regards Marshall > A peer, armed with this information, can do whatever they do today > to figure > out which IP address falls in which ASN. The P4P and Yale folks > claim that returning a preference of ASNs helped their application > tremendously. > > Dave, was your concern about discovering ASN being unnecessary, or > about ranking of ASNs being unhelpful? Can you restate? > > Thanks, > Lisa > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi ------------------------------ Message: 6 Date: Tue, 21 Oct 2008 13:43:30 -0700 From: Nicholas Weaver Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) To: Karl Auerbach Cc: "p2pi@ietf.org" , Nicholas Weaver , IESG IESG , "ietf@ietf.org" Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hey, stupid thought... Could you do proximity based on "who's your DNS resolver"? Do a few name lookups: one to register YOU as using YOUR DNS resolver to the remote coordinator, and one to get "who are other peers using the same resolver"? An ugly, UGLY hack, but it might be interesting to think about. Has anyone done this already? ------------------------------ Message: 7 Date: Tue, 21 Oct 2008 15:50:40 -0500 From: David Ward Subject: Re: [p2pi] ASN utility To: Marshall Eubanks Cc: p2pi@ietf.org, Lisa Dusseault Message-ID: <10062CD4-88B8-47EC-8809-D02486A3D05D@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Marshall - I mentioned that this is one deployment model and is as it works today but, the charter is unclear if they want to support any other model. I do think it is considerably harder to deduce a current AS_path from simple prefix -> ASN information. -DWard On Oct 21, 2008, at 3:38 PM, Marshall Eubanks wrote: > > On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: > >> >> >> When the IESG looked at the proposed ALTO charter last week, Dave >> had some comments about ASNs which I'd like to follow up on by >> dragging Dave into the conversation. >> >> What I understand the ASN related suggestions so far to be, is to >> have the ALTO server return a list of ASN numbers to prefer or >> avoid. This sort of information could only be provided by an ISP- >> operated ALTO server. > > Are you sure about that ? > > A peer can (for example) query route views, or I (or a host of > others) can send it BGP / address block tables. It would not be > hard to collate address information with ASN and ASN paths and draw > conclusions. I don't see why an ISP is necessarily involved. > > Regards > Marshall > > > >> A peer, armed with this information, can do whatever they do today >> to figure >> out which IP address falls in which ASN. The P4P and Yale folks >> claim that returning a preference of ASNs helped their application >> tremendously. >> >> Dave, was your concern about discovering ASN being unnecessary, or >> about ranking of ASNs being unhelpful? Can you restate? >> >> Thanks, >> Lisa >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > ------------------------------ Message: 8 Date: Tue, 21 Oct 2008 16:05:40 -0500 From: "Vijay K. Gurbani" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) To: Nicholas Weaver Cc: "p2pi@ietf.org" Message-ID: <48FE4424.2000309@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Nicholas Weaver wrote: > Hey, stupid thought... > > Could you do proximity based on "who's your DNS resolver"? Do a few > name lookups: one to register YOU as using YOUR DNS resolver to the > remote coordinator, and one to get "who are other peers using the same > resolver"? > > An ugly, UGLY hack, but it might be interesting to think about. > > Has anyone done this already? Doesn't Ono [1] do that? Or am I missing something? CDNs also use DNS redirects to redirect clients to nearest servers. [1] David R. Choffnes and Fabi?n E. Bustamante. Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems, Proc. of ACM SIGCOMM 2008, August 2008. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ------------------------------ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi End of p2pi Digest, Vol 7, Issue 27 *********************************** _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 14:49:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25B03A6BB8; Tue, 21 Oct 2008 14:49:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818AF3A6BA4; Tue, 21 Oct 2008 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=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 1oa0ZH3r7A3S; Tue, 21 Oct 2008 14:49:14 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 406B43A657C; Tue, 21 Oct 2008 14:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1224625829; x=1256161829; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2pi@ietf.org"=20|CC:=20"tana@ietf.org "=20,=20"tsv-area@ietf.org"=20|Date:=20Tue,=2021=20Oct=202008=2014:49:26=20-0700 |Subject:=20Re:=20[p2pi]=20[tsv-area]=20[tana]=20TANA=20p roposed=20charter|Thread-Topic:=20Re:=20[p2pi]=20[tsv-are a]=20[tana]=20TANA=20proposed=20charter|Thread-Index:=20A ckzxuMJVlalFty0Sjmg1UhH9UMnxA=3D=3D|Message-ID:=20<4A27D0 5E36DE7E47B96BCF7DD8F3FD7101D352FD30@NASANEXMB04.na.qualc omm.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D35 2FD30NASANEXMB04na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5411"=3B=20a=3D"11145210"; bh=TJhjloB0bSJU+f4DL1evDG2ppPgjG8cfjIInCfDloRo=; b=Q6mzTC7/FGuFnyXmiRulIE9FYSTSEmKb15wzYCk91d0/pkR/Tyq0YsuV TMWwQu/KgS2fr/z7942NQFxHCZ1ujTeo3ND0heKIeH+zZNQOykvyOAzYS WX2hF7fQM5qYQ0OL+QChkTT/48P6TfJltKuLDRwA5e4XC+o25UqegvBHT w=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11145210" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 14:49:35 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LLnYkx030905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 14:49:35 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LLnYNN024558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 14:49:34 -0700 Received: from nasanexhub06.na.qualcomm.com (129.46.134.254) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 14:49:34 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.85]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Tue, 21 Oct 2008 14:49:34 -0700 From: "Das, Saumitra" To: "p2pi@ietf.org" Date: Tue, 21 Oct 2008 14:49:26 -0700 Thread-Topic: Re: [p2pi] [tsv-area] [tana] TANA proposed charter Thread-Index: AckzxuMJVlalFty0Sjmg1UhH9UMnxA== Message-ID: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD30@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tana@ietf.org" , "tsv-area@ietf.org" Subject: Re: [p2pi] [tsv-area] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1128606700==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1128606700== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD30NASANEXMB04na_" --_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD30NASANEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>Murari Sridharan wrote: >> Isn't the goal here to achieve lower than best-effort, so essentially >> "Low Priority TCP", > > assuming non-TCP traffic flows E2E we can make it more general and call= it "Congestion control > for low priority flows" >> >> Murari >> >A successful algorithm here would not necessarily "lower than" >best-effort, because the "low priority' flow could actually achieve higher= throughput than a conventional TCP flow. >I believe that the key phrase in the proposed charter is very much on targ= et -- that the "TANA flows" rapidly yield to conventional TCP. >It is possible to both rapidly yield *and* to rapidly claim bandwidth that= conventional TCP algorithms would have left unused. >The extent to which a given algorithm can rapidly claim bandwidth without = imperiling existing TCP traffic is of course something that the WG would ha= ve >o review. But given the charter objective of "saturation" it is importa= nt to understand that this is not necessarily "low priority" traffic. It is= >ndoubtedly very jitter-tolerant traffic that can be quite elastic in its = bandwidth utilization for any short period of time. >----- >Caitlin Bestler >cait@asomi.com - http://www.asomi.com/CaitlinBestle= rResume.pdf I think the term low priority refers to yielding to a conventional TCP flow= and in those terms TANA flows are low priority. The fact that they could claim unused and available bandwidth doesn't chang= e the fact that they are lower priority than conventional TCP. I agree with your point that this could in fact rapidly claim bandwidth fas= ter than conventional TCP depending on the design but the priority consider= ation with relation to conventional TCP still remains. I was wondering how different or aligned the goals of TANA are with somethi= ng like TCP-LP which also yields to conventional TCP but uses the available Unused bandwidth. Are we differentiating it based on the fact that TANA wou= ld be more aggressive in reclaiming unused bandwidth to the point of being higher throughput than a conventional TCP flow? Or is TCP-LP one of the sol= ution points for consideration. Thanks Saumitra www.saumitra.info --_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD30NASANEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>Murari Sridharan wrote:

>> Isn't the goal here to achieve lower than best-effort, so essentially

>> "Low Priority TCP",

> > assuming non-TCP traffic flows E2E we can= make it more general and call it "Congestion control  > for low priority flows"

>>

>> Murari

>>

 

>A successful algorithm here would not necessari= ly "lower than"

>best-effort, because the "low priority' fl= ow could actually achieve higher throughput than a conventional TCP flow.=

>I believe that the key phrase in the proposed c= harter is very much on target -- that the "TANA flows" rapidly yield to conventional TCP.

>It is possible to both rapidly yield *and* to r= apidly claim bandwidth that conventional TCP algorithms would have left unused.

>The extent to which a given algorithm can rapid= ly claim bandwidth without imperiling existing TCP traffic is of course someth= ing that the WG would have >o review. But given the charter objective of "saturation" it is important to understand that this is not necessarily "low priority" traffic. It is >ndoubtedly very jitter-tolerant traffic that can be quite elastic in its bandwidth utilizat= ion for any short period of time.

>-----

>Caitlin Bestler

>cait@asomi.co= m - http://www.asomi.com= /CaitlinBestlerResume.pdf

 

 

I think the term low priority refers to yielding to= a conventional TCP flow and in those terms TANA flows are low priority.<= /o:p>

The fact that they could claim unused and available= bandwidth doesn’t change the fact that they are lower priority than conventiona= l TCP.

 

I agree with your point that this could in fact rap= idly claim bandwidth faster than conventional TCP depending on the design but th= e priority consideration with relation to conventional TCP still remains.

 

I was wondering how different or aligned the goals = of TANA are with something like TCP-LP which also yields to conventional TCP b= ut uses the available

Unused bandwidth. Are we differentiating it based o= n the fact that TANA would be more aggressive in reclaiming unused bandwidth to t= he point of being

higher throughput than a conventional TCP flow? Or = is TCP-LP one of the solution points for consideration.

 

Thanks

Saumitra

 

www.saumitra.i= nfo

 

 

 

--_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD30NASANEXMB04na_-- --===============1128606700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1128606700==-- From p2pi-bounces@ietf.org Tue Oct 21 14:59:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F1D3A6BC1; Tue, 21 Oct 2008 14:59:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2BD3A6BB8 for ; Tue, 21 Oct 2008 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.071 X-Spam-Level: X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 8xe1ZXOHDXSk for ; Tue, 21 Oct 2008 14:59:41 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0361F3A6BBD for ; Tue, 21 Oct 2008 14:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1224626456; x=1256162456; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2pi@ietf.org"=20|Date:=20Tue,=2021=20 Oct=202008=2015:00:45=20-0700|Subject:=20Re:=20WG=20Revie w:=20Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20Re:=20WG=20Review:=20Application-Layer =20Traffic=20Optimization=20(alto)|Thread-Index:=20AckzyH ggmQfRLWs9RyKCT8n1zde6+Q=3D=3D|Message-ID:=20<4A27D05E36D E7E47B96BCF7DD8F3FD7101D352FD38@NASANEXMB04.na.qualcomm.c om>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D35 2FD38NASANEXMB04na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5411"=3B=20a=3D"11220442"; bh=di0NVrA3r3tlrDG6h8fULsn7merS0sTrzpQOkfMW97k=; b=f3WA30l7TU7ygpa2G/OXIlcYYLqb946suiCGyiXg6crK7ZFKVbYwqPpH ziQpgizRUrgbPyS2Hgfqj2CeCkfavEqS+WDXlN9JffZduPyp8MplcXPId fpelJCdYVtXlrbzRN3DrAQjYraWLzekMV2Bgbay0KniFsSayl8ACOi8f6 M=; X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11220442" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 15:00:56 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LM0tnj022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Oct 2008 15:00:56 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9LM0t1v017078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 Oct 2008 15:00:55 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.85]) by nasanexhc02.na.qualcomm.com ([172.30.33.23]) with mapi; Tue, 21 Oct 2008 15:00:54 -0700 From: "Das, Saumitra" To: "p2pi@ietf.org" Date: Tue, 21 Oct 2008 15:00:45 -0700 Thread-Topic: Re: WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckzyHggmQfRLWs9RyKCT8n1zde6+Q== Message-ID: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD38@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369441580==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0369441580== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD38NASANEXMB04na_" --_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD38NASANEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Ono is leveraging off Akamai's DNS information: You do a few queries to a= kamai'ed (and other CDN'ed) domains, and use the results as a coordinate sp= ace. >The question is the simpler coordinate: "who's MY resolver and who else us= es it". >>On Oct 21, 2008, at 2:05 PM, Vijay K. Gurbani wrote: > Nicholas Weaver wrote: >> Hey, stupid thought... >> Could you do proximity based on "who's your DNS resolver"? Do a few >> name lookups: one to register YOU as using YOUR DNS resolver to the >> remote coordinator, and one to get "who are other peers using the >> same resolver"? >> An ugly, UGLY hack, but it might be interesting to think about. >> Has anyone done this already? > > Doesn't Ono [1] do that? Or am I missing something? CDNs also use > DNS redirects to redirect clients to nearest servers. > > [1] David R. Choffnes and Fabi?n E. Bustamante. Taming the Torrent: > A practical approach to reducing cross-ISP traffic in P2P > systems, Proc. of ACM SIGCOMM 2008, August 2008. > > Thanks, > > - vijay This may work for general ISP users who likely share the same DNS resolvers= . However others like say universities would have their own DNS resovler se= t up although they may also buy access from an ISP as well. So this informa= tion will nto be enough to figure out that peers in other universities that= can be reached via the Abilene network should be preferred by p2p applicat= ions since they will likely have different DNS resolvers. However this is different from the Taming the torrent approach which uses A= kami to infer "being in the same ISPness". They may in some cases have more= information about closeness based on cooperation with ISPs. Thanks, Saumitra www.saumitra.info --_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD38NASANEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Ono is leveraging off Akamai's DNS information:=   You do a few queries to akamai'ed (and other CDN'ed) domains, and use the results as a coordinate space.

>The question is the simpler coordinate: "w= ho's MY resolver and who else uses it".

 

>>On Oct 21, 2008, at 2:05 PM, Vijay K. Gurba= ni wrote:

 

> Nicholas Weaver wrote:

>> Hey, stupid thought...

>> Could you do proximity based on "who'= s your DNS resolver"?  Do a few

>> name lookups: one to register YOU as using= YOUR DNS resolver to the

>> remote coordinator, and one to get "w= ho are other peers using the

>> same resolver"?

>> An ugly, UGLY hack, but it might be intere= sting to think about.

>> Has anyone done this already?

> 

> Doesn't Ono [1] do that?  Or am I missing something?  CDNs also use

> DNS redirects to redirect clients to nearest servers.

> 

> [1] David R. Choffnes and Fabi?n E. Bustamante= . Taming the Torrent:

>    A practical approach to redu= cing cross-ISP traffic in P2P

>    systems, Proc. of ACM SIGCOM= M 2008, August 2008.

> 

> Thanks,

> 

> - vijay

 

This may work for general ISP users who likely shar= e the same DNS resolvers. However others like say universities would have their o= wn DNS resovler set up although they may also buy access from an ISP as well. = So this information will nto be enough to figure out that peers in other universiti= es that can be reached via the Abilene network should be preferred by p2p applications since they will likely have different DNS resolvers.

 

However this is different from the Taming the torre= nt approach which uses Akami to infer “being in the same ISPness”. They may in some cases have more information about closeness based on cooperation with ISPs.

 

Thanks,

Saumitra

 

www.saumitra.i= nfo

 

--_000_4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD38NASANEXMB04na_-- --===============0369441580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0369441580==-- From p2pi-bounces@ietf.org Tue Oct 21 15:00:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6998628C1B9; Tue, 21 Oct 2008 15:00:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B6A28C134 for ; Tue, 21 Oct 2008 15:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_41=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 AblVWXjhq7oq for ; Tue, 21 Oct 2008 15:00:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 34DAA3A6BBD for ; Tue, 21 Oct 2008 15:00:56 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so177241and.122 for ; Tue, 21 Oct 2008 15:02:09 -0700 (PDT) Received: by 10.100.5.15 with SMTP id 15mr10822505ane.50.1224626528953; Tue, 21 Oct 2008 15:02:08 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 30sm11047653yxk.4.2008.10.21.15.02.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 15:02:08 -0700 (PDT) Message-Id: <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com> From: Stanislav Shalunov To: "Das, Saumitra" In-Reply-To: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 15:02:04 -0700 References: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com> X-Mailer: Apple Mail (2.929.2) Cc: "tsv-area@ietf.org" , "tana@ietf.org" , "p2pi@ietf.org" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 21, 2008, at 2:33 PM, Das, Saumitra wrote: > Overall the problem is scoped well. Just a few clarifications about > "(2) A document that clarifies the current practices of > application design and reasons behind them and discusses the > tradeoffs surrounding the use of many concurrent transport > connections to one peer and/or to different peers." > > This seems a bit too broad. Multiple transport connections to a > single peer/server is often used in applications like FDM and other > download accelerators. Are we talking about how multiple TANA flows > will share a bottleneck in this context or in general about how > current TCP flows do this and > best practices for that such as how many connections to open > depending on network characteristics? The focus is on TCP primarily, but also we'd need to discuss TANA connections and, I suppose, TFRC and such. The genesis of TANA was at the P2PI workshop. A lot of people there were concerned about multiple connections used by P2P apps. Some concerns are meritorious, others require mostly just information -- there, apparently, exists a belief that P2P apps are designed to open multiple TCP connections to the same destination to circumvent TCP fairness. (I even have an inkling of how that one could get started.) The focus is on long-lived bulk transport connections, and the primary push was from correctly observing BitTorrent open a whole ton of TCP connections on start. (Most BitTorrent connections only transmit short metadata as it turns out, but still there are several unchoked connections with actual data.) Download managers opening concurrent connections would probably qualify. I expect things like browsers and MTAs that open multiple connections to deal with app latencies and round-trips would also need to be mentioned for completeness, even though they pose no concern for the transport area. > When we talk about connections to different peers in multi-source > downloads what exactly are the tradeoffs we are talking about: is it > the impact on ISPs, or that the application could try to choose > peers whose AS path or routing path is maximally disjoint. And again > is this about how TANA flows > would work connecting to multiple peers while sharing a common > bottleneck at the client or really about multiple TCP flows to > different peers and how to choose the peers such that you reduce > common bottlenecks in the network. This being the transport area, we need to examine primarily issues of network stability, efficiency, and fairness but, to a smaller extent, analyze when an app may or may not be getting the benefit its designers thought they would get. > Maybe the multiple connections work item needs to be elaborated upon > to give the correct context. I'll see what I can do to provide some context for it that is missing from the charter for people who didn't attend the workshop. > Also, I think the name change is useful since there is not inkling > that this really is about congestion control. Scavenger Network > Congestion Protocols sounds good. White ball noted. That makes three. Incidentally, does anyone *dislike* this name? -- Stas > > > Thanks > Saumitra > > www.saumitra.info > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf > Of p2pi-request@ietf.org > Sent: Tuesday, October 21, 2008 2:05 PM > To: p2pi@ietf.org > Subject: p2pi Digest, Vol 7, Issue 27 > > Send p2pi mailing list submissions to > p2pi@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/p2pi > or, via email, send a message with subject or body 'help' to > p2pi-request@ietf.org > > You can reach the person managing the list at > p2pi-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of p2pi digest..." > > > Today's Topics: > > 1. Re: [tsv-area] TANA proposed charter (Ted Faber) > 2. Re: [tsv-area] TANA proposed charter (Ted Faber) > 3. Re: [tsv-area] TANA proposed charter (Caitlin Bestler) > 4. Re: [tana] [tsv-area] TANA proposed charter (Ted Faber) > 5. Re: ASN utility (Marshall Eubanks) > 6. Re: WG Review: Application-Layer Traffic Optimization (alto) > (Nicholas Weaver) > 7. Re: ASN utility (David Ward) > 8. Re: WG Review: Application-Layer Traffic Optimization (alto) > (Vijay K. Gurbani) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Oct 2008 09:50:51 -0700 > From: Ted Faber > Subject: Re: [p2pi] [tsv-area] TANA proposed charter > To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" > Cc: TSV Area , tana@ietf.org, p2pi@ietf.org > Message-ID: <20081021165051.GA64367@zod.isi.edu> > Content-Type: text/plain; charset="us-ascii" > > On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. (GRC-RCN0) > [VZ] wrote: >> But if nobody else has a problem with the TANA name, I'll keep my >> mouth >> shut so we don't waste time and energy. There are bigger fish to >> fry! > > It should change. > > I care about congestion control and nothing in the expansion of TANA > indicated it was about congestion (to me). > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 195 bytes > Desc: not available > Url : > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Oct 2008 13:23:27 -0700 > From: Ted Faber > Subject: Re: [p2pi] [tsv-area] TANA proposed charter > To: Stanislav Shalunov > Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, > Wesley M. \(GRC-RCN0\)\[VZ\]" > Message-ID: <20081021202327.GE64367@zod.isi.edu> > Content-Type: text/plain; charset="us-ascii" > > On Tue, Oct 21, 2008 at 10:11:37AM -0700, Stanislav Shalunov wrote: >> On Oct 21, 2008, at 9:50 AM, Ted Faber wrote: >>> [The TANA name] should change. >> >> >> Would it be sufficient to change the name on the documents and not in >> the mailing list and the WG name? >> >> The WG name will go after we're done. The documents will remain. >> This would also allow us to choose the names when the document bodies >> are already written -- always a plus for relevance... > > If you want people who are interested in congestion control to take > part > in your group, "Techniques for Advanced Networking Applications" > will do > nothing to attract their attention. It is completely generic phrase. > It could refer to UTF encoding strategies or peer-to-peer load > balancing. > > It may not be important to you to attract congestion control > expertise. > If it is, I recommend changing the name to something that will get > busy congestion control people to read past the name. > > YMMV. > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 195 bytes > Desc: not available > Url : > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Oct 2008 09:23:01 -0700 > From: Caitlin Bestler > Subject: Re: [p2pi] [tsv-area] TANA proposed charter > To: Murari Sridharan > Cc: TSV Area , "tana@ietf.org" , > "p2pi@ietf.org" , "ext Eddy, Wesley M. > \(GRC-RCN0\)\[VZ\]" > Message-ID: <48FE01E5.5000302@asomi.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Murari Sridharan wrote: >> Isn't the goal here to achieve lower than best-effort, so >> essentially "Low Priority TCP", >> assuming non-TCP traffic flows E2E we can make it more general and > call it "Congestion control >> for low priority flows" >> >> Murari >> > > A successful algorithm here would not necessarily "lower than" > best-effort, because the "low priority' flow could actually achieve > higher throughput than a conventional TCP flow. > > I believe that the key phrase in the proposed charter is very much > on target -- that the "TANA flows" rapidly yield to conventional TCP. > It is possible to both rapidly yield *and* to rapidly claim bandwidth > that conventional TCP algorithms would have left unused. > > The extent to which a given algorithm can rapidly claim bandwidth > without imperiling existing TCP traffic is of course something that > the WG would have to review. But given the charter objective of > "saturation" it is important to understand that this is not > necessarily > "low priority" traffic. It is undoubtedly very jitter-tolerant traffic > that can be quite elastic in its bandwidth utilization for any short > period of time. > > ----- > Caitlin Bestler > cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf > > > ------------------------------ > > Message: 4 > Date: Tue, 21 Oct 2008 13:31:40 -0700 > From: Ted Faber > Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter > To: Nicholas Weaver > Cc: p2pi@ietf.org, tana@ietf.org, TSV Area , "Eddy, > Wesley M. \(GRC-RCN0\)\[VZ\]" > Message-ID: <20081021203140.GH64367@zod.isi.edu> > Content-Type: text/plain; charset="us-ascii" > > On Tue, Oct 21, 2008 at 01:26:46PM -0700, Nicholas Weaver wrote: >> Why not: >> >> Scavenger Network Congestion Protocols? > > My ears would prick up for that. > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 195 bytes > Desc: not available > Url : > > > ------------------------------ > > Message: 5 > Date: Tue, 21 Oct 2008 16:38:30 -0400 > From: Marshall Eubanks > Subject: Re: [p2pi] ASN utility > To: Lisa Dusseault > Cc: p2pi@ietf.org > Message-ID: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: > >> >> >> When the IESG looked at the proposed ALTO charter last week, Dave >> had some comments about ASNs which I'd like to follow up on by >> dragging Dave into the conversation. >> >> What I understand the ASN related suggestions so far to be, is to >> have the ALTO server return a list of ASN numbers to prefer or >> avoid. This sort of information could only be provided by an ISP- >> operated ALTO server. > > Are you sure about that ? > > A peer can (for example) query route views, or I (or a host of others) > can send it BGP / address block tables. It would not be hard to > collate address information with ASN and ASN paths and draw > conclusions. I don't see why an ISP is necessarily involved. > > Regards > Marshall > > > >> A peer, armed with this information, can do whatever they do today >> to figure >> out which IP address falls in which ASN. The P4P and Yale folks >> claim that returning a preference of ASNs helped their application >> tremendously. >> >> Dave, was your concern about discovering ASN being unnecessary, or >> about ranking of ASNs being unhelpful? Can you restate? >> >> Thanks, >> Lisa >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > > > ------------------------------ > > Message: 6 > Date: Tue, 21 Oct 2008 13:43:30 -0700 > From: Nicholas Weaver > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization > (alto) > To: Karl Auerbach > Cc: "p2pi@ietf.org" , Nicholas Weaver > , IESG IESG , > "ietf@ietf.org" > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hey, stupid thought... > > Could you do proximity based on "who's your DNS resolver"? Do a few > name lookups: one to register YOU as using YOUR DNS resolver to the > remote coordinator, and one to get "who are other peers using the same > resolver"? > > An ugly, UGLY hack, but it might be interesting to think about. > > Has anyone done this already? > > > > ------------------------------ > > Message: 7 > Date: Tue, 21 Oct 2008 15:50:40 -0500 > From: David Ward > Subject: Re: [p2pi] ASN utility > To: Marshall Eubanks > Cc: p2pi@ietf.org, Lisa Dusseault > Message-ID: <10062CD4-88B8-47EC-8809-D02486A3D05D@cisco.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Marshall - > > I mentioned that this is one deployment model and is as it works > today but, the charter is unclear if they want to support any other > model. I do think it is considerably harder to deduce a current > AS_path from simple prefix -> ASN information. > > -DWard > > On Oct 21, 2008, at 3:38 PM, Marshall Eubanks wrote: > >> >> On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote: >> >>> >>> >>> When the IESG looked at the proposed ALTO charter last week, Dave >>> had some comments about ASNs which I'd like to follow up on by >>> dragging Dave into the conversation. >>> >>> What I understand the ASN related suggestions so far to be, is to >>> have the ALTO server return a list of ASN numbers to prefer or >>> avoid. This sort of information could only be provided by an ISP- >>> operated ALTO server. >> >> Are you sure about that ? >> >> A peer can (for example) query route views, or I (or a host of >> others) can send it BGP / address block tables. It would not be >> hard to collate address information with ASN and ASN paths and draw >> conclusions. I don't see why an ISP is necessarily involved. >> >> Regards >> Marshall >> >> >> >>> A peer, armed with this information, can do whatever they do today >>> to figure >>> out which IP address falls in which ASN. The P4P and Yale folks >>> claim that returning a preference of ASNs helped their application >>> tremendously. >>> >>> Dave, was your concern about discovering ASN being unnecessary, or >>> about ranking of ASNs being unhelpful? Can you restate? >>> >>> Thanks, >>> Lisa >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> > > > > ------------------------------ > > Message: 8 > Date: Tue, 21 Oct 2008 16:05:40 -0500 > From: "Vijay K. Gurbani" > Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization > (alto) > To: Nicholas Weaver > Cc: "p2pi@ietf.org" > Message-ID: <48FE4424.2000309@alcatel-lucent.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Nicholas Weaver wrote: >> Hey, stupid thought... >> >> Could you do proximity based on "who's your DNS resolver"? Do a few >> name lookups: one to register YOU as using YOUR DNS resolver to the >> remote coordinator, and one to get "who are other peers using the >> same >> resolver"? >> >> An ugly, UGLY hack, but it might be interesting to think about. >> >> Has anyone done this already? > > Doesn't Ono [1] do that? Or am I missing something? CDNs also > use DNS redirects to redirect clients to nearest servers. > > [1] David R. Choffnes and Fabi?n E. Bustamante. Taming the Torrent: > A practical approach to reducing cross-ISP traffic in P2P > systems, Proc. of ACM SIGCOMM 2008, August 2008. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > > ------------------------------ > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > > > End of p2pi Digest, Vol 7, Issue 27 > *********************************** > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 15:26:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9769128C18F; Tue, 21 Oct 2008 15:26:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7EE3A6A92 for ; Tue, 21 Oct 2008 15:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 gFbca-vBCYfb for ; Tue, 21 Oct 2008 15:26:43 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.245]) by core3.amsl.com (Postfix) with ESMTP id 3B2D23A6BA5 for ; Tue, 21 Oct 2008 15:26:43 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so2846452agb.12 for ; Tue, 21 Oct 2008 15:27:55 -0700 (PDT) Received: by 10.100.5.15 with SMTP id 15mr10865867ane.50.1224628074839; Tue, 21 Oct 2008 15:27:54 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 4sm11090082yxd.2.2008.10.21.15.27.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 15:27:54 -0700 (PDT) Message-Id: <5F6E7371-33F5-431E-9A36-6F89B6F4B9E1@shlang.com> From: Stanislav Shalunov To: Pekka Savola In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 15:27:51 -0700 References: <20081006203532.B1D673A68AF@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 13, 2008, at 5:23 AM, Pekka Savola wrote: > I believe this work could be useful and would provide an improvement > over existing p2p usage and traffic management. I also believe that an ALTO WG should be formed and would like to contribute to a solutions draft. The current requirements and problem statement are scoped rather narrowly around a solution in mind. This is recognized by the BoF chairs and the authors, and I would be interested in contributing to these documents so that they more generally applicable. A solutions draft should be a start to help think about the solutions space. The starting point for the solutions idea is described at http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html This is intended to answer Lisa's call for example candidate solutions to better understand the space. The solution will emphasize simplicity, privacy, and, correspondingly, clear understanding of what information is given to whom. The question at hand is not consensus on the requirements or even problem statement, but just the charter. I believe the charter has by now been crafted with the intention of covering the known cases. One small concern that I didn't previously raise because I just noticed it is that the charter still says "A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses." This starts to specify an architecture. While the known candidate solutions seem to fit, I would prefer clarifying that it's not request/ response protocol or data format that's the point, but the information. One way of doing so would to to rephrase as follows: "A complete mechanisms that enables clients to learn from the ALTO service information useful for peer selection." Again, this should go forward. Thanks, -- Stas -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 17:12:07 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F104B3A6853; Tue, 21 Oct 2008 17:12:06 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E45D3A6853 for ; Tue, 21 Oct 2008 17:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.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 vAvicADyaN3d for ; Tue, 21 Oct 2008 17:12:04 -0700 (PDT) Received: from redflag.CS.Princeton.EDU (redflag.CS.Princeton.EDU [128.112.136.72]) by core3.amsl.com (Postfix) with ESMTP id 3BDA23A63EC for ; Tue, 21 Oct 2008 17:12:04 -0700 (PDT) Received: from mfreedman.CS.Princeton.EDU (mfreedman.CS.Princeton.EDU [128.112.95.37]) (authenticated bits=0) by redflag.CS.Princeton.EDU (8.13.8/8.13.8) with ESMTP id m9M0CZ4t027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 20:12:38 -0400 (EDT) Message-ID: <48FE6FF3.6030008@cs.princeton.edu> Date: Tue, 21 Oct 2008 20:12:35 -0400 From: "Michael J. Freedman" User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Nicholas Weaver References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <48F4E20B.8000609@cavebear.com> <48FE4424.2000309@alcatel-lucent.com> <7307B5F6-254F-4A22-8C68-93A83D09E6A7@ICSI.Berkeley.EDU> In-Reply-To: <7307B5F6-254F-4A22-8C68-93A83D09E6A7@ICSI.Berkeley.EDU> X-Proofpoint-Virus-Version: vendor=nai engine=5.3.00 definitions=5411 signatures=474220 X-Proofpoint-Spam-Reason: safe Cc: "p2pi@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nicholas Weaver wrote: > Ono is leveraging off Akamai's DNS information: You do a few queries to = > akamai'ed (and other CDN'ed) domains, and use the results as a = > coordinate space. > = > The question is the simpler coordinate: "who's MY resolver and who else = > uses it". CoralCDN did something very similar to this at first. In fact, in = addition to inserting a entry in the Coral DHT, = it also tracerouted the resolver (of our proxy servers). If the = resulting last-hop IP addresses were a "relatively good match" for the = resolver, we would store these "network topology" hints in our DHT as = well. (This conditional check was to avoid cases when "last = traceroute-able hops" were quite distant from the destination, = especially given the fact that many hosts and routers don't actually = reply to traceroute probes these days.) The goal of this was to perform topological clustering of our peers, = much as you suggest: When a client would perform a DNS request, we = would synchronously traceroute the client's DNS resolver (we built a = very fast tool that would return in ~2 network RTTs), do a DHT lookup on = these the resolver and its last hops, and use any returned information = in our selection of "nearby" CoralCDN web proxies. Unfortunately, it didn't really work. I can't cite the precise numbers = off-hand, but we were seeing hit rates in the low single-digits. Thus, = the delay clients were experiencing for all this network hackery was = totally out-of-proportion to its benefit. (And when this hackery would = occasionally take more than two seconds, the client's DNS resolver would = happily reissue DNS requests to other Coral DNS servers, losing all the = previous work already done.) In short, we stopped using this technique after CoralCDN was deployed = for a few months. In fact, the experience of needing to return accurate = responses very quickly led us to design and build another system, OASIS, = that tries to build stable network maps that other services can use as a = peer-selection oracle. Now, one should be careful in trying to extend these lessons to the P2P = file-sharing setting, as CoralCDN focused on web content, thus had much = tighter latency requirements than a lot of file-sharing applications. = Second, our use of a decentralized DHT, especially deployed on flaky = PlanetLab servers, made meta-data loss more prevalent than one might = find in cluster storage. Third, and perhaps most importantly, the "CoralCDN proxies" we were mapping clients to were largely deployed on = university networks, while our client population was well-distributed = over the entire Internet: at the time, 100,000s-1M distinct clients IP = addresses (and 10,000s of distinct DNS resolvers) per day. On the flip side, I wouldn't completely discount these results. Many of = the very peers that contribute large amounts of upstream bandwidth on = P2P systems are *also* on university networks (both because of their = high upstream capacity and their lack of NATing compared to home users). As an aside, ALTO seems to have many similar goals as the IETF = SONAR/HOPs work in the mid-to-late 90s, although perhaps with more focus = on ISP buy-in. Thoughts? Regards, --mike References: CoralCDN, http://www.coralcdn.org/ NSDI 2004 paper: http://www.coralcdn.org/docs/coral-nsdi04.pdf OASIS, http://oasis.coralcdn.org/ NSDI 2006 paper: http://www.coralcdn.org/docs/oasis-nsdi06.pdf > On Oct 21, 2008, at 2:05 PM, Vijay K. Gurbani wrote: > = >> Nicholas Weaver wrote: >>> Hey, stupid thought... >>> Could you do proximity based on "who's your DNS resolver"? Do a few = >>> name lookups: one to register YOU as using YOUR DNS resolver to the = >>> remote coordinator, and one to get "who are other peers using the = >>> same resolver"? >>> An ugly, UGLY hack, but it might be interesting to think about. >>> Has anyone done this already? >> >> Doesn't Ono [1] do that? Or am I missing something? CDNs also >> use DNS redirects to redirect clients to nearest servers. >> >> [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: >> A practical approach to reducing cross-ISP traffic in P2P >> systems, Proc. of ACM SIGCOMM 2008, August 2008. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 17:46:12 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC713A68A4; Tue, 21 Oct 2008 17:46:12 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731A23A67ED; Tue, 21 Oct 2008 17:46:11 -0700 (PDT) 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 S6jJTMox65zl; Tue, 21 Oct 2008 17:46:10 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3877A3A63EC; Tue, 21 Oct 2008 17:46:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 429842C0012C2; Wed, 22 Oct 2008 02:47:23 +0200 (CEST) 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 l0Shd+S39+uU; Wed, 22 Oct 2008 02:47:23 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0CB832C000359; Wed, 22 Oct 2008 02:46:53 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 02:46:51 +0200 Message-ID: <547F018265F92642B577B986577D671C3E031F@VENUS.office> In-Reply-To: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: AckzrfkB1yfPeIbSR3OG8ws+cQsjEQALls2w References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com><9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu><19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com><4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU> From: "Rolf Winter" To: "Nicholas Weaver" , "Narayanan, Vidya" Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Very well scoped charter and I think the discussion so far has shown that besides clarifications and a need for a better name the charter is right on target. I am all for TANA or whatever its name is going to be. I think what is very important to remember in these discussions is that we talk about content that is served from the edge of the network, i.e. your typical P2P application. Access network asymetry in terms of upstream and downstream (e.g. DSL) is e.g. an important factor. P2P apps have been shown to fill up the upstream very efficiently. Tit-for-tat in BitTorrent will (to some degree) make sure the downstream will not significantly exceed the upstream bandwidth (Stansilav correct me if I am wrong). So the upstream is usually the thing we need to worry about in those settings as it is the limiting factor. Downloading something from YouTube is therefore very different in nature although it qualifies as bulk traffic. Overall I think "file-like" content distribution is the main application field as application developers probably do not want to bet their application's functioning on the access link characteristics of their customers if delay is an issue e.g. Even the earlier Warcraft example is still "file-like". We do not need to explicitly write this down but trying to achieve more complex things to make all sorts of potential applications "happy" would probably too ambitous. Rolf > Well, it also depends too: > > The medical data is point to point, not P2P. A single TCP > flow works well, and by being on real network, shouldn't > experience the buffer issues present in home gateways, and by > being a single flow, doesn't have the > congestion-monopolization properties that P2P transfer programs have. > > Warcraft is not using P2P for playing, rather it is using P2P > to save money in the data transfer of "patches", which > include large amounts of content (textures, models, etc) > (thus my rant on cost shifting). > > > Another interesting piece of data is that for the first > time in many > > years, http has overtaken p2p traffic in some markets, primarily > > driven by video download applications such as YouTube. > Thanks to http > > being the common firewall transport mechanism, much of the > video now > > runs over TCP. So, is it really as cut and dry as the bulk > data P2P > > traffic needing to yield to Internet traffic? As long as > it is about > > some background file transfer, perhaps that philosophy will > just work. > > But, if the P2P app is also a video app, the answer is > probably more > > complex. > > Additionally, on the video apps, to my mind these are often > badly done, and badly done in a way that the transport layer > can do nothing about. > > Take YouTube for example. Its flash-based structure is not > suitable (deliberately so!) for significant offline viewing. > Yet its buffer strategy is "Fill-er-up completely", when many > viewers will not stick around to watch the whole thing: a > substantial waste although it does improve seek time. > > (Comedy Central's, OTOH, has a maximum buffer of about 10 > seconds, so "stop in the middle" doesn't waste bandwidth). > > Yet all of these apps don't also properly recognize "I don't > have ENOUGH bandwidth to keep up with realtime", and so don't > (aren't capable of in flash?) of switching to a lower-bitrate > encoded source. > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 21 19:09:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0612C3A6963; Tue, 21 Oct 2008 19:09:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8153A6963; Tue, 21 Oct 2008 19:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 Mkbw1+Rv0nbZ; Tue, 21 Oct 2008 19:09:23 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id A32393A6918; Tue, 21 Oct 2008 19:09:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 95FEBE10E7E; Tue, 21 Oct 2008 22:10:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za0zd9hP85kb; Tue, 21 Oct 2008 22:09:56 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 4DE1FE10E6F; Tue, 21 Oct 2008 22:09:56 -0400 (EDT) Date: Tue, 21 Oct 2008 22:09:56 -0400 (EDT) From: Laird Popkin To: Rolf Winter Message-ID: <90204692.387711224641396296.JavaMail.root@dkny.pando.com> In-Reply-To: <547F018265F92642B577B986577D671C3E031F@VENUS.office> MIME-Version: 1.0 X-Originating-IP: [71.187.59.213] Cc: tana@ietf.org, Nicholas Weaver , p2pi@ietf.org, TSV Area , "Wesley M. Eddy \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org One technical point about p2p: a tit-for-tat mechanism only applies between downloaders (i.e. peers that have <100% of the data); seeds (i.e. peers with 100% of the data) send data without getting anything in return. This means that while the traffic between downloaders is balanced (so upstream is roughly equal to downstream, which would given asymmetrical consumer bandwidth would typically leave lots of available downlink capacity) it's entirely possible for many seeds to collectively saturate a downloader's downstream capacity. So while I agree that upstream is much more often the concern, we can't ignore downstream entirely. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Rolf Winter" To: "Nicholas Weaver" , "Vidya Narayanan" Cc: "TSV Area" , tana@ietf.org, p2pi@ietf.org, "Wesley M. Eddy (GRC-RCN0)[VZ]" Sent: Tuesday, October 21, 2008 8:46:51 PM (GMT-0500) America/New_York Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter Very well scoped charter and I think the discussion so far has shown that besides clarifications and a need for a better name the charter is right on target. I am all for TANA or whatever its name is going to be. I think what is very important to remember in these discussions is that we talk about content that is served from the edge of the network, i.e. your typical P2P application. Access network asymetry in terms of upstream and downstream (e.g. DSL) is e.g. an important factor. P2P apps have been shown to fill up the upstream very efficiently. Tit-for-tat in BitTorrent will (to some degree) make sure the downstream will not significantly exceed the upstream bandwidth (Stansilav correct me if I am wrong). So the upstream is usually the thing we need to worry about in those settings as it is the limiting factor. Downloading something from YouTube is therefore very different in nature although it qualifies as bulk traffic. Overall I think "file-like" content distribution is the main application field as application developers probably do not want to bet their application's functioning on the access link characteristics of their customers if delay is an issue e.g. Even the earlier War craft example is still "file-like". We do not need to explicitly write this down but trying to achieve more complex things to make all sorts of potential applications "happy" would probably too ambitous. Rolf > Well, it also depends too: > > The medical data is point to point, not P2P. A single TCP > flow works well, and by being on real network, shouldn't > experience the buffer issues present in home gateways, and by > being a single flow, doesn't have the > congestion-monopolization properties that P2P transfer programs have. > > Warcraft is not using P2P for playing, rather it is using P2P > to save money in the data transfer of "patches", which > include large amounts of content (textures, models, etc) > (thus my rant on cost shifting). > > > Another interesting piece of data is that for the first > time in many > > years, http has overtaken p2p traffic in some markets, primarily > > driven by video download applications such as YouTube. > Thanks to http > > being the common firewall transport mechanism, much of the > video now > > runs over TCP. So, is it really as cut and dry as the bulk > data P2P > > traffic needing to yield to Internet traffic? As long as > it is about > > some background file transfer, perhaps that philosophy will > just work. > > But, if the P2P app is also a video app, the answer is > probably more > > complex. > > Additionally, on the video apps, to my mind these are often > badly done, and badly done in a way that the transport layer > can do nothing about. > > Take YouTube for example. Its flash-based structure is not > suitable (deliberately so!) for significant offline viewing. > Yet its buffer strategy is "Fill-er-up completely", when many > viewers will not stick around to watch the whole thing: a > substantial waste although it does improve seek time. > > (Comedy Central's, OTOH, has a maximum buffer of about 10 > seconds, so "stop in the middle" doesn't waste bandwidth). > > Yet all of these apps don't also properly recognize "I don't > have ENOUGH bandwidth to keep up with realtime", and so don't > (aren't capable of in flash?) of switching to a lower-bitrate > encoded source. > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ tana mailing list tana@ietf.org https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 00:10:37 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA593A69BB; Wed, 22 Oct 2008 00:10:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA72C3A68D8; Wed, 22 Oct 2008 00:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XtaXEMZXKrbW; Wed, 22 Oct 2008 00:10:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 556823A67ED; Wed, 22 Oct 2008 00:10:33 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5AEB82106D; Wed, 22 Oct 2008 09:10:34 +0200 (CEST) X-AuditID: c1b4fb3e-aa77dbb00000537b-02-48fed1eae3a6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CBA92191E; Wed, 22 Oct 2008 09:10:34 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 09:10:33 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 09:10:33 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6331A265E; Wed, 22 Oct 2008 10:10:33 +0300 (EEST) Received: from n75.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 061924DC85; Wed, 22 Oct 2008 10:10:32 +0300 (EEST) Message-ID: <48FED1E8.7080101@ericsson.com> Date: Wed, 22 Oct 2008 10:10:32 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> <48FEC5C9.6060101@informatik.uni-wuerzburg.de> In-Reply-To: <48FEC5C9.6060101@informatik.uni-wuerzburg.de> X-OriginalArrivalTime: 22 Oct 2008 07:10:33.0542 (UTC) FILETIME=[4650AE60:01C93415] X-Brightmail-Tracker: AAAAAA== Cc: tana@ietf.org, Ted Faber , p2pi@ietf.org, Ingemar Johansson S , TSV Area , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, I also think the charter is very well scoped. However I'd like to see the *multiple connections* work item elaborated and explained a little bit more! about the name proposal both "LETBET (LEss Than Best Effort Transport)" and "Scavenger Network Congestion Protocols" sound good proposal to me. /sal Michael Menth wrote: > Hi, > > I also find the charter good and like Ingemar's name proposal "LETBET > (LEss Than Best Effort Transport)" > > Michael > > Ingemar Johansson S wrote: >> Hi >> >> Even though I understand that it is better to focus on the charter than >> in the name I too beleieve that TANA does not say much. >> >> I believe that somewhere along the track and also in the charter the >> term "less than best effort transmission" was/is mentioned >> A possible name would then be >> LETBET (LEss Than Best Effort Transport) >> >> That said... there are a whole bunch of WG names out there that at first >> glance does not say anything about the group. >> The charter looks OK from my perspective. >> >> /Ingemar >> >> >>> -----Original Message----- >>> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] >>> On Behalf Of Ted Faber >>> Sent: den 21 oktober 2008 18:51 >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>> Subject: Re: [tsv-area] TANA proposed charter >>> >>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>> (GRC-RCN0)[VZ] wrote: >>> >>>> But if nobody else has a problem with the TANA name, I'll keep my >>>> mouth shut so we don't waste time and energy. There are >>> bigger fish to fry! >>> >>> It should change. >>> >>> I care about congestion control and nothing in the expansion of TANA >>> indicated it was about congestion (to me). >>> >>> -- >>> Ted Faber >>> http://www.isi.edu/~faber PGP: >>> http://www.isi.edu/~faber/pubkeys.asc >>> Unexpected attachment on this mail? See >>> http://www.isi.edu/~faber/FAQ.html#SIG >>> >>> >> _______________________________________________ >> tana mailing list >> tana@ietf.org >> https://www.ietf.org/mailman/listinfo/tana >> > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 01:28:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D293A6AD3; Wed, 22 Oct 2008 01:28:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448123A6AD3; Wed, 22 Oct 2008 01:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, 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 HIGLAt9daM0G; Wed, 22 Oct 2008 01:28:28 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0AC683A6A2E; Wed, 22 Oct 2008 01:28:28 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 22 Oct 2008 01:28:34 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 01:28:49 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 01:28:49 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 04:28:48 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Oct 2008 08:28:47 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 22 Oct 2008 01:28:43 -0700 From: Reinaldo Penno To: Michael Welzl , , , Message-ID: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0IDFzKICC1YdMcEeFx9GSPrY0Qw== In-Reply-To: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> Mime-version: 1.0 X-OriginalArrivalTime: 22 Oct 2008 08:28:48.0148 (UTC) FILETIME=[3484B540:01C93420] Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'm not sure I'm reading the semantics of "Less than Best Effort" like other folks. 'Best Effort' has a well-defined semantics in the scope of Diffserv, including a code point of its own. Less than best effort seems we are defining a code point for such applications. Are we? The charter talks about 'end-to-end Diffserv'. End-to-end diffserv is a challenge on its own given ISP policies, etc. If the link is not saturated, are such application also treated as 'less than best effort' by still being DSCP marked and treated differently within routers? I would like if possible to decouple the 'less than best effort', as in diffserv, from the algorithm per se. Besides, there are ISPs that are worried about the effect that P2P have on other applications when the link is saturated, but otherwise they do not care. P2P would be treated like best effort in non-saturated situations (a more ECN type approach). Thanks, Reinaldo On 10/22/08 12:53 AM, "Michael Welzl" wrote: > I agree 100%, about both - charter and LETBET (which is my > favorite name proposal) > > Cheers, > Michael > > > On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: >> Hi, >> >> I also think the charter is very well scoped. >> >> However I'd like to see the *multiple connections* work item elaborated >> and explained a little bit more! >> >> about the name proposal both "LETBET (LEss Than Best Effort Transport)" and >> "Scavenger Network Congestion Protocols" sound good proposal to me. >> >> /sal >> >> Michael Menth wrote: >>> Hi, >>> >>> I also find the charter good and like Ingemar's name proposal "LETBET >>> (LEss Than Best Effort Transport)" >>> >>> Michael >>> >>> Ingemar Johansson S wrote: >>>> Hi >>>> >>>> Even though I understand that it is better to focus on the charter than >>>> in the name I too beleieve that TANA does not say much. >>>> >>>> I believe that somewhere along the track and also in the charter the >>>> term "less than best effort transmission" was/is mentioned >>>> A possible name would then be >>>> LETBET (LEss Than Best Effort Transport) >>>> >>>> That said... there are a whole bunch of WG names out there that at first >>>> glance does not say anything about the group. >>>> The charter looks OK from my perspective. >>>> >>>> /Ingemar >>>> >>>> >>>>> -----Original Message----- >>>>> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] >>>>> On Behalf Of Ted Faber >>>>> Sent: den 21 oktober 2008 18:51 >>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>>>> Subject: Re: [tsv-area] TANA proposed charter >>>>> >>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>>>> (GRC-RCN0)[VZ] wrote: >>>>> >>>>>> But if nobody else has a problem with the TANA name, I'll keep my >>>>>> mouth shut so we don't waste time and energy. There are >>>>> bigger fish to fry! >>>>> >>>>> It should change. >>>>> >>>>> I care about congestion control and nothing in the expansion of TANA >>>>> indicated it was about congestion (to me). >>>>> >>>>> -- >>>>> Ted Faber >>>>> http://www.isi.edu/~faber PGP: >>>>> http://www.isi.edu/~faber/pubkeys.asc >>>>> Unexpected attachment on this mail? See >>>>> http://www.isi.edu/~faber/FAQ.html#SIG >>>>> >>>>> >>>> _______________________________________________ >>>> tana mailing list >>>> tana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tana >>>> >>> >> >> _______________________________________________ >> tana mailing list >> tana@ietf.org >> https://www.ietf.org/mailman/listinfo/tana >> > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 01:50:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF113A6AAE; Wed, 22 Oct 2008 01:50:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC103A69A0; Wed, 22 Oct 2008 01:50:25 -0700 (PDT) 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 2JS+IMhOADYu; Wed, 22 Oct 2008 01:50:24 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E69E83A67D0; Wed, 22 Oct 2008 01:50:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D585D2C0012CA; Wed, 22 Oct 2008 10:51:39 +0200 (CEST) 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 9iurtZ6XMvl8; Wed, 22 Oct 2008 10:51:39 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id A4F822C000359; Wed, 22 Oct 2008 10:51:14 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 10:49:28 +0200 Message-ID: <547F018265F92642B577B986577D671C3E039F@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0IDFzKICC1YdMcEeFx9GSPrY0QwAAr9xA References: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> From: "Rolf Winter" To: "Reinaldo Penno" , "Michael Welzl" , , , Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Please see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Wednesday, October 22, 2008 5:29 PM > To: Michael Welzl; tana@ietf.org; p2pi@ietf.org; tsv-area@ietf.org > Subject: Re: [tana] [tsv-area] TANA proposed charter > > I'm not sure I'm reading the semantics of "Less than Best > Effort" like other folks. > > 'Best Effort' has a well-defined semantics in the scope of > Diffserv, including a code point of its own. Less than best > effort seems we are defining a code point for such > applications. Are we? The charter talks about 'end-to-end Diffserv'. I read this point in the charter differently. My interpretation is that if there is something available that helps you to achieve less-than-best-effort then please make use of it. TANA is not chartered to promote the global adoption of DiffServ for this purpose. > > End-to-end diffserv is a challenge on its own given ISP policies, etc. > > If the link is not saturated, are such application also > treated as 'less than best effort' by still being DSCP marked > and treated differently within routers? > > I would like if possible to decouple the 'less than best > effort', as in diffserv, from the algorithm per se. > > Besides, there are ISPs that are worried about the effect > that P2P have on other applications when the link is > saturated, but otherwise they do not care. P2P would be > treated like best effort in non-saturated situations (a more > ECN type approach). That is exactly the point. P2P should not "harm" inelastic traffic. In order to do that, queues should not build up as a consequence of the P2P traffic. The charter according to my interpretation says that the most suitable of the set of available means should be used or any combination of it that makes sense. > > Thanks, > > Reinaldo > > > On 10/22/08 12:53 AM, "Michael Welzl" > wrote: > > > I agree 100%, about both - charter and LETBET (which is my favorite > > name proposal) > > > > Cheers, > > Michael > > > > > > On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: > >> Hi, > >> > >> I also think the charter is very well scoped. > >> > >> However I'd like to see the *multiple connections* work item > >> elaborated and explained a little bit more! > >> > >> about the name proposal both "LETBET (LEss Than Best Effort > >> Transport)" and "Scavenger Network Congestion Protocols" > sound good proposal to me. > >> > >> /sal > >> > >> Michael Menth wrote: > >>> Hi, > >>> > >>> I also find the charter good and like Ingemar's name proposal > >>> "LETBET (LEss Than Best Effort Transport)" > >>> > >>> Michael > >>> > >>> Ingemar Johansson S wrote: > >>>> Hi > >>>> > >>>> Even though I understand that it is better to focus on > the charter > >>>> than in the name I too beleieve that TANA does not say much. > >>>> > >>>> I believe that somewhere along the track and also in the charter > >>>> the term "less than best effort transmission" was/is mentioned A > >>>> possible name would then be LETBET (LEss Than Best Effort > >>>> Transport) > >>>> > >>>> That said... there are a whole bunch of WG names out > there that at > >>>> first glance does not say anything about the group. > >>>> The charter looks OK from my perspective. > >>>> > >>>> /Ingemar > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: tsv-area-bounces@ietf.org > [mailto:tsv-area-bounces@ietf.org] > >>>>> On Behalf Of Ted Faber > >>>>> Sent: den 21 oktober 2008 18:51 > >>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] > >>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > >>>>> Subject: Re: [tsv-area] TANA proposed charter > >>>>> > >>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > >>>>> (GRC-RCN0)[VZ] wrote: > >>>>> > >>>>>> But if nobody else has a problem with the TANA name, > I'll keep my > >>>>>> mouth shut so we don't waste time and energy. There are > >>>>> bigger fish to fry! > >>>>> > >>>>> It should change. > >>>>> > >>>>> I care about congestion control and nothing in the expansion of > >>>>> TANA indicated it was about congestion (to me). > >>>>> > >>>>> -- > >>>>> Ted Faber > >>>>> http://www.isi.edu/~faber PGP: > >>>>> http://www.isi.edu/~faber/pubkeys.asc > >>>>> Unexpected attachment on this mail? See > >>>>> http://www.isi.edu/~faber/FAQ.html#SIG > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> tana mailing list > >>>> tana@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tana > >>>> > >>> > >> > >> _______________________________________________ > >> tana mailing list > >> tana@ietf.org > >> https://www.ietf.org/mailman/listinfo/tana > >> > > > > _______________________________________________ > > tana mailing list > > tana@ietf.org > > https://www.ietf.org/mailman/listinfo/tana > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 02:16:16 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5B93A6A95; Wed, 22 Oct 2008 02:16:16 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FC528C125; Wed, 22 Oct 2008 02:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, 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 oK05+agFU-p2; Wed, 22 Oct 2008 02:16:13 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id D99EB3A6986; Wed, 22 Oct 2008 02:16:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Wed, 22 Oct 2008 02:15:49 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 02:15:57 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 05:15:56 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Oct 2008 09:10:26 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 22 Oct 2008 02:10:22 -0700 From: Reinaldo Penno To: Rolf Winter , Michael Welzl , , , Message-ID: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0IDFzKICC1YdMcEeFx9GSPrY0QwAAr9xAAADEhWs= In-Reply-To: <547F018265F92642B577B986577D671C3E039F@VENUS.office> Mime-version: 1.0 X-OriginalArrivalTime: 22 Oct 2008 09:15:56.0639 (UTC) FILETIME=[CA6E2EF0:01C93426] Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hello, Inline... On 10/22/08 1:49 AM, "Rolf Winter" wrote: > Please see inline. > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 > 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On >> Behalf Of Reinaldo Penno >> Sent: Wednesday, October 22, 2008 5:29 PM >> To: Michael Welzl; tana@ietf.org; p2pi@ietf.org; tsv-area@ietf.org >> Subject: Re: [tana] [tsv-area] TANA proposed charter >> >> I'm not sure I'm reading the semantics of "Less than Best >> Effort" like other folks. >> >> 'Best Effort' has a well-defined semantics in the scope of >> Diffserv, including a code point of its own. Less than best >> effort seems we are defining a code point for such >> applications. Are we? The charter talks about 'end-to-end Diffserv'. > > I read this point in the charter differently. My interpretation is that if > there is something available that helps you to achieve less-than-best-effort > then please make use of it. TANA is not chartered to promote the global > adoption of DiffServ for this purpose. Let me ask it differently. Is a deliverable of the algorithm to "desired feaures...where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ)." ? In other words, beside the immediate deliverable to provide an algorithm that is delay bound, are we also going to specify how this new algorithm "use" those other features? It could go either way, I'm just looking for clarification on the scope of the problem. > >> >> End-to-end diffserv is a challenge on its own given ISP policies, etc. >> >> If the link is not saturated, are such application also >> treated as 'less than best effort' by still being DSCP marked >> and treated differently within routers? >> >> I would like if possible to decouple the 'less than best >> effort', as in diffserv, from the algorithm per se. >> >> Besides, there are ISPs that are worried about the effect >> that P2P have on other applications when the link is >> saturated, but otherwise they do not care. P2P would be >> treated like best effort in non-saturated situations (a more >> ECN type approach). > > That is exactly the point. P2P should not "harm" inelastic traffic. In order > to do that, queues should not build up as a consequence of the P2P traffic. > The charter according to my interpretation says that the most suitable of the > set of available means should be used or any combination of it that makes > sense. Inelastic as is VoIP? In this case instead of making P2P as less than best effort you can mark VoIP with EF. So, there is no need for "less than best effort" in this case from a Diffserv perspective, only from a algorithmic perspective. Thanks, Reinaldo > >> >> Thanks, >> >> Reinaldo >> >> >> On 10/22/08 12:53 AM, "Michael Welzl" >> wrote: >> >>> I agree 100%, about both - charter and LETBET (which is my favorite >>> name proposal) >>> >>> Cheers, >>> Michael >>> >>> >>> On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: >>>> Hi, >>>> >>>> I also think the charter is very well scoped. >>>> >>>> However I'd like to see the *multiple connections* work item >>>> elaborated and explained a little bit more! >>>> >>>> about the name proposal both "LETBET (LEss Than Best Effort >>>> Transport)" and "Scavenger Network Congestion Protocols" >> sound good proposal to me. >>>> >>>> /sal >>>> >>>> Michael Menth wrote: >>>>> Hi, >>>>> >>>>> I also find the charter good and like Ingemar's name proposal >>>>> "LETBET (LEss Than Best Effort Transport)" >>>>> >>>>> Michael >>>>> >>>>> Ingemar Johansson S wrote: >>>>>> Hi >>>>>> >>>>>> Even though I understand that it is better to focus on >> the charter >>>>>> than in the name I too beleieve that TANA does not say much. >>>>>> >>>>>> I believe that somewhere along the track and also in the charter >>>>>> the term "less than best effort transmission" was/is mentioned A >>>>>> possible name would then be LETBET (LEss Than Best Effort >>>>>> Transport) >>>>>> >>>>>> That said... there are a whole bunch of WG names out >> there that at >>>>>> first glance does not say anything about the group. >>>>>> The charter looks OK from my perspective. >>>>>> >>>>>> /Ingemar >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: tsv-area-bounces@ietf.org >> [mailto:tsv-area-bounces@ietf.org] >>>>>>> On Behalf Of Ted Faber >>>>>>> Sent: den 21 oktober 2008 18:51 >>>>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>>>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>>>>>> Subject: Re: [tsv-area] TANA proposed charter >>>>>>> >>>>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>>>>>> (GRC-RCN0)[VZ] wrote: >>>>>>> >>>>>>>> But if nobody else has a problem with the TANA name, >> I'll keep my >>>>>>>> mouth shut so we don't waste time and energy. There are >>>>>>> bigger fish to fry! >>>>>>> >>>>>>> It should change. >>>>>>> >>>>>>> I care about congestion control and nothing in the expansion of >>>>>>> TANA indicated it was about congestion (to me). >>>>>>> >>>>>>> -- >>>>>>> Ted Faber >>>>>>> http://www.isi.edu/~faber PGP: >>>>>>> http://www.isi.edu/~faber/pubkeys.asc >>>>>>> Unexpected attachment on this mail? See >>>>>>> http://www.isi.edu/~faber/FAQ.html#SIG >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> tana mailing list >>>>>> tana@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tana >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> tana mailing list >>>> tana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tana >>>> >>> >>> _______________________________________________ >>> tana mailing list >>> tana@ietf.org >>> https://www.ietf.org/mailman/listinfo/tana >> >> _______________________________________________ >> tana mailing list >> tana@ietf.org >> https://www.ietf.org/mailman/listinfo/tana >> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 02:26:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586C93A6B63; Wed, 22 Oct 2008 02:26:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3533A699D; Wed, 22 Oct 2008 02:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, 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 BbDdJEHYdOGD; Wed, 22 Oct 2008 02:26:24 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id AA6603A692F; Wed, 22 Oct 2008 02:26:24 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Wed, 22 Oct 2008 02:26:21 PDT Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 02:26:34 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 05:26:33 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Oct 2008 09:26:33 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 22 Oct 2008 02:26:29 -0700 From: Reinaldo Penno To: Roland Bless Message-ID: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0KENY03Ka+RMOwk2MeimttWguAw== In-Reply-To: <48FEEFDB.6000801@tm.uka.de> Mime-version: 1.0 X-OriginalArrivalTime: 22 Oct 2008 09:26:33.0286 (UTC) FILETIME=[45E6CE60:01C93428] Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org, Michael Welzl Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 10/22/08 2:18 AM, "Roland Bless" wrote: > Hi Reinaldo, > > Reinaldo Penno wrote: >> I'm not sure I'm reading the semantics of "Less than Best Effort" like other >> folks. > > Maybe RFC 3662 defines this more clearly. > >> 'Best Effort' has a well-defined semantics in the scope of Diffserv, >> including a code point of its own. Less than best effort seems we are >> defining a code point for such applications. Are we? The charter talks about >> 'end-to-end Diffserv'. > > See RFC 3662 Thanks Roland. I remember some of these discussions. Is there any effort to make it standard, particularly the DSCP so the algorithm can use it? > >> End-to-end diffserv is a challenge on its own given ISP policies, etc. >> >> If the link is not saturated, are such application also treated as 'less >> than best effort' by still being DSCP marked and treated differently within >> routers? > > Usually lower effort (LE) packets will go into a different queue > and served only if no other BE packets are waiting. So if > the BE queue is empty, LE packets will get the same treatment as BE > packets. Only in case of congestion, LE packets will be treated > differently. > >> I would like if possible to decouple the 'less than best effort', as in >> diffserv, from the algorithm per se. >> >> Besides, there are ISPs that are worried about the effect that P2P have on >> other applications when the link is saturated, but otherwise they do not >> care. P2P would be treated like best effort in non-saturated situations (a >> more ECN type approach). > > Yes, and that's exactly where LE helps: an ISP can be sure that > LE traffic will not harm other BE traffic at any time. In case > of congestion BE traffic will preempt LE traffic. If the > link is not saturated, LE will be treated like BE. > > Regards, > Roland > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 02:49:11 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7703A6BA0; Wed, 22 Oct 2008 02:49:11 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9FC3A6B80; Wed, 22 Oct 2008 02:49:10 -0700 (PDT) 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 LYX1XyL1pulV; Wed, 22 Oct 2008 02:49:09 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 885443A6B8F; Wed, 22 Oct 2008 02:49:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 973BB2C0012CA; Wed, 22 Oct 2008 11:50:24 +0200 (CEST) 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 2t7wkaq2bBql; Wed, 22 Oct 2008 11:50:24 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 66DE02C000359; Wed, 22 Oct 2008 11:49:59 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 11:49:53 +0200 Message-ID: <547F018265F92642B577B986577D671C3E03C0@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0IDFzKICC1YdMcEeFx9GSPrY0QwAAr9xAAADEhWsAAJZU8A== References: <547F018265F92642B577B986577D671C3E039F@VENUS.office> From: "Rolf Winter" To: "Reinaldo Penno" , "Michael Welzl" , , , Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Inline. > >> > >> I'm not sure I'm reading the semantics of "Less than Best Effort" > >> like other folks. > >> > >> 'Best Effort' has a well-defined semantics in the scope of > Diffserv, > >> including a code point of its own. Less than best effort > seems we are > >> defining a code point for such applications. Are we? The charter > >> talks about 'end-to-end Diffserv'. > > > > I read this point in the charter differently. My interpretation is > > that if there is something available that helps you to achieve > > less-than-best-effort then please make use of it. TANA is not > > chartered to promote the global adoption of DiffServ for > this purpose. > > Let me ask it differently. Is a deliverable of the algorithm > to "desired feaures...where available, use explicit > congestion notification (ECN), active queue management (AQM), > and/or end-to-end differentiated services (DiffServ)." ? > > In other words, beside the immediate deliverable to provide > an algorithm that is delay bound, are we also going to > specify how this new algorithm "use" those other features? > How such a feature could be used is very likely already documented to a sufficient level of detail elsewhere. See e.g. the RFC Roland quoted earlier. I personally think TANA should focus on what can be achieved in the absence of these features. From a charter perspective, it would be wrong to neglect the existence of these features though. So if somebody feels that there is a significant gap that leaves a number of questions open on how TANA could make use of an existing technique then I believe there is room in the WG for that. DiffServ I personally feel might not meet that criteria. But it is a very good point you raise and maybe the charter could be made more explicit in that respect. > It could go either way, I'm just looking for clarification on > the scope of the problem. > > > >> > >> End-to-end diffserv is a challenge on its own given ISP > policies, etc. > >> > >> If the link is not saturated, are such application also treated as > >> 'less than best effort' by still being DSCP marked and treated > >> differently within routers? > >> > >> I would like if possible to decouple the 'less than best > effort', as > >> in diffserv, from the algorithm per se. > >> > >> Besides, there are ISPs that are worried about the effect that P2P > >> have on other applications when the link is saturated, but > otherwise > >> they do not care. P2P would be treated like best effort in > >> non-saturated situations (a more ECN type approach). > > > > That is exactly the point. P2P should not "harm" inelastic > traffic. In > > order to do that, queues should not build up as a > consequence of the P2P traffic. > > The charter according to my interpretation says that the > most suitable > > of the set of available means should be used or any > combination of it > > that makes sense. > > Inelastic as is VoIP? In this case instead of making P2P as > less than best effort you can mark VoIP with EF. So, there is > no need for "less than best effort" in this case from a > Diffserv perspective, only from a algorithmic perspective. Yes, if DiffServ is availabe you could do all sorts of things. > > Thanks, > > Reinaldo > > > > >> > >> Thanks, > >> > >> Reinaldo > >> > >> > >> On 10/22/08 12:53 AM, "Michael Welzl" > >> wrote: > >> > >>> I agree 100%, about both - charter and LETBET (which is > my favorite > >>> name proposal) > >>> > >>> Cheers, > >>> Michael > >>> > >>> > >>> On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: > >>>> Hi, > >>>> > >>>> I also think the charter is very well scoped. > >>>> > >>>> However I'd like to see the *multiple connections* work item > >>>> elaborated and explained a little bit more! > >>>> > >>>> about the name proposal both "LETBET (LEss Than Best Effort > >>>> Transport)" and "Scavenger Network Congestion Protocols" > >> sound good proposal to me. > >>>> > >>>> /sal > >>>> > >>>> Michael Menth wrote: > >>>>> Hi, > >>>>> > >>>>> I also find the charter good and like Ingemar's name proposal > >>>>> "LETBET (LEss Than Best Effort Transport)" > >>>>> > >>>>> Michael > >>>>> > >>>>> Ingemar Johansson S wrote: > >>>>>> Hi > >>>>>> > >>>>>> Even though I understand that it is better to focus on > >> the charter > >>>>>> than in the name I too beleieve that TANA does not say much. > >>>>>> > >>>>>> I believe that somewhere along the track and also in > the charter > >>>>>> the term "less than best effort transmission" was/is > mentioned A > >>>>>> possible name would then be LETBET (LEss Than Best Effort > >>>>>> Transport) > >>>>>> > >>>>>> That said... there are a whole bunch of WG names out > >> there that at > >>>>>> first glance does not say anything about the group. > >>>>>> The charter looks OK from my perspective. > >>>>>> > >>>>>> /Ingemar > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: tsv-area-bounces@ietf.org > >> [mailto:tsv-area-bounces@ietf.org] > >>>>>>> On Behalf Of Ted Faber > >>>>>>> Sent: den 21 oktober 2008 18:51 > >>>>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] > >>>>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > >>>>>>> Subject: Re: [tsv-area] TANA proposed charter > >>>>>>> > >>>>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > >>>>>>> (GRC-RCN0)[VZ] wrote: > >>>>>>> > >>>>>>>> But if nobody else has a problem with the TANA name, > >> I'll keep my > >>>>>>>> mouth shut so we don't waste time and energy. There are > >>>>>>> bigger fish to fry! > >>>>>>> > >>>>>>> It should change. > >>>>>>> > >>>>>>> I care about congestion control and nothing in the > expansion of > >>>>>>> TANA indicated it was about congestion (to me). > >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 03:29:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839FF3A6AFC; Wed, 22 Oct 2008 03:29:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786E03A6A2E; Wed, 22 Oct 2008 03:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 0UDj-kL41wWJ; Wed, 22 Oct 2008 03:29:38 -0700 (PDT) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) by core3.amsl.com (Postfix) with ESMTP id 243A53A690E; Wed, 22 Oct 2008 03:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univie.ac.at; s=rev1; h=Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References; bh=8M4eqxPoSdzDR7vS75S25O/jO6G/4K0PjB/54Ttt7/Y=; b=m mmVCeNKgP8MAaQBgvIKXSXhe7MoQLM/VgQnG5E3Mg+3ekgQ/D6ktUUKdh/8yXx1J PAa5eG2O1PpsMO5xF2qYJWCinTu48duFwQRxpJRTETDP0T95BNS2FTC/Pej0xT4d bvxt0M5CyfT6Z/KJeuUQly5cRrz4pMU8bEXFCiucDY= Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1KsazM-0003e6-91; Wed, 22 Oct 2008 12:30:52 +0200 Received: from styx.pri.univie.ac.at ([131.130.37.129] helo=[172.24.66.45]) by joan.univie.ac.at with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KsazM-0002QP-6B; Wed, 22 Oct 2008 12:30:52 +0200 Message-Id: <0DF0CA59-35E9-48C5-B8F9-AB7A5655D797@univie.ac.at> From: Kurt Tutschku To: Michael Welzl In-Reply-To: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 12:30:51 +0200 References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> <48FEC5C9.6060101@informatik.uni-wuerzburg.de> <48FED1E8.7080101@ericsson.com> <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> X-Mailer: Apple Mail (2.929.2) Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dear honored colleagues, I think "LETBET" is nice to remember, but is my opinion very dangerous. The part of "BET" in the name recalls me some associations with auctions and bandwidth broker systems (see RFC 2638). I think TANA should and will distinguish itself from previous work. Therefore, I would be in favor of another name. Best Regards Kurt Am 22.10.2008 um 09:53 schrieb Michael Welzl: > I agree 100%, about both - charter and LETBET (which is my > favorite name proposal) > > Cheers, > Michael > > > On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: >> Hi, >> >> I also think the charter is very well scoped. >> >> However I'd like to see the *multiple connections* work item >> elaborated >> and explained a little bit more! >> >> about the name proposal both "LETBET (LEss Than Best Effort >> Transport)" and >> "Scavenger Network Congestion Protocols" sound good proposal to me. >> >> /sal >> >> Michael Menth wrote: >>> Hi, >>> >>> I also find the charter good and like Ingemar's name proposal >>> "LETBET >>> (LEss Than Best Effort Transport)" >>> >>> Michael >>> >>> Ingemar Johansson S wrote: >>>> Hi >>>> >>>> Even though I understand that it is better to focus on the >>>> charter than >>>> in the name I too beleieve that TANA does not say much. >>>> >>>> I believe that somewhere along the track and also in the charter >>>> the >>>> term "less than best effort transmission" was/is mentioned >>>> A possible name would then be >>>> LETBET (LEss Than Best Effort Transport) >>>> >>>> That said... there are a whole bunch of WG names out there that >>>> at first >>>> glance does not say anything about the group. >>>> The charter looks OK from my perspective. >>>> >>>> /Ingemar >>>> >>>> >>>>> -----Original Message----- >>>>> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] >>>>> On Behalf Of Ted Faber >>>>> Sent: den 21 oktober 2008 18:51 >>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>>>> Subject: Re: [tsv-area] TANA proposed charter >>>>> >>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>>>> (GRC-RCN0)[VZ] wrote: >>>>> >>>>>> But if nobody else has a problem with the TANA name, I'll keep my >>>>>> mouth shut so we don't waste time and energy. There are >>>>> bigger fish to fry! >>>>> >>>>> It should change. >>>>> >>>>> I care about congestion control and nothing in the expansion of >>>>> TANA >>>>> indicated it was about congestion (to me). >>>>> >>>>> -- >>>>> Ted Faber >>>>> http://www.isi.edu/~faber PGP: >>>>> http://www.isi.edu/~faber/pubkeys.asc >>>>> Unexpected attachment on this mail? See >>>>> http://www.isi.edu/~faber/FAQ.html#SIG >>>>> >>>>> >>>> _______________________________________________ >>>> tana mailing list >>>> tana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tana >>>> >>> >> >> _______________________________________________ >> tana mailing list >> tana@ietf.org >> https://www.ietf.org/mailman/listinfo/tana >> > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > --- Prof. Dr. Kurt Tutschku Chair of Future Communication (Endowed by Telekom Austria) Institute of Distributed and Multimedia Systems, Faculty of Computer Science University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria. Tel: +43/1/4277-39611 mailto:kurt.tutschku@univie.ac.at or mailto:kurttutschku@gmail.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 05:28:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CD83A6B78; Wed, 22 Oct 2008 05:28:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA833A6AAE; Wed, 22 Oct 2008 05:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 4TOWP2FVl2Da; Wed, 22 Oct 2008 05:28:56 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A08BC3A69B7; Wed, 22 Oct 2008 05:28:55 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 13:29:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 13:29:18 +0100 Message-ID: In-Reply-To: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: AckzmS9catvy+WU6SoiHfPKGL3HW9QAiRdVg References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> From: To: , X-OriginalArrivalTime: 22 Oct 2008 12:29:22.0176 (UTC) FILETIME=[CFDE9800:01C93441] Cc: p2pi@ietf.org, tana@ietf.org, tsv-area@ietf.org Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree that this is a pretty good charter. Just a few comments in-line (mainly supporting Bruce's earlier comments). > -----Original Message----- > From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On Behalf Of > Bruce Davie > Sent: 21 October 2008 16:06 > To: Eddy, Wesley M. (GRC-RCN0)[VZ] > Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > Subject: Re: [tana] [tsv-area] TANA proposed charter > > I'll start by saying that I support the WG and think the new charter > is pretty good. I have a few suggestions for small changes. > > > Applications that transmit large amounts of data for a long > > time with congestion-limited TCP, but without ECN fill the > > buffer at the head of the bottleneck link. > > Replace ECN with Active Queue Management (AQM) > Agree. In fact even ECN fills the head of the queue if it runs on RED algo... > > This increases the > > delay experienced by other applications. > > It would be more accurate to say "In the absence of any form of > isolation in the queues, this increases..." > Agree > > In the best case, > > with an ideally sized buffer of one RTT, the delay doubles. In > > some cases, the extra delay may be much larger. > > Since there isn't complete agreement on the ideal size of a buffer, > just say: > > "If the buffer size is one RTT, the delay doubles...." > Or "If the buffer is set to one RTT as often recommended, the delay doubles..." > > This is a > > particularly acute and common case is when P2P applications > > upload over thin home uplinks: delays in these cases can > > sometimes be of the order of seconds. > [snip] > > > The WG will work on the following: > > > > (1) An experimental congestion control algorithm for > > less-than-best-effort "background" transmissions, i.e., an > > algorithm that attempts to scavenge otherwise idle bandwidth > > for its transmissions in a way that minimizes interference > > with regular best-effort traffic. > > > > Desired features of such an algorithm are: > > * saturate the bottleneck, > > * eliminate long standing queues and thus keep delay low when > > no other traffic is present, > > * quickly yield to regular best-effort traffic that uses > > standard TCP congestion control, > > perhaps it would be more precise to say: > "quickly yield to traffic sharing the same bottleneck queue that uses > standard TCP congestion control" And do we mind about how it reacts to any other congestion control? Do we need to mention possible interactions with other delay-based CC's? > > > * add little to the queueing delays induced by TCP traffic, > > * operate well in today's typical networks with FIFO queueing > > with drop-tail discipline, > > suggest deleting "today's typical" > Agree - not sure we can call anything typical and we don't want to limit our scope too much. > > * where available, use explicit congestion notification (ECN), > > active queue management (AQM), and/or end-to-end > > differentiated services (DiffServ). > [snip] > > > > (2) A document that clarifies the current practices of > > application design and reasons behind them and discusses the > > tradeoffs surrounding the use of many concurrent transport > > connections to one peer and/or to different peers. > > > This is just a bit confusingly worded and could be interpreted very > broadly. I would suggest: > "(2) A document that discusses the > tradeoffs surrounding the use of many concurrent transport > connections to one peer and/or to different peers and recommends best > practices for applications in this regard." > More or less agree with Bruce but it would be nice to make it clearer that we are talking about one or more connections: "(2) A document that discusses the tradeoffs of using many concurrent transport connections to one peer and/or to different peers compared to single transport connections between peers and recommends best practices for applications in this regard." > Finally, I hate the name, because it is so completely undescriptive of > the WG. I like all of Wesley's suggestions better, MILT probably being > the best. Yes the name is awful, but as with all such things we are already getting used to the acronym TANA. However if we do decide to change the name how about: "Congestion-Optimisation for Large Transfers (COLT)" "Transport for Impact Limited Large Transfers (TILTT)" Toby > > Bruce > > > On Oct 21, 2008, at 10:12 AM, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > > > The charter, as written looks reasonable to me. I just hate the name > > :). > > > > Even though you explained it before, "Advanced Network Applications" > > still bothers me as it's completely unspecific. Furthermore, I think > > that "Techniques" isn't well-scoped enough to limit the work properly > > as it seems to be focused on congestion control techniques, and not > > NAT traversal techniques, search techniques, etc. > > > > The way that the problem statement was described, I think what's > > really > > meant is "bulk transfer applications that want to be a good neighbor > > to > > real-time or other applications". I guess the challenge is that this > > doesn't produce a pronouncable acronym like TANA :). > > > > It should really be something like: > > "Minimizing Impact of Large Transfers" (MILT) > > "Concurrent Realtime And Bulk Applications" (CRABA) > > "Fast Transfers Adding Minimal Latency" (FTAML) > > "Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) -- > > probably not a good one as it looks too much like "barfing" :) > > > > But if nobody else has a problem with the TANA name, I'll keep my > > mouth > > shut so we don't waste time and energy. There are bigger fish to > fry! > > > > > > > > > >> -----Original Message----- > >> From: tsv-area-bounces@ietf.org > >> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Stanislav Shalunov > >> Sent: Tuesday, October 21, 2008 9:17 AM > >> To: tana@ietf.org; p2pi@ietf.org; TSV Area > >> Subject: [tsv-area] TANA proposed charter > >> > >> At the BoF in Dublin, we observed strong interest and > >> consensus that the TANA work should go forward as a working > >> group. Does the following proposed charter, based on the BoF > >> description, capture what the community was interested in? > >> > >> Thanks, -- Stas > >> > >> > >> > >> Techniques for Advanced Networking Applications (TANA) WG > >> > >> Chair(s): > >> TBD > >> > >> Transport Area Director(s): > >> * Magnus Westerlund > >> * Lars Eggert > >> > >> Transport Area Advisor: > >> * Lars Eggert > >> > >> Mailing Lists: > >> > >> General Discussion: tana@ietf.org > >> To Subscribe: tana-request@ietf.org > >> In Body: (un)subscribe > >> Archive: http://www.ietf.org/mail-archive/web/tana/ > >> > >> Description of Working Group: > >> > >> The TANA WG is chartered to standardize a congestion control > >> mechanism that should saturate the bottleneck, maintain low > >> delay, and yield to standard TCP. > >> > >> Applications that transmit large amounts of data for a long > >> time with congestion-limited TCP, but without ECN fill the > >> buffer at the head of the bottleneck link. This increases the > >> delay experienced by other applications. In the best case, > >> with an ideally sized buffer of one RTT, the delay doubles. In > >> some cases, the extra delay may be much larger. This is a > >> particularly acute and common case is when P2P applications > >> upload over thin home uplinks: delays in these cases can > >> sometimes be of the order of seconds. > >> > >> The IETF's standard end-to-end transport protocols have not > >> been designed to minimize the extra delay introduced by them into > the > >> network. TCP, as a side effect of filling the buffer until it > >> experiences drop-tail loss, effectively maximizes the delay. > >> While this works well for applications that are not > >> delay-sensitive, it harms interactive applications that share > >> the same bottleneck. VoIP and games are particularly affected, > >> but even web browsing may become problematic. > >> > >> TANA is a transport-area WG that will focus on broadly > >> applicable techniques that allow large amounts of data to be > >> consistently transmitted without substantially affecting the > >> delays experienced by other users and applications. > >> > >> The WG will work on the following: > >> > >> (1) An experimental congestion control algorithm for > >> less-than-best-effort "background" transmissions, i.e., an > >> algorithm that attempts to scavenge otherwise idle bandwidth > >> for its transmissions in a way that minimizes interference > >> with regular best-effort traffic. > >> > >> Desired features of such an algorithm are: > >> * saturate the bottleneck, > >> * eliminate long standing queues and thus keep delay low when > >> no other traffic is present, > >> * quickly yield to regular best-effort traffic that uses > >> standard TCP congestion control, > >> * add little to the queueing delays induced by TCP traffic, > >> * operate well in today's typical networks with FIFO queueing > >> with drop-tail discipline, > >> * where available, use explicit congestion notification (ECN), > >> active queue management (AQM), and/or end-to-end > >> differentiated services (DiffServ). > >> > >> Application of this algorithm to existing transport protocols > >> (TCP, SCTP, DCCP) is expected to occur in the working groups > >> that maintain those protocols. > >> > >> (2) A document that clarifies the current practices of > >> application design and reasons behind them and discusses the > >> tradeoffs surrounding the use of many concurrent transport > >> connections to one peer and/or to different peers. > >> > >> Standard Internet congestion control result in different > >> transport connections sharing bottleneck capacity. When an > >> application uses several unchoked and not rate-limited > >> transport connections to transfer through a bottleneck, it may > >> obtain a larger fraction of the bottleneck than if it had used > >> fewer connections. Although capacity is the most commonly > >> considered bottleneck resource, middlebox state table entries > >> are also an important resource for an end system > >> communication. Other resource types may exist, and the > >> guidelines are expected to comprehensively discuss them. > >> > >> Applications use a variety of techniques to mitigate these > >> concerns. These techniques have not always been reviewed by > >> the IETF and their interaction with TCP dynamics is poorly > >> understood. The WG document the known techniques, discussing > >> the consequences and, where appropriate, provide guidance to > >> application designers. > >> > >> (3) The WG will discuss how to best take into account prior > >> work in the area. The outcome will be either incorporated > >> into the document specifying the experimental congestion > >> control algorithm or into a separate document summarizing prior > work. > >> > >> > >> > >> Goals and Milestones > >> > >> TBD Submit "Multiple Transport Connections in Applications > >> Design" to the IESG for consideration as an Informational RFC > >> TBD Submit "Transport for Advanced Networking Applications > >> (TANA)" to the IESG for consideration as an Experimental RFC > >> > >> > >> Internet-Drafts > >> > >> Transport for Advanced Networking Applications (TANA) Problem > >> Statement > >> http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem > >> -statement-01.txt > >> > >> No Requests for Comments > >> > >> > >> > >> -- > >> Stanislav Shalunov > >> > >> Hacking Startups > >> > >> > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 05:34:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8466B3A69B7; Wed, 22 Oct 2008 05:34:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17873A69E9 for ; Wed, 22 Oct 2008 05:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 oGRoADS14Bhi for ; Wed, 22 Oct 2008 05:34:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A17D63A6886 for ; Wed, 22 Oct 2008 05:34:18 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 14:34:40 +0200 Received: from L-AT7580.rd.francetelecom.fr ([10.193.11.136]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 14:34:39 +0200 Date: Wed, 22 Oct 2008 14:34:39 +0200 (Romance Daylight Time) From: CARLINET Yannick RD-CORE-LAN To: Message-ID: X-X-Sender: FTRDwyce7390yannick.carlinet@ftrdmel3.rd.francetelecom.fr MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2008 12:34:40.0095 (UTC) FILETIME=[8D5D2EF0:01C93442] Subject: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: CARLINET Yannick RD-CORE-LAN List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dear All, Is an alto meeting planned for the 73th ietf meeting ? If yes when will we know the date of this wg meeting ? Thank you very much in advance Best regards -- | Yannick CARLINET - Research engineer | Orange Labs (FT R&D) - CORE/M2I | 2 ave. Pierre Marzin, 22307 Lannion, France | phone +33 2.96.05.03.25 | fax +33 2.96.05.37.84 | yannick.carlinet@orange-ftgroup.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 05:45:10 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0DF3A6A9B; Wed, 22 Oct 2008 05:45:10 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F303A6804; Wed, 22 Oct 2008 05:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, 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 VCy2NeSRdGtf; Wed, 22 Oct 2008 05:45:03 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 91D1A3A692F; Wed, 22 Oct 2008 05:45:03 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9MCjmcd022265; Wed, 22 Oct 2008 05:45:59 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Rolf Winter In-Reply-To: <547F018265F92642B577B986577D671C3E039F@VENUS.office> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 05:45:48 -0700 References: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> <547F018265F92642B577B986577D671C3E039F@VENUS.office> X-Mailer: Apple Mail (2.929.2) Cc: tana@ietf.org, Nicholas Weaver , p2pi@ietf.org, tsv-area@ietf.org, Michael Welzl Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 22, 2008, at 1:49 AM, Rolf Winter wrote: >> >> Besides, there are ISPs that are worried about the effect >> that P2P have on other applications when the link is >> saturated, but otherwise they do not care. P2P would be >> treated like best effort in non-saturated situations (a more >> ECN type approach). > > That is exactly the point. P2P should not "harm" inelastic traffic. > In order to do that, queues should not build up as a consequence of > the P2P traffic. The charter according to my interpretation says > that the most suitable of the set of available means should be used > or any combination of it that makes sense. There are actually at least two sources of harm that BitTorrent and related bulk-data P2P protocols can cause: A) Self harm on access-link buffers: Simply because the protocol will very easily saturate uplinks for residences, and devices ON the uplinks (NAT boxes, etc) are often criminally overbuffered. This is not really affected by the multiple-TCP flow nature of the protocols in question, as a single TCP flow will happily grab the full buffer as well, but P2P protocols tend to be the heaviest user of the uplink. B) Congestion on shared-access uplinks: DOCSIS is explicitly a shared-bandwidth media. Thus a few users of a P2P protocol (many- flow, full-data-rate) can acquire a large amount of the shared channel. Part of the problem: A and B may require different strategies and solutions: A is the one which the P2P developers are most interested in, because that directly harms their customers. If you provide a solution to A, it will be deployed, and quickly. B is the source of conflicts between the ISP and P2P, why ISPs have tried managing the upload rate, and why some ISPs, notably Comcast, are shifting to a network-enforced fairness approach. Dealing with B is what I personally consider essential for a scavenger class protocol, and the more interesting problem, but I think it may be trickier, because you can solve A but not B with delay-based hacks. But solving B also has another problem: If P2P program Gamma and P2P program Delta are sharing the same uplink, and Gamma implements a scavenger protocol, its going to get squeezed out if congestion occurs on the uplink and, if any reciprocity is involved, the user's download is also going to suffer. So there may be reasons for P2P developers to use techniques which solve A AND B, but there doesn't seem to be so clear an incentive for such solutions over solutions for A alone. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 07:42:18 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C6D3A69C5; Wed, 22 Oct 2008 07:42:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55CC3A6886 for ; Wed, 22 Oct 2008 07:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 WCRVGp6V6rtu for ; Wed, 22 Oct 2008 07:42:16 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 0AC373A68AB for ; Wed, 22 Oct 2008 07:42:15 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13477493; Wed, 22 Oct 2008 10:43:12 -0400 Message-Id: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> From: Marshall Eubanks To: CARLINET Yannick RD-CORE-LAN In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 10:43:11 -0400 References: X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org Subject: Re: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 22, 2008, at 8:34 AM, CARLINET Yannick RD-CORE-LAN wrote: > Dear All, > > Is an alto meeting planned for the 73th ietf meeting ? If yes when > will we > know the date of this wg meeting ? The current agenda can be found here : https://datatracker.ietf.org/meeting/73/agenda.html I do not see an ALTO meeting on it. Please note that IETF meeting agendas are subject to change at any time. Regards Marshall > > > Thank you very much in advance > Best regards > > > -- > | Yannick CARLINET - Research engineer > | Orange Labs (FT R&D) - CORE/M2I > | 2 ave. Pierre Marzin, 22307 Lannion, France > | phone +33 2.96.05.03.25 | fax +33 2.96.05.37.84 > | yannick.carlinet@orange-ftgroup.com > > > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:05:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC2A3A68D8; Wed, 22 Oct 2008 08:05:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810DE3A67F2; Tue, 21 Oct 2008 22:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 a3ZGthEbqBHK; Tue, 21 Oct 2008 22:47:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2574E3A6768; Tue, 21 Oct 2008 22:47:22 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 395F0210E5; Wed, 22 Oct 2008 07:48:37 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-56-48febeb5f583 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 128FD210E2; Wed, 22 Oct 2008 07:48:37 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 07:48:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 07:48:36 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> In-Reply-To: <20081021165051.GA64367@zod.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsv-area] TANA proposed charter Thread-Index: Ackznfhh1ziBsxw7RTihMaxxO3ST5QAaBL7Q References: <20081021165051.GA64367@zod.isi.edu> From: "Ingemar Johansson S" To: "Ted Faber" , "Eddy, Wesley M. (GRC-RCN0)[VZ]" X-OriginalArrivalTime: 22 Oct 2008 05:48:36.0509 (UTC) FILETIME=[D388FCD0:01C93409] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700 Cc: p2pi@ietf.org, tana@ietf.org, TSV Area Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Even though I understand that it is better to focus on the charter than in the name I too beleieve that TANA does not say much. I believe that somewhere along the track and also in the charter the term "less than best effort transmission" was/is mentioned A possible name would then be LETBET (LEss Than Best Effort Transport) That said... there are a whole bunch of WG names out there that at first glance does not say anything about the group. The charter looks OK from my perspective. /Ingemar > -----Original Message----- > From: tsv-area-bounces@ietf.org > [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber > Sent: den 21 oktober 2008 18:51 > To: Eddy, Wesley M. (GRC-RCN0)[VZ] > Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > Subject: Re: [tsv-area] TANA proposed charter > > On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > (GRC-RCN0)[VZ] wrote: > > But if nobody else has a problem with the TANA name, I'll keep my > > mouth shut so we don't waste time and energy. There are > bigger fish to fry! > > It should change. > > I care about congestion control and nothing in the expansion > of TANA indicated it was about congestion (to me). > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:05:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8358D28C153; Wed, 22 Oct 2008 08:05:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0EE3A6886; Tue, 21 Oct 2008 23:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 Sr4G+VqMN5H3; Tue, 21 Oct 2008 23:19:36 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 720F43A6835; Tue, 21 Oct 2008 23:19:36 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C168F198DF7; Wed, 22 Oct 2008 08:20:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B1631198DFE; Wed, 22 Oct 2008 08:20:27 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 977F7A05D1; Wed, 22 Oct 2008 08:20:27 +0200 (CEST) Message-ID: <48FEC5C9.6060101@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 08:18:49 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ingemar Johansson S References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700 Cc: p2pi@ietf.org, TSV Area , tana@ietf.org, Ted Faber , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, I also find the charter good and like Ingemar's name proposal "LETBET (LEss Than Best Effort Transport)" Michael Ingemar Johansson S wrote: > Hi > > Even though I understand that it is better to focus on the charter than > in the name I too beleieve that TANA does not say much. > > I believe that somewhere along the track and also in the charter the > term "less than best effort transmission" was/is mentioned > A possible name would then be > > LETBET (LEss Than Best Effort Transport) > > That said... there are a whole bunch of WG names out there that at first > glance does not say anything about the group. > > The charter looks OK from my perspective. > > /Ingemar > > >> -----Original Message----- >> From: tsv-area-bounces@ietf.org >> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber >> Sent: den 21 oktober 2008 18:51 >> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >> Subject: Re: [tsv-area] TANA proposed charter >> >> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >> (GRC-RCN0)[VZ] wrote: >> >>> But if nobody else has a problem with the TANA name, I'll keep my >>> mouth shut so we don't waste time and energy. There are >>> >> bigger fish to fry! >> >> It should change. >> >> I care about congestion control and nothing in the expansion >> of TANA indicated it was about congestion (to me). >> >> -- >> Ted Faber >> http://www.isi.edu/~faber PGP: >> http://www.isi.edu/~faber/pubkeys.asc >> Unexpected attachment on this mail? See >> http://www.isi.edu/~faber/FAQ.html#SIG >> >> > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:05:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D6028C16F; Wed, 22 Oct 2008 08:05:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CE03A6A03; Wed, 22 Oct 2008 00:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.314 X-Spam-Level: X-Spam-Status: No, score=-5.314 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 qYey3IQGsDU7; Wed, 22 Oct 2008 00:52:23 -0700 (PDT) Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id BD2A33A6946; Wed, 22 Oct 2008 00:52:22 -0700 (PDT) Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id m9M7rXjd032661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 22 Oct 2008 09:53:33 +0200 From: Michael Welzl To: tana@ietf.org, p2pi@ietf.org, tsv-area@ietf.org In-Reply-To: <48FED1E8.7080101@ericsson.com> References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> <48FEC5C9.6060101@informatik.uni-wuerzburg.de> <48FED1E8.7080101@ericsson.com> Organization: University of Innsbruck Date: Wed, 22 Oct 2008 09:53:33 +0200 Message-Id: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700 Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree 100%, about both - charter and LETBET (which is my favorite name proposal) Cheers, Michael On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: > Hi, > > I also think the charter is very well scoped. > > However I'd like to see the *multiple connections* work item elaborated > and explained a little bit more! > > about the name proposal both "LETBET (LEss Than Best Effort Transport)" and > "Scavenger Network Congestion Protocols" sound good proposal to me. > > /sal > > Michael Menth wrote: > > Hi, > > > > I also find the charter good and like Ingemar's name proposal "LETBET > > (LEss Than Best Effort Transport)" > > > > Michael > > > > Ingemar Johansson S wrote: > >> Hi > >> > >> Even though I understand that it is better to focus on the charter than > >> in the name I too beleieve that TANA does not say much. > >> > >> I believe that somewhere along the track and also in the charter the > >> term "less than best effort transmission" was/is mentioned > >> A possible name would then be > >> LETBET (LEss Than Best Effort Transport) > >> > >> That said... there are a whole bunch of WG names out there that at first > >> glance does not say anything about the group. > >> The charter looks OK from my perspective. > >> > >> /Ingemar > >> > >> > >>> -----Original Message----- > >>> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] > >>> On Behalf Of Ted Faber > >>> Sent: den 21 oktober 2008 18:51 > >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] > >>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > >>> Subject: Re: [tsv-area] TANA proposed charter > >>> > >>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > >>> (GRC-RCN0)[VZ] wrote: > >>> > >>>> But if nobody else has a problem with the TANA name, I'll keep my > >>>> mouth shut so we don't waste time and energy. There are > >>> bigger fish to fry! > >>> > >>> It should change. > >>> > >>> I care about congestion control and nothing in the expansion of TANA > >>> indicated it was about congestion (to me). > >>> > >>> -- > >>> Ted Faber > >>> http://www.isi.edu/~faber PGP: > >>> http://www.isi.edu/~faber/pubkeys.asc > >>> Unexpected attachment on this mail? See > >>> http://www.isi.edu/~faber/FAQ.html#SIG > >>> > >>> > >> _______________________________________________ > >> tana mailing list > >> tana@ietf.org > >> https://www.ietf.org/mailman/listinfo/tana > >> > > > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:05:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36DF28C177; Wed, 22 Oct 2008 08:05:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCA83A69E9; Wed, 22 Oct 2008 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, 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 NLH4ifpZDx3C; Wed, 22 Oct 2008 02:17:28 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id B8B113A693A; Wed, 22 Oct 2008 02:17:27 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1KsZrE-0002Km-SI; Wed, 22 Oct 2008 11:18:26 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1KsZrE-0005vF-P9; Wed, 22 Oct 2008 11:18:24 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A0E7B2FC04F; Wed, 22 Oct 2008 11:18:24 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id AC7FE10390; Wed, 22 Oct 2008 11:18:21 +0200 (CEST) Message-ID: <48FEEFDB.6000801@tm.uka.de> Date: Wed, 22 Oct 2008 11:18:19 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700 Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org, Michael Welzl Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Reinaldo, Reinaldo Penno wrote: > I'm not sure I'm reading the semantics of "Less than Best Effort" like other > folks. Maybe RFC 3662 defines this more clearly. > 'Best Effort' has a well-defined semantics in the scope of Diffserv, > including a code point of its own. Less than best effort seems we are > defining a code point for such applications. Are we? The charter talks about > 'end-to-end Diffserv'. See RFC 3662 > End-to-end diffserv is a challenge on its own given ISP policies, etc. > > If the link is not saturated, are such application also treated as 'less > than best effort' by still being DSCP marked and treated differently within > routers? Usually lower effort (LE) packets will go into a different queue and served only if no other BE packets are waiting. So if the BE queue is empty, LE packets will get the same treatment as BE packets. Only in case of congestion, LE packets will be treated differently. > I would like if possible to decouple the 'less than best effort', as in > diffserv, from the algorithm per se. > > Besides, there are ISPs that are worried about the effect that P2P have on > other applications when the link is saturated, but otherwise they do not > care. P2P would be treated like best effort in non-saturated situations (a > more ECN type approach). Yes, and that's exactly where LE helps: an ISP can be sure that LE traffic will not harm other BE traffic at any time. In case of congestion BE traffic will preempt LE traffic. If the link is not saturated, LE will be treated like BE. Regards, Roland _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:05:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3413C28C17C; Wed, 22 Oct 2008 08:05:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8A73A6886; Wed, 22 Oct 2008 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 8v3FCKnN1nxo; Wed, 22 Oct 2008 07:27:15 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 50B373A697E; Wed, 22 Oct 2008 07:27:15 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1KsegH-0000Mo-9H; Wed, 22 Oct 2008 16:27:29 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1KsegH-0006n6-3f; Wed, 22 Oct 2008 16:27:25 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 00F0C2FC037; Wed, 22 Oct 2008 16:27:25 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 2C31C10390; Wed, 22 Oct 2008 16:27:23 +0200 (CEST) Message-ID: <48FF384B.7060105@tm.uka.de> Date: Wed, 22 Oct 2008 16:27:23 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-Mailman-Approved-At: Wed, 22 Oct 2008 08:05:26 -0700 Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org, Michael Welzl Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Reinaldo, Reinaldo Penno wrote: > Thanks Roland. I remember some of these discussions. Is there any effort to > make it standard, particularly the DSCP so the algorithm can use it? There was a decision in the DiffServ WG that Per Domain Behaviors have to be Informational RFCs. There is a recommended codepoint of using CSC 1 (see RFC 2474), i.e. 001000 as DSCP value for the LE PDB. Regards, Roland _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:24:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0970328C13D; Wed, 22 Oct 2008 08:24:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7740328C118; Wed, 22 Oct 2008 08:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, 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 iVeYBX1qDIDD; Wed, 22 Oct 2008 08:24:10 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6655328C11C; Wed, 22 Oct 2008 08:24:10 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9MFP7x3010650; Wed, 22 Oct 2008 08:25:12 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Roland Bless In-Reply-To: <48FEEFDB.6000801@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 08:25:06 -0700 References: <48FEEFDB.6000801@tm.uka.de> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, tsv-area@ietf.org, tana@ietf.org, Nicholas Weaver Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 22, 2008, at 2:18 AM, Roland Bless wrote: >> I would like if possible to decouple the 'less than best effort', >> as in >> diffserv, from the algorithm per se. >> >> Besides, there are ISPs that are worried about the effect that P2P >> have on >> other applications when the link is saturated, but otherwise they >> do not >> care. P2P would be treated like best effort in non-saturated >> situations (a >> more ECN type approach). > > Yes, and that's exactly where LE helps: an ISP can be sure that > LE traffic will not harm other BE traffic at any time. In case > of congestion BE traffic will preempt LE traffic. If the > link is not saturated, LE will be treated like BE. This is also roughly how Comcast is implementing fairness on their network: Any user identified as being above a threshold of usage (averaged over ~15 minutes) is placed into a lower QoS category. And as long as there is at least some capacity headroom left over, the heavy users aren't starved out, the light users don't notice, and the heavy users traffic just negotiates between itself. However, this brings up a question: Should a scavenger service be true LE, if the network does not support QoS? In such a case, the service can't yield instantly anyway, so the question is what is the equilibrium it goes to relative to other flows. Should it actually yield completely to other TCP flows on the network? Or should it instead have some equilibrium position thats a stated fraction of what a normal TCP flow would achieve under the circumstances? EG, a "Scavenger App" has N flows, on a congested link shared with a significant number of normal TCP flows. Given x is the equilibrium transfer rate of a single TCP flow. If the scavenger app's flows were normal TCP, the equilibrium point in congestion with others would be Nx Should the goal be to have the equilibrium value be X? (No matter the # of peers, the app behaves like a single TCP flow for equilibrium purposes) Should the goal be to have the equilibrium be some fraction of X? Zero? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:26:10 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D0428C16A; Wed, 22 Oct 2008 08:26:10 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AD83A697E; Wed, 22 Oct 2008 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 mEfg4abVXhy7; Wed, 22 Oct 2008 08:26:08 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 6E8763A689A; Wed, 22 Oct 2008 08:26:04 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13478756; Wed, 22 Oct 2008 11:27:01 -0400 Message-Id: From: Marshall Eubanks To: Reinaldo Penno In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 11:26:59 -0400 References: X-Mailer: Apple Mail (2.929.2) Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org, Michael Welzl Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I am not sure that this is still a charter discussion, but... On Oct 22, 2008, at 4:28 AM, Reinaldo Penno wrote: > I'm not sure I'm reading the semantics of "Less than Best Effort" > like other > folks. > > 'Best Effort' has a well-defined semantics in the scope of Diffserv, > including a code point of its own. Less than best effort seems we are > defining a code point for such applications. Are we? I absolutely think that we should. This has been proposed before - RFC 3662 Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] may be used as the PHB for the LE traffic aggregate. This document does not specify the exact DSCP to use inside a domain, but instead specifies the necessary properties of the PHB selected by the DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. ... The notion of having something "lower than Best Effort" was raised in the Diffserv Working Group, most notably by Roland Bless and Klaus Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for enterprise multimedia applications. One of its first applications was to re-mark packets within multicast groups [NRS]. Therefore, previous discussions centered on the creation of a new PHB. However, the original authors (Brian Carpenter and Kathleen Nichols) believe this is not required and this document was written to specifically explain how to get less than Best Effort without a new PHB. > The charter talks about > 'end-to-end Diffserv'. > > > End-to-end diffserv is a challenge on its own given ISP policies, etc. > Much of which LTBE gets around. (It does not directly hurt LTBE traffic to turn it into BE traffic, and it provides a benefit to the ISP to keep it LTBE, unlike the case for priority "Better than best effort" diffserve codepoints, where you realistically need a contract with the ISP to get them to prioritize it, and where it does potentially hurt the traffic to turn it into BE.) I have talked to ISP representatives about this and they have been generally supportive both of the concept and of honoring the LTBE tag (which, after all, gives them the green light to drop the traffic). > If the link is not saturated, are such application also treated as > 'less > than best effort' by still being DSCP marked and treated differently > within > routers? I would regard that as an implementation detail. If LTBE translated into "do not queue this traffic" (for a high level view of queuing - my understanding is that some queuing may be unavoidable "under the hood" in some routers) then this traffic would be treated like best effort in non-saturated situations. A "do not resuscitate" request has no actual effect as long as the patient does not need resuscitation. I would envision this as working similarly. > > > I would like if possible to decouple the 'less than best effort', as > in > diffserv, from the algorithm per se. > > Besides, there are ISPs that are worried about the effect that P2P > have on > other applications when the link is saturated, but otherwise they do > not > care. P2P would be treated like best effort in non-saturated > situations (a > more ECN type approach). I think that in almost any scheme LTBE traffic would be treated like best effort in non-saturated situations. > > > Thanks, > > Reinaldo > > Regards Marshall > On 10/22/08 12:53 AM, "Michael Welzl" > wrote: > >> I agree 100%, about both - charter and LETBET (which is my >> favorite name proposal) >> >> Cheers, >> Michael >> >> >> On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote: >>> Hi, >>> >>> I also think the charter is very well scoped. >>> >>> However I'd like to see the *multiple connections* work item >>> elaborated >>> and explained a little bit more! >>> >>> about the name proposal both "LETBET (LEss Than Best Effort >>> Transport)" and >>> "Scavenger Network Congestion Protocols" sound good proposal to me. >>> >>> /sal >>> >>> Michael Menth wrote: >>>> Hi, >>>> >>>> I also find the charter good and like Ingemar's name proposal >>>> "LETBET >>>> (LEss Than Best Effort Transport)" >>>> >>>> Michael >>>> >>>> Ingemar Johansson S wrote: >>>>> Hi >>>>> >>>>> Even though I understand that it is better to focus on the >>>>> charter than >>>>> in the name I too beleieve that TANA does not say much. >>>>> >>>>> I believe that somewhere along the track and also in the charter >>>>> the >>>>> term "less than best effort transmission" was/is mentioned >>>>> A possible name would then be >>>>> LETBET (LEss Than Best Effort Transport) >>>>> >>>>> That said... there are a whole bunch of WG names out there that >>>>> at first >>>>> glance does not say anything about the group. >>>>> The charter looks OK from my perspective. >>>>> >>>>> /Ingemar >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: tsv-area-bounces@ietf.org [mailto:tsv-area- >>>>>> bounces@ietf.org] >>>>>> On Behalf Of Ted Faber >>>>>> Sent: den 21 oktober 2008 18:51 >>>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>>>>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>>>>> Subject: Re: [tsv-area] TANA proposed charter >>>>>> >>>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>>>>> (GRC-RCN0)[VZ] wrote: >>>>>> >>>>>>> But if nobody else has a problem with the TANA name, I'll keep >>>>>>> my >>>>>>> mouth shut so we don't waste time and energy. There are >>>>>> bigger fish to fry! >>>>>> >>>>>> It should change. >>>>>> >>>>>> I care about congestion control and nothing in the expansion of >>>>>> TANA >>>>>> indicated it was about congestion (to me). >>>>>> >>>>>> -- >>>>>> Ted Faber >>>>>> http://www.isi.edu/~faber PGP: >>>>>> http://www.isi.edu/~faber/pubkeys.asc >>>>>> Unexpected attachment on this mail? See >>>>>> http://www.isi.edu/~faber/FAQ.html#SIG >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> tana mailing list >>>>> tana@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tana >>>>> >>>> >>> >>> _______________________________________________ >>> tana mailing list >>> tana@ietf.org >>> https://www.ietf.org/mailman/listinfo/tana >>> >> >> _______________________________________________ >> tana mailing list >> tana@ietf.org >> https://www.ietf.org/mailman/listinfo/tana > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 08:32:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DA428C17F; Wed, 22 Oct 2008 08:32:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDCC28C177; Wed, 22 Oct 2008 08:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 shlLp05IIKUZ; Wed, 22 Oct 2008 08:32:12 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 4093128C162; Wed, 22 Oct 2008 08:32:11 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13478888; Wed, 22 Oct 2008 11:32:54 -0400 Message-Id: <9821BF99-1F8F-41BE-8E6C-28A9E6EE8427@multicasttech.com> From: Marshall Eubanks To: Nicholas Weaver In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 11:32:52 -0400 References: <48FEEFDB.6000801@tm.uka.de> X-Mailer: Apple Mail (2.929.2) Cc: tsv-area@ietf.org, tana@ietf.org, Roland Bless , p2pi@ietf.org Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 22, 2008, at 11:25 AM, Nicholas Weaver wrote: > > On Oct 22, 2008, at 2:18 AM, Roland Bless wrote: >>> I would like if possible to decouple the 'less than best effort', >>> as in >>> diffserv, from the algorithm per se. >>> >>> Besides, there are ISPs that are worried about the effect that P2P >>> have on >>> other applications when the link is saturated, but otherwise they >>> do not >>> care. P2P would be treated like best effort in non-saturated >>> situations (a >>> more ECN type approach). >> >> Yes, and that's exactly where LE helps: an ISP can be sure that >> LE traffic will not harm other BE traffic at any time. In case >> of congestion BE traffic will preempt LE traffic. If the >> link is not saturated, LE will be treated like BE. > > This is also roughly how Comcast is implementing fairness on their > network: Any user identified as being above a threshold of usage > (averaged over ~15 minutes) is placed into a lower QoS category. > And as long as there is at least some capacity headroom left over, > the heavy users aren't starved out, the light users don't notice, > and the heavy users traffic just negotiates between itself. > However, this brings up a question: > > Should a scavenger service be true LE, if the network does not > support QoS? In such a case, the service can't yield instantly > anyway, so the question is what is the equilibrium it goes to > relative to other flows. > If the network doesn't support QOS, how would it know ? If I am ignoring code points, how do I know what the code point is ? Regards Marshall > Should it actually yield completely to other TCP flows on the network? > > Or should it instead have some equilibrium position thats a stated > fraction of what a normal TCP flow would achieve under the > circumstances? > > > EG, a "Scavenger App" has N flows, on a congested link shared with a > significant number of normal TCP flows. > > Given x is the equilibrium transfer rate of a single TCP flow. > > If the scavenger app's flows were normal TCP, the equilibrium point > in congestion with others would be Nx > > Should the goal be to have the equilibrium value be X? (No matter > the # of peers, the app behaves like a single TCP flow for > equilibrium purposes) > > Should the goal be to have the equilibrium be some fraction of X? > Zero? > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 09:16:24 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E74A28C0E8; Wed, 22 Oct 2008 09:16:24 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F433A6920; Wed, 22 Oct 2008 09:16:22 -0700 (PDT) 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 s+EexFuIZWkf; Wed, 22 Oct 2008 09:16:16 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4BFA33A68AB; Wed, 22 Oct 2008 09:15:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9MGGdD26030; Wed, 22 Oct 2008 18:16:39 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp8182.cisco.com [10.61.95.245]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9MGGUG25735; Wed, 22 Oct 2008 18:16:30 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 22 Oct 2008 18:16:29 +0200 From: stefano previdi To: David Ward , Lisa Dusseault Message-ID: Thread-Topic: [p2pi] ASN utility Thread-Index: Ack0YYoWyH3UBKBUEd2gxwAX8vOM8g== In-Reply-To: <9428A91F-D7AC-4C91-85CF-4A5EB3721589@cisco.com> Mime-version: 1.0 Cc: p2pi@ietf.org, IESG IESG Subject: Re: [p2pi] ASN utility X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dave, I mostly agree with you. Just a few points below: > From: David Ward > > Lisa - > > My issue is that the charter has ASN as a viable item to return to a > query without limiting how the ASN is to be gleaned. The solution you > state below "avoid this ASN" is a bit different than an dynamically > generated, ordered list of preferred ASN based on current routing > "proximity" or "reachability." In addition, information about > specific attributes and topologic information could be useful, e.g. > AS path list (vs just AS origin information) for transit "hints." > There could be a query "give me prefixes and/or ASN that are tagged > w/ X community" (where the community represents SP preference. > Another easy one to think about "give me servers|prefixes in AS X > that don't traverse AS Y." > > There is obviously a large amount of routing data (passed in routing > protocols along w/ other attributes associated with the prefix, peer, > AS, exit point, policy, cost, topologic location, etc) that could be > used in the future for very interesting preference schemes. indeed and note that some of this is already used in 'some' implementations... > Generally this information is passed in BGP or other routing/ > signaling protocols. That would mean that the ALTO server would need > to be a peer or member of the routing system to get this information > and routing protocol extensions (e.g. BGP) may be necessary. I'd prefer to rephrase stating that the alto server would need to access routing layer information. Having to be a participant is a bit constraintful to me. > Therefore, this interaction and these extensions would be in or out > of charter. I was confused how far this would go. > > If instead you want to limit the server to passing "policy and > preference information" which in this case is akin to a list of hand > configured objects (e.g. list of ASN you want some client to prefer) > that has no other relationship to the routing system, then let's put > that in the charter. I assume the client in this case would get the > ASN, "query" some looking-glass server and make decisions. Well, I hope we can go a bit beyond that. But again, I'm not sure we have to specify any 'interaction' between alto server and routing layer. Either the alto server has some form of proprietary mechanisms in order to acquire routing knowledge, either it uses well known standardized interfaces such as igp adjacencies and bgp sessions. > I think there are a lot of very interesting services to think about > when the ALTO server *is* a peer of the routing system but, if the WG > doesn't want to go down this path ... I'd just like it clarified in > the charter. If you want it watered down further, I'd like it stated > in the charter that the outcome of the framework document will make > it clear and please mention that it is specifically to be worked on. The alto server needs not to be a participant into the routing layer as it will raise too many other issues that we would have to address (and probably in different WGs). This doesn't mean you can't do that... it's just that I don't think we have to enforce this rule. But there's no question on whether or not an alto server should get the routing layer info or optimizing localization computation. I believe it proved to help. s. > -DWard > > > On Sep 29, 2008, at 12:38 PM, Lisa Dusseault wrote: > >> >> When the IESG looked at the proposed ALTO charter last week, Dave >> had some comments about ASNs which I'd like to follow up on by >> dragging Dave into the conversation. >> >> What I understand the ASN related suggestions so far to be, is to >> have the ALTO server return a list of ASN numbers to prefer or >> avoid. This sort of information could only be provided by an ISP- >> operated ALTO server. A peer, armed with this information, can do >> whatever they do today to figure >> out which IP address falls in which ASN. The P4P and Yale folks >> claim that returning a preference of ASNs helped their application >> tremendously. >> >> Dave, was your concern about discovering ASN being unnecessary, or >> about ranking of ASNs being unhelpful? Can you recap? >> >> Thanks, >> Lisa > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 09:44:43 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7ADC28C148; Wed, 22 Oct 2008 09:44:43 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978C13A69BA for ; Wed, 22 Oct 2008 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 dflNwdnrz3Vm for ; Wed, 22 Oct 2008 09:44:40 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by core3.amsl.com (Postfix) with ESMTP id 4B0173A68AC for ; Wed, 22 Oct 2008 09:44:40 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id f17so3916523qba.41 for ; Wed, 22 Oct 2008 09:45:56 -0700 (PDT) Received: by 10.114.56.1 with SMTP id e1mr7776864waa.69.1224693955707; Wed, 22 Oct 2008 09:45:55 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 4sm12266722yxd.2.2008.10.22.09.45.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 09:45:55 -0700 (PDT) Message-Id: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> From: Stanislav Shalunov To: p2pi@ietf.org, tana@ietf.org, "tsv-area@ietf.org Area" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 09:45:52 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [p2pi] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org A refreshed working copy of the draft charter. I've attempted to capture and reconcile the edits and clarify point (2). We'll need to change the name, but it's not yet reflected because a new one hasn't been selected. -- Stas Techniques for Advanced Networking Applications (TANA) WG Chair(s): TBD Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Lars Eggert Mailing Lists: General Discussion: tana@ietf.org To Subscribe: tana-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/tana/ Description of Working Group: The TANA WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. TANA is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best- effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck, * eliminate long standing queues and thus keep delay low when no other traffic is present, * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control, * add little to the queueing delays induced by TCP traffic, * operate well in networks with FIFO queueing with drop-tail discipline, * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. (3) The WG will discuss how to best take into account prior work in the area. The outcome will be either incorporated into the document specifying the experimental congestion control algorithm or into a separate document summarizing prior work. Goals and Milestones TBD Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC TBD Submit "Transport for Advanced Networking Applications (TANA)" to the IESG for consideration as an Experimental RFC Internet-Drafts Transport for Advanced Networking Applications (TANA) Problem Statement http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt No Requests for Comments -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 10:51:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8073A69B2; Wed, 22 Oct 2008 10:51:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079713A69B2; Wed, 22 Oct 2008 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 umJrMcn8FIRE; Wed, 22 Oct 2008 10:51:45 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 802B43A6970; Wed, 22 Oct 2008 10:51:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 57A75E10D2E; Wed, 22 Oct 2008 13:53:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT1wnI-wqauz; Wed, 22 Oct 2008 13:52:50 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1660FE10D3F; Wed, 22 Oct 2008 13:52:50 -0400 (EDT) Date: Wed, 22 Oct 2008 13:52:50 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <1012819135.391531224697970032.JavaMail.root@dkny.pando.com> In-Reply-To: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: "tsv-area@ietf.org Area" , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nice job. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: p2pi@ietf.org, tana@ietf.org, "tsv-area@ietf.org Area" Sent: Wednesday, October 22, 2008 12:45:52 PM (GMT-0500) America/New_York Subject: Re: [p2pi] [tana] TANA proposed charter A refreshed working copy of the draft charter. I've attempted to capture and reconcile the edits and clarify point (2). We'll need to change the name, but it's not yet reflected because a new one hasn't been selected. -- Stas Techniques for Advanced Networking Applications (TANA) WG Chair(s): TBD Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Lars Eggert Mailing Lists: General Discussion: tana@ietf.org To Subscribe: tana-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/tana/ Description of Working Group: The TANA WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. TANA is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best- effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck, * eliminate long standing queues and thus keep delay low when no other traffic is present, * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control, * add little to the queueing delays induced by TCP traffic, * operate well in networks with FIFO queueing with drop-tail discipline, * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. (3) The WG will discuss how to best take into account prior work in the area. The outcome will be either incorporated into the document specifying the experimental congestion control algorithm or into a separate document summarizing prior work. Goals and Milestones TBD Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC TBD Submit "Transport for Advanced Networking Applications (TANA)" to the IESG for consideration as an Experimental RFC Internet-Drafts Transport for Advanced Networking Applications (TANA) Problem Statement http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt No Requests for Comments -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 11:38:48 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF063A6821; Wed, 22 Oct 2008 11:38:48 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F163A69B7; Wed, 22 Oct 2008 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.822, 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 2sJiAysm9KB3; Wed, 22 Oct 2008 09:53:19 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 97D513A6778; Wed, 22 Oct 2008 09:53:19 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9MGs2Og019474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Oct 2008 12:54:02 -0400 Date: Wed, 22 Oct 2008 12:54:01 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Nicholas Weaver In-Reply-To: Message-ID: MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Oct 2008 11:38:48 -0700 Cc: "ietf@ietf.org" , "p2pi@ietf.org" , IESG IESG , Karl Auerbach Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Tue, 21 Oct 2008, Nicholas Weaver wrote: > Hey, stupid thought... > > Could you do proximity based on "who's your DNS resolver"? Do a few > name lookups: one to register YOU as using YOUR DNS resolver to the > remote coordinator, and one to get "who are other peers using the same > resolver"? > > An ugly, UGLY hack, but it might be interesting to think about. > > Has anyone done this already? This is a very good idea. You can get 'who are your peers?' through BGP analysis. (look at quagga/zebra). Quagga can get routes from the routers, and then do whatever, feed that to a database, etc. So one could start with BGP data, and then perhaps test and cache actual hops to the target, rather like DNS, but not actually DNS. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 11:57:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B9B3A6A5A; Wed, 22 Oct 2008 11:57:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB6B3A6895; Wed, 22 Oct 2008 11:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, 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 y4Ir0Qf+sELS; Wed, 22 Oct 2008 11:56:58 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 26EF43A683B; Wed, 22 Oct 2008 11:56:57 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 20:58:13 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 20:58:12 +0200 Received: from [172.16.82.10] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 20:58:11 +0200 Message-ID: <48FF77C0.3080900@telecomitalia.it> Date: Wed, 22 Oct 2008 20:58:08 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Stanislav Shalunov References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> In-Reply-To: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 22 Oct 2008 18:58:11.0368 (UTC) FILETIME=[2126CA80:01C93478] Cc: "tsv-area@ietf.org Area" , "tana@ietf.org" , "p2pi@ietf.org" Subject: Re: [p2pi] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937176298==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0937176298== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040509060104050602060403" This is a cryptographically signed message in MIME format. --------------ms040509060104050602060403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I like the charter, just one more fix. Stanislav Shalunov wrote: > Applications that transmit large amounts of data for a long time with > congestion-limited TCP, but without AQM, fill the buffer at the head > of the bottleneck link. With FIFO queue, this increases the delay > experienced by other applications. With buffer of one RTT, the delay > doubles. In some cases, the extra delay may be much larger. This is a > particularly acute and common case is when P2P applications upload > over thin home uplinks: delays in these cases can sometimes be of the > order of seconds. Last sentence should be: "A particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds." -- Ciao, Enrico --------------ms040509060104050602060403 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjIxODU4MDhaMCMG CSqGSIb3DQEJBDEWBBTb8wHSQTOWguLBs+PcnJu89hfPYjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAAorYIrhwwD6 7rUKpD64MlRiqr1owzJF0+a1ItaRHR5TGfZugwQRNn5/VntosVmsjKpsrZhnLfPtRoqU1fKM TuCQx+4kAWA9JNRDjaraOZ10dQ7RQxQNpzYnp8qZjmPLJwV6L9tplZ6c2ISay6vwgOS42x0o Pfa/hGpAUQVAnEaN+nHZdPoFA2BHuE5dOPLGo6o2urAgqyO+HtaiOSJOj3EDBEF/cSqymfCN Sxv7CY6gqLl6TJX0fVUVAm5Y4KJXFBkJ6JrUKgVRyCwSSLfpazMtFhqAKacYHCOeYeSjGdwD 5/3/8LXcZsAk+N1w9c1/Ecgje2o1BuQN93fx7/6g7AcAAAAAAAA= --------------ms040509060104050602060403-- --===============0937176298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0937176298==-- From p2pi-bounces@ietf.org Wed Oct 22 17:49:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BED328C170; Wed, 22 Oct 2008 17:49:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5482E28C14A; Wed, 22 Oct 2008 17:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.135 X-Spam-Level: X-Spam-Status: No, score=-105.135 tagged_above=-999 required=5 tests=[AWL=1.464, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bToGevTSxncw; Wed, 22 Oct 2008 17:49:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CBCB13A685E; Wed, 22 Oct 2008 17:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224723055; x=1256259055; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20IESG=20IESG=20|CC:=20"p2pi@ietf.org"=20 ,=20"ietf@ietf.org"=20 |Date:=20Wed,=2022=20Oct=202008=2017:50:51=20-0700 |Subject:=20RE:=20WG=20Review:=20Application-Layer=20Traf fic=20Optimization=20(alto)=20|Thread-Topic:=20WG=20Revie w:=20Application-Layer=20Traffic=20Optimization=20(alto) =20|Thread-Index:=20Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUw |Message-ID:=20|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>|In-Reply-To:=20<20081006203 532.B1D673A68AF@core3.amsl.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5412"=3B=20a=3D"11277959"; bh=iXxtLGE0PWf/LLZZKuogbjYDRFP031pw6hUBiGc5RbY=; b=FyzVSOquGOLS7J1rJCYo6SrLIIaN+WWUkrNPELMKuJrlEHevgqf9Way3 FhVnYbiJCAGZTr3zHi/yM9FZOnYVjiHdfjJ8773ljpne8J3kaRJQX60oM prJodx995waPNIhGR/uXhhqI98upCSobNeduxNot/zVnoP9uSme0NpkMF k=; X-IronPort-AV: E=McAfee;i="5300,2777,5412"; a="11277959" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2008 17:50:54 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9N0osZ6006128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Oct 2008 17:50:54 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9N0orKA028746 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Oct 2008 17:50:53 -0700 (PDT) Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 22 Oct 2008 17:50:53 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 22 Oct 2008 17:50:53 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 22 Oct 2008 17:50:52 -0700 From: "Narayanan, Vidya" To: IESG IESG Date: Wed, 22 Oct 2008 17:50:51 -0700 Thread-Topic: WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUw Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org All, We have submitted a draft explaining the overall problem of peer selection - http://www.ietf.org/internet-drafts/draft-saumitra-alto-multi-ps-00.txt. Below are my suggested revisions to the charter based on arguments the draft puts forth (and based on emails exchanged over the last several days). Thanks, Vidya > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Monday, October 06, 2008 1:36 PM > To: IETF Announcement list > Cc: p2pi@ietf.org > Subject: WG Review: Application-Layer Traffic Optimization (alto) > > A new IETF working group has been proposed in the > Applications Area. The IESG has not made any determination > as yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by Monday, > October 13, 2008. > > Application-Layer Traffic Optimization (alto) > ============================================= > Last Modified: 2008-09-29 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Applications Area Director(s): > > Lisa Dusseault (lisa at osafoundation.org) Chris Newman > (Chris.Newman at sun.com) > > Applications Area Advisor: > > Lisa Dusseault (lisa at osafoundation.org) > > Mailing List: > > General Discussion: p2pi at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi > Archive: http://www.ietf.org/pipermail/p2pi/ > > Description of Working Group: > > A significant part of the Internet traffic today is generated > by peer-to-peer (P2P) applications used for file sharing, > real-time communications, and live media streaming. P2P > applications exchange large amounts of data, often uploading > as much as downloading. In contrast to client/server > architectures, P2P applications often have a selection of > peers and must choose. > Add: "Peer selection is also a problem that has many different applications in p2p systems - e.g., identifying the best peer to download content from, identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc." > One of the advantages of P2P systems comes from redundancy in > resource availability. This requires choosing among download > locations, s/download locations/a list of peers > yet applications have at best incomplete > information about the topology of the network. s/incomplete information about the topology of the network/incomplete information to help the selection, e.g., topology of the network. > Applications > can sometimes make empirical measurements of link > performance, but even when this is an option it takes time. > The application cannot always start out with an optimal > arrangement of peers, thus causing at least temporary reduced > performance and excessive cross-domain traffic. Providing > more information for use in peer selection can improve P2P > performance and lower ISP costs. > > The Working Group will design and specify an > Application-Layer Traffic Optimization (ALTO) service that > will provide applications with information to perform > better-than-random initial peer selection. > ALTO services may take different approaches at balancing > factors including s/including/such as > maximum bandwidth, minimum cross-domain > traffic, lowest cost to the user, etc. The WG will consider > the needs of BitTorrent, tracker-less P2P, and other > applications, such as content delivery networks (CDN) and > mirror selection. > > The WG will focus on the following items: > > - A "problem statement" document providing a description of the > problem and a common terminology. > > - A requirements document. This document will list > requirements for the ALTO service, identifying, for example, > what kind of information P2P applications will need for > optimizing their choices. > I propose deleting "identifying, for example, what kind of information P2P applications will need for optimizing their choices". > - A request/response protocol for querying the ALTO service > to obtain information useful for peer selection, and a format > for requests and > responses. I suggest replacing this with Stanislav's suggestion: "A complete mechanism that enables clients to learn from the ALTO service information useful for peer selection". > The WG does not require intermediaries between the ALTO > server and the peer querying it. s/the ALTO server and the peer querying it/the communicating ALTO endpoints. > If the requirements > analysis identifies the need to allow clients to delegate > third-parties to query the ALTO service on their behalf, the > WG will ensure that the protocol provides a mechanism to > assert the consent of the delegating client. > > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different > level of knowledge about the underlying network, such > preferences may have different representations. Initially the > WG will consider: IP ranges to prefer and to avoid, ranked > lists of the peers requested by the client, information about > topological proximity and approximate geographic locations. The above seems okay. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > I think we should delete the sentence above. > - In order to query the ALTO server, clients must first know > one or more ALTO servers that might provide useful > information. The WG will look at service discovery > mechanisms that are in use, or defined elsewhere (e.g. > based on DNS SRV records or DHCP options). If such discovery > mechanisms can be reused, the WG will produce a document to > specify how they may be adopted for locating such servers. > However, a new, general-purpose service discovery mechanism > is not in scope. > > When the WG considers standardizing information that the ALTO > server could provide, the following criteria are important to > ensure real feasibility. > In the context of standardization, I don't think we should be trying to evaluate the importance of any information. The idea for us should be to standardize mechanisms to exchange peer selection related information. The value of the actual information exchanged is very contextual and not for general evaluation. > - Can the ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that a client will find useful? > - Can a client get that information without excessive privacy concerns > (e.g. by sending large lists of peers)? > - Is it information that a client cannot find easily some other way? > > After these criteria are met, the generality of the data will > be considered for prioritizing standardization work, for > example the number of operators and clients that are likely > to be able to provide or use that particular data. The above again gets into our evaluation of what is important based on what we know today and is limiting. >In any > case, this WG will not propose standards on how congestion is > signaled, remediated, or avoided, and will not deal with > information representing instantaneous network state. > Such issues belong to other IETF areas and will be treated > accordingly by the specific area. > > This WG will focus solely on the communication protocol > between applications and ALTO servers. s/applications and ALTO servers/ALTO endpoints >Note that ALTO > services may be useful in client-server environments as well > as P2P environments, although P2P environments are the first > focus. If, in the future, the IETF considers changes to > other protocols for actually implementing ALTO servers s/servers/services >(e.g. > application-layer protocols for Internet coordinate systems, > routing protocol extensions for ISP-based solutions), such > work will be done in strict coordination with the appropriate WGs. > > Issues related to the content exchanged in P2P systems are > also excluded from the WG's scope, as is the issue dealing > with enforcing the legality of the content. > > Goals and Milestones (very tentative dates): > > Apr 2009: Working Group Last Call for problem statement Jun > 2009: Submit problem statement to IESG as Informational Aug > 2009: Working Group Last Call for requirements document Oct > 2009: Submit requirements document to IESG as Informational > Jan 2010: Working Group Last Call for request/response > protocol Jan 2010: Working Group Last Call for usage document > for communicating network preferences Mar 2010: Submit > request/response protocol to IESG as Proposed Standard Mar > 2010: Submit usage document to IESG as Proposed Standard May > 2010: Working Group Last Call of discovery mechanism Jul > 2010: Submit discovery mechanism to IESG as Proposed Standard > Aug 2010: Dissolve or re-charter > > Initial Drafts for Consideration > - draft-marocco-alto-problem-statement-02 -- > Application-Layer Traffic Optimization (ALTO) Problem Statement > - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization > (ALTO) Requirements > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 22 20:52:44 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D55E3A68A8; Wed, 22 Oct 2008 20:52:44 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CC53A68A8; Wed, 22 Oct 2008 20:52:42 -0700 (PDT) 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=[AWL=0.000, 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 Dt+0bPCvYpZi; Wed, 22 Oct 2008 20:52:42 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B82D43A6358; Wed, 22 Oct 2008 20:52:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A325F2C0008DF; Thu, 23 Oct 2008 05:53:59 +0200 (CEST) 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 d-7LOD+3QWlc; Thu, 23 Oct 2008 05:53:59 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 776F62C000359; Thu, 23 Oct 2008 05:53:34 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 05:53:30 +0200 Message-ID: <547F018265F92642B577B986577D671C3E049E@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [tsv-area] TANA proposed charter Thread-Index: Ack0WnLXii25mH7vQ/i0lZO4Fz16QAAX4m8g References: <48FEEFDB.6000801@tm.uka.de> From: "Rolf Winter" To: "Nicholas Weaver" , "Roland Bless" Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nicholas, I think in your Email below you are asking the right questions. That said, this is probably not about the charter any more but already doing the work (and this is very good as the new version of the charter looks fine - to me at least). Rolf > -----Original Message----- > From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On > Behalf Of Nicholas Weaver > Sent: Thursday, October 23, 2008 12:25 AM > To: Roland Bless > Cc: p2pi@ietf.org; tsv-area@ietf.org; tana@ietf.org; Nicholas Weaver > Subject: Re: [tana] [tsv-area] TANA proposed charter > > > On Oct 22, 2008, at 2:18 AM, Roland Bless wrote: > >> I would like if possible to decouple the 'less than best > effort', as > >> in diffserv, from the algorithm per se. > >> > >> Besides, there are ISPs that are worried about the effect that P2P > >> have on other applications when the link is saturated, but > otherwise > >> they do not care. P2P would be treated like best effort in > >> non-saturated situations (a more ECN type approach). > > > > Yes, and that's exactly where LE helps: an ISP can be sure that LE > > traffic will not harm other BE traffic at any time. In case of > > congestion BE traffic will preempt LE traffic. If the link is not > > saturated, LE will be treated like BE. > > This is also roughly how Comcast is implementing fairness on their > network: Any user identified as being above a threshold of > usage (averaged over ~15 minutes) is placed into a lower QoS > category. And as long as there is at least some capacity > headroom left over, the heavy users aren't starved out, the > light users don't notice, and the heavy users traffic just > negotiates between itself. > > > However, this brings up a question: > > Should a scavenger service be true LE, if the network does > not support QoS? In such a case, the service can't yield > instantly anyway, so the question is what is the equilibrium > it goes to relative to other flows. > > Should it actually yield completely to other TCP flows on the network? > > Or should it instead have some equilibrium position thats a > stated fraction of what a normal TCP flow would achieve under > the circumstances? > > > EG, a "Scavenger App" has N flows, on a congested link shared > with a significant number of normal TCP flows. > > Given x is the equilibrium transfer rate of a single TCP flow. > > If the scavenger app's flows were normal TCP, the equilibrium > point in congestion with others would be Nx > > Should the goal be to have the equilibrium value be X? (No > matter the # of peers, the app behaves like a single TCP flow > for equilibrium > purposes) > > Should the goal be to have the equilibrium be some fraction > of X? Zero? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 02:59:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9133B3A6959; Thu, 23 Oct 2008 02:59:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B9D3A6870; Thu, 23 Oct 2008 02:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 O9vSfqdD+pe0; Thu, 23 Oct 2008 02:59:25 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E77F73A6959; Thu, 23 Oct 2008 02:59:24 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 10:57:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 10:57:13 +0100 Message-ID: In-Reply-To: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] [tana] TANA proposed charter Thread-Index: Ack0Zb6SCDlyQ/JWR2e2GDvAyNAPZgAjrBRw References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> From: To: , , , X-OriginalArrivalTime: 23 Oct 2008 09:57:16.0932 (UTC) FILETIME=[BB369C40:01C934F5] Subject: Re: [p2pi] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is looking pretty good to me. Couple of minor changes inline... Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stanislav Shalunov > Sent: 22 October 2008 17:46 > To: p2pi@ietf.org; tana@ietf.org; tsv-area@ietf.org Area > Subject: Re: [p2pi] [tana] TANA proposed charter > > A refreshed working copy of the draft charter. I've attempted to > capture and reconcile the edits and clarify point (2). > > We'll need to change the name, but it's not yet reflected because a > new one hasn't been selected. > > -- Stas > > > > > Techniques for Advanced Networking Applications (TANA) WG > > Chair(s): > TBD > > Transport Area Director(s): > * Magnus Westerlund > * Lars Eggert > > Transport Area Advisor: > * Lars Eggert > > Mailing Lists: > > General Discussion: tana@ietf.org > To Subscribe: tana-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/tana/ > > Description of Working Group: > > The TANA WG is chartered to standardize a congestion control mechanism > that should saturate the bottleneck, maintain low delay, and yield to > standard TCP. > > Applications that transmit large amounts of data for a long time with > congestion-limited TCP, but without AQM, fill the buffer at the head > of the bottleneck link. With FIFO queue, this increases the delay > experienced by other applications. With buffer of one RTT, the delay > doubles. In some cases, the extra delay may be much larger. This is a > particularly acute and common case is when P2P applications upload > over thin home uplinks: delays in these cases can sometimes be of the > order of seconds. > " With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles." --> " With FIFO queues, this increases the delay experienced by other applications. With buffers of the order of one RTT, the delay doubles." > The IETF's standard end-to-end transport protocols have not been > designed to minimize the extra delay introduced by them into the > network. TCP, as a side effect of filling the buffer until it > experiences drop-tail loss, effectively maximizes the delay. While > this works well for applications that are not delay-sensitive, it > harms interactive applications that share the same bottleneck. VoIP > and games are particularly affected, but even web browsing may become > problematic. > > TANA is a transport-area WG that will focus on broadly applicable > techniques that allow large amounts of data to be consistently > transmitted without substantially affecting the delays experienced by > other users and applications. > > The WG will work on the following: > > (1) An experimental congestion control algorithm for less-than-best- > effort "background" transmissions, i.e., an algorithm that attempts to > scavenge otherwise idle bandwidth for its transmissions in a way that > minimizes interference with regular best-effort traffic. > > Desired features of such an algorithm are: > * saturate the bottleneck, > * eliminate long standing queues and thus keep delay low when no other > traffic is present, > * quickly yield to traffic sharing the same bottleneck queue that uses > standard TCP congestion control, > * add little to the queueing delays induced by TCP traffic, > * operate well in networks with FIFO queueing with drop-tail > discipline, > * where available, use explicit congestion notification (ECN), active > queue management (AQM), and/or end-to-end differentiated services > (DiffServ). > > Application of this algorithm to existing transport protocols (TCP, > SCTP, DCCP) is expected to occur in the working groups that maintain > those protocols. > > (2) A document that clarifies the current practices of application > design and reasons behind them and discusses the tradeoffs surrounding > the use of many concurrent TCP connections to one destination and/or > to different destinations. > > Applications routinely open multiple TCP connections. For example, > P2P applications maintain connections to a number of different peers > while web browsers perform concurrent downloads from the same web > server. Application designers pursue different goals when doing so: > P2P apps need to maintain a well-connected mesh in the swarm while web > browsers mainly use multiple connections to parallelize requests that > involve application latency on the web server side. The IETF > transport area community is concerned about this practice, because > standard Internet congestion control results in different transport > connections sharing bottleneck capacity. When an application uses > several non-rate-limited transport connections to transfer through a > bottleneck, it may obtain a larger fraction of the bottleneck than if > it had used fewer connections. Although capacity is the most commonly > considered bottleneck resource, middlebox state table entries are also > an important resource for an end system communication. Other resource > types may exist, and the guidelines are expected to comprehensively > discuss them. > It would be nice to add something about the fact that TCP strongly favours long-running flows over shorter flows and that this further exacerbates the problems of capacity sharing. Not sure if this should go here or in the first work item? > Applications use a variety of techniques to mitigate these concerns. > These techniques have not always been reviewed by the IETF and their > interaction with TCP dynamics is poorly understood. The WG will > document the known techniques, discussing the consequences and, where > appropriate, provide guidance to application designers. > > (3) The WG will discuss how to best take into account prior work in > the area. The outcome will be either incorporated into the document > specifying the experimental congestion control algorithm or into a > separate document summarizing prior work. > > > > Goals and Milestones > > TBD Submit "Multiple Transport Connections in Applications Design" to > the IESG for consideration as an Informational RFC > TBD Submit "Transport for Advanced Networking Applications (TANA)" to > the IESG for consideration as an Experimental RFC > > > Internet-Drafts > > Transport for Advanced Networking Applications (TANA) Problem Statement > http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem- > statement-01.txt > > No Requests for Comments > > -- > Stanislav Shalunov > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 04:29:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB028C1A6; Thu, 23 Oct 2008 04:29:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29373A67BD; Thu, 23 Oct 2008 04:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 BJyG6MR8LMWp; Thu, 23 Oct 2008 04:28:57 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9B55E3A6C01; Thu, 23 Oct 2008 04:28:57 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 11:41:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 11:41:21 +0100 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] [tsv-area] TANA proposed charter Thread-Index: Ackznfhh1ziBsxw7RTihMaxxO3ST5QAaBL7QADvvDXA= References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> From: To: , , X-OriginalArrivalTime: 23 Oct 2008 10:41:29.0614 (UTC) FILETIME=[E855C2E0:01C934FB] Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org LETBET doesn't seem to me quite right. It seems to imply the WG would only work on a very limited subset of work from its charter. Having said that I can't think off-hand of a name that does sum things up. Was playing round with NASTY (network-aware scavenger transport) but that has the same problem as the above. I would love to fit it to something like YIELD or GIVEWAY that sums up the idea in its acronym. Toby > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Ingemar Johansson S > Sent: 22 October 2008 06:49 > To: Ted Faber; Eddy, Wesley M. (GRC-RCN0)[VZ] > Cc: p2pi@ietf.org; tana@ietf.org; TSV Area > Subject: Re: [p2pi] [tsv-area] TANA proposed charter > > Hi > > Even though I understand that it is better to focus on the charter than > in the name I too beleieve that TANA does not say much. > > I believe that somewhere along the track and also in the charter the > term "less than best effort transmission" was/is mentioned > A possible name would then be > > LETBET (LEss Than Best Effort Transport) > > That said... there are a whole bunch of WG names out there that at > first > glance does not say anything about the group. > > The charter looks OK from my perspective. > > /Ingemar > > > -----Original Message----- > > From: tsv-area-bounces@ietf.org > > [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber > > Sent: den 21 oktober 2008 18:51 > > To: Eddy, Wesley M. (GRC-RCN0)[VZ] > > Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > > Subject: Re: [tsv-area] TANA proposed charter > > > > On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > > (GRC-RCN0)[VZ] wrote: > > > But if nobody else has a problem with the TANA name, I'll keep my > > > mouth shut so we don't waste time and energy. There are > > bigger fish to fry! > > > > It should change. > > > > I care about congestion control and nothing in the expansion > > of TANA indicated it was about congestion (to me). > > > > -- > > Ted Faber > > http://www.isi.edu/~faber PGP: > > http://www.isi.edu/~faber/pubkeys.asc > > Unexpected attachment on this mail? See > > http://www.isi.edu/~faber/FAQ.html#SIG > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 06:52:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE6A28C0CE; Thu, 23 Oct 2008 06:52:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA363A6AA9; Thu, 23 Oct 2008 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-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 jFNmK5Urpxas; Thu, 23 Oct 2008 06:52:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 747FF3A69C9; Thu, 23 Oct 2008 06:52:34 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 14:52:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 14:52:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: Ack1DpE+wfIDPfz/SuuHS5fsx+0rhAABtadw References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> From: To: X-OriginalArrivalTime: 23 Oct 2008 13:52:42.0847 (UTC) FILETIME=[9EEA2EF0:01C93516] Cc: p2pi@ietf.org, tana@ietf.org, tsv-area@ietf.org Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Yes, that seems a much better name. Also really memorable which helps. I think it can be traced back to Marshall Eubanks. As you say flow sounds a bit limiting and so does file. On the other hand it bears its meaning on its face so quibbles about what the FF stands for are probably just distractions... Toby > -----Original Message----- > From: Bryan Ford [mailto:baford@mpi-sws.org] > Sent: 23 October 2008 13:55 > To: Moncaster,T,Toby,CXR9 R > Cc: ingemar.s.johansson@ericsson.com; faber@ISI.EDU; > Wesley.M.Eddy@nasa.gov; tsv-area@ietf.org; tana@ietf.org; p2pi@ietf.org > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > On Oct 23, 2008, at 12:41 PM, > > wrote: > > LETBET doesn't seem to me quite right. It seems to imply the WG would > > only work on a very limited subset of work from its charter. > > > > Having said that I can't think off-hand of a name that does sum > things > > up. Was playing round with NASTY (network-aware scavenger transport) > > but > > that has the same problem as the above. I would love to fit it to > > something like YIELD or GIVEWAY that sums up the idea in its acronym. > > I personally liked the suggestion someone else made earlier of "BACK- > OFF" - meaning "Background Congestion Kontrol of File Flows" or > something like that, wasn't it...? (Maybe we could come up with an > alternate word for the second 'F' that doesn't make it sound so > narrowly scoped.) > > Bryan > > > > > > > Toby > > > >> -----Original Message----- > >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf > > Of > >> Ingemar Johansson S > >> Sent: 22 October 2008 06:49 > >> To: Ted Faber; Eddy, Wesley M. (GRC-RCN0)[VZ] > >> Cc: p2pi@ietf.org; tana@ietf.org; TSV Area > >> Subject: Re: [p2pi] [tsv-area] TANA proposed charter > >> > >> Hi > >> > >> Even though I understand that it is better to focus on the charter > > than > >> in the name I too beleieve that TANA does not say much. > >> > >> I believe that somewhere along the track and also in the charter the > >> term "less than best effort transmission" was/is mentioned > >> A possible name would then be > >> > >> LETBET (LEss Than Best Effort Transport) > >> > >> That said... there are a whole bunch of WG names out there that at > >> first > >> glance does not say anything about the group. > >> > >> The charter looks OK from my perspective. > >> > >> /Ingemar > >> > >>> -----Original Message----- > >>> From: tsv-area-bounces@ietf.org > >>> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber > >>> Sent: den 21 oktober 2008 18:51 > >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] > >>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > >>> Subject: Re: [tsv-area] TANA proposed charter > >>> > >>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > >>> (GRC-RCN0)[VZ] wrote: > >>>> But if nobody else has a problem with the TANA name, I'll keep my > >>>> mouth shut so we don't waste time and energy. There are > >>> bigger fish to fry! > >>> > >>> It should change. > >>> > >>> I care about congestion control and nothing in the expansion > >>> of TANA indicated it was about congestion (to me). > >>> > >>> -- > >>> Ted Faber > >>> http://www.isi.edu/~faber PGP: > >>> http://www.isi.edu/~faber/pubkeys.asc > >>> Unexpected attachment on this mail? See > >>> http://www.isi.edu/~faber/FAQ.html#SIG > >>> > >> _______________________________________________ > >> p2pi mailing list > >> p2pi@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > > tana mailing list > > tana@ietf.org > > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 08:14:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A055C3A6A30; Thu, 23 Oct 2008 08:14:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA6E3A68A8; Wed, 22 Oct 2008 20:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 wAu1COmyG9HG; Wed, 22 Oct 2008 20:48:22 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 0E05B3A6358; Wed, 22 Oct 2008 20:48:22 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m9N3maHB023055; Wed, 22 Oct 2008 20:48:36 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 17E7F35D00CC; Wed, 22 Oct 2008 23:47:40 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 62A87974404; Wed, 22 Oct 2008 23:48:29 -0400 (EDT) To: Nicholas Weaver From: Mark Allman In-Reply-To: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: I'm No Angel MIME-Version: 1.0 Date: Wed, 22 Oct 2008 23:48:29 -0400 Message-Id: <20081023034829.62A87974404@lawyers.icir.org> X-Mailman-Approved-At: Thu, 23 Oct 2008 08:14:16 -0700 Cc: TSV Area , tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [p2pi] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0229605546==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0229605546== Content-Type: multipart/signed; boundary="--------ma62477-1"; micalg=pgp-sha1; protocol="application/pgp-signature" ----------ma62477-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Or at least until you bribe the NAT box vendors to implement some > active queue management. That might in fact be something desirable from a user's point of view and so the bribe might not be too big. It's the general notion sketched in this paper: Dan Ardelean, Ethan Blanton, Maxim Martynov. Remote Active Queue Management. Proceedings of the ACM SIGMM NOSSDAV 2008. May 2008. http://www.cs.purdue.edu/homes/eblanton/publications/raqm.ps allman ----------ma62477-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkj/9A0ACgkQWyrrWs4yIs6aZACdFFO4UTU38qykcvpERUvKJQQU NucAn0TejtK59S5fiTgxjDY2TUX6FVzZ =eH84 -----END PGP SIGNATURE----- ----------ma62477-1-- --===============0229605546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0229605546==-- From p2pi-bounces@ietf.org Thu Oct 23 08:14:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43A33A6AB0; Thu, 23 Oct 2008 08:14:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D1E3A6C2F; Thu, 23 Oct 2008 05:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UsBPX9UO7Xl0; Thu, 23 Oct 2008 05:53:58 -0700 (PDT) Received: from hera.mpi-sb.mpg.de (hera.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 0C7113A6A3A; Thu, 23 Oct 2008 05:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Cc:Message-Id:From:To: In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version: Subject:Date:References; bh=yTW9tDA+ot0XF+PzeN/BAqob5e6Ziktq7IZi Dug8PYo=; b=yIgutO//YTYYuQ1qlDANTHwirdoj7eTwdFGlMur/3xpdZ2bAfwCm X+JyUNAhDJ6XCGbLtRB/qL56frZf6S0UHrJz2Ntz/jUJJvLWP2sB66XujZVq5znI b6IpKAUWfZYbrHUiFxWUZb3ZHN5qJAzWQCZ1sDOkXKQls5x77aPtUgs= Received: from tentacle.mpi-sb.mpg.de ([139.19.1.27]:34565) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1Kszi0-0003zz-FG; Thu, 23 Oct 2008 14:54:51 +0200 Received: from guest-12.mpi-sb.mpg.de ([139.19.64.12]:51007) by tentacle.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Kszhz-0008OB-O8; Thu, 23 Oct 2008 14:54:35 +0200 Message-Id: From: Bryan Ford To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 14:54:33 +0200 References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Thu, 23 Oct 2008 08:14:16 -0700 Cc: tana@ietf.org, faber@ISI.EDU, p2pi@ietf.org, ingemar.s.johansson@ericsson.com, tsv-area@ietf.org, Wesley.M.Eddy@nasa.gov Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 23, 2008, at 12:41 PM, wrote: > LETBET doesn't seem to me quite right. It seems to imply the WG would > only work on a very limited subset of work from its charter. > > Having said that I can't think off-hand of a name that does sum things > up. Was playing round with NASTY (network-aware scavenger transport) > but > that has the same problem as the above. I would love to fit it to > something like YIELD or GIVEWAY that sums up the idea in its acronym. I personally liked the suggestion someone else made earlier of "BACK- OFF" - meaning "Background Congestion Kontrol of File Flows" or something like that, wasn't it...? (Maybe we could come up with an alternate word for the second 'F' that doesn't make it sound so narrowly scoped.) Bryan > > > Toby > >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf > Of >> Ingemar Johansson S >> Sent: 22 October 2008 06:49 >> To: Ted Faber; Eddy, Wesley M. (GRC-RCN0)[VZ] >> Cc: p2pi@ietf.org; tana@ietf.org; TSV Area >> Subject: Re: [p2pi] [tsv-area] TANA proposed charter >> >> Hi >> >> Even though I understand that it is better to focus on the charter > than >> in the name I too beleieve that TANA does not say much. >> >> I believe that somewhere along the track and also in the charter the >> term "less than best effort transmission" was/is mentioned >> A possible name would then be >> >> LETBET (LEss Than Best Effort Transport) >> >> That said... there are a whole bunch of WG names out there that at >> first >> glance does not say anything about the group. >> >> The charter looks OK from my perspective. >> >> /Ingemar >> >>> -----Original Message----- >>> From: tsv-area-bounces@ietf.org >>> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber >>> Sent: den 21 oktober 2008 18:51 >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] >>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org >>> Subject: Re: [tsv-area] TANA proposed charter >>> >>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. >>> (GRC-RCN0)[VZ] wrote: >>>> But if nobody else has a problem with the TANA name, I'll keep my >>>> mouth shut so we don't waste time and energy. There are >>> bigger fish to fry! >>> >>> It should change. >>> >>> I care about congestion control and nothing in the expansion >>> of TANA indicated it was about congestion (to me). >>> >>> -- >>> Ted Faber >>> http://www.isi.edu/~faber PGP: >>> http://www.isi.edu/~faber/pubkeys.asc >>> Unexpected attachment on this mail? See >>> http://www.isi.edu/~faber/FAQ.html#SIG >>> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 08:14:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4F33A67A5; Thu, 23 Oct 2008 08:14:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D123A66B4; Thu, 23 Oct 2008 08:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QIJ-kQTsCS3y; Thu, 23 Oct 2008 08:01:00 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id EC2DB3A6AF0; Thu, 23 Oct 2008 08:00:29 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m9NF1ilm019279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2008 16:01:45 +0100 (BST) Message-ID: <490091D9.2050203@erg.abdn.ac.uk> Date: Thu, 23 Oct 2008 16:01:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: tana@ietf.org References: <1224662013.3728.44.camel@pc105-c703.uibk.ac.at> <547F018265F92642B577B986577D671C3E039F@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C3E039F@VENUS.office> X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Thu, 23 Oct 2008 08:14:24 -0700 Cc: tsv-area@ietf.org, tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org So, let me add a few things to this discussion, to make sure I understand what is being said. From what I saw at the BoF, there was strong consensus to proceed, and this still seems to be so. The charter seems close to what we need. I'd prefer a title for the second work item that reflects the purpose of the RFC-to-be (see note below on the name of the group). I'd expect more RFCs to follow later, if this WG develops work in this space. There were a few emails on using a DSCP for LBE service, and since I raised this at the BoF, I'd like to clarify a little of what I intended. I think the WG should look at the transport issues applied to the current Internet - In my opinion the work should not *require* router changes to enable ECN, implement new DS codepoints, etc. The work should stimulate a new type of transport that *should* in turn be able to use new mechanisms such as an LBE DS offering, or ECN-provided feedaback, Quick-Start, and a range of other mechanisms that may help in the future. I think this is what the proposed Charter says now... I think the name of the BoF was OK, but the name doesn't reflect the role being sketched by the Charter. The charter is very Congestion-Control orientated, and rightly so in my opinion. A name that better reflects that would be good. We've had various suggestions... and I guess we need to "pick" one, of those I have seen, the most promising ones seem to be: Scavenger Network Congestion Protocols Background Congestion Control (BACKCC) Background Congestion of File Flows (BACKOFF) - or similar. Minimizing Impact of Large Transfers (MILT) Congestion-Optimisation for Large Transfers (COLT) Transport for Impact Limited Large Transfers (TILT) Note: As I recall, an IETF WG can not have a hyphen or underscore in their name. Best wishes, Gorry _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 09:03:15 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF3B3A69CE; Thu, 23 Oct 2008 09:03:15 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654EC3A68D7; Thu, 23 Oct 2008 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5Cd1raAkpVhk; Thu, 23 Oct 2008 09:03:13 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 69FCD3A69CE; Thu, 23 Oct 2008 09:03:13 -0700 (PDT) Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 09:04:32 -0700 Received: from NA-EXMSG-C102.redmond.corp.microsoft.com ([157.54.110.48]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.54.46.187]) with mapi; Thu, 23 Oct 2008 09:04:32 -0700 From: Yu-Shun Wang To: "Narayanan, Vidya" , IESG IESG Date: Thu, 23 Oct 2008 09:04:30 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfA= Message-ID: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20081006203532.B1D673A68AF@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vidya, Comments inline. (I've only preserved the points I have comments on. Others are fine with me.) Thanks, yushun > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Narayanan, Vidya > Sent: Wednesday, October 22, 2008 5:51 PM > > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org > > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary > > Sent: Monday, October 06, 2008 1:36 PM <...> > > A significant part of the Internet traffic today is generated > > by peer-to-peer (P2P) applications used for file sharing, > > real-time communications, and live media streaming. P2P > > applications exchange large amounts of data, often uploading > > as much as downloading. In contrast to client/server > > architectures, P2P applications often have a selection of > > peers and must choose. > > Add: "Peer selection is also a problem that has many different > applications in p2p systems - e.g., identifying the best peer to > download content from, identifying the best super peer to contact in a > system, using the best relay for NAT traversal, identifying the best > next hop for a query based on several criteria (e.g., quality, > reputation, semantic expertise, etc.), etc." I actually think the proposed addition is somewhat redundant, and could easily lead into ratholes on what are the metrics for "best" and whether it is even possible to get the best. The current charter tries to avoid that by saying "better-than- random" selection gating mostly on getting better performance and lowering the costs (as two examples). Also, what's the "best" depends heavily on whom you ask. ISP's notions of "best" may not align with those of the end users. I am fine with the examples (targets for selections), but let's try to avoid the debates on "best" again. <...> > > yet applications have at best incomplete > > information about the topology of the network. > > s/incomplete information about the topology of the network/incomplete > information to help the selection, e.g., topology of the network. I'm neutral to this. I think the intention is to narrow the initial scope to avoid confusion w/ TANA. The charter does leave the door open to future re-chartering/work. <...> > > Other usages will be considered as extensions to the charter > > once the work for the initial services has been completed. > > I think we should delete the sentence above. While it may seem redundant, I don't see anything wrong with that. It just means we may have a narrow scope now, but we will think about new extensions once we are done. <...> > > When the WG considers standardizing information that the ALTO > > server could provide, the following criteria are important to > > ensure real feasibility. > > In the context of standardization, I don't think we should be trying to > evaluate the importance of any information. The idea for us should be > to standardize mechanisms to exchange peer selection related > information. The value of the actual information exchanged is very > contextual and not for general evaluation. I read the list below somewhat differently. These are not for relative importance of the information, but kind of a min bar for what we want to do. While some may need re-wording, the intent is fine, IMO. > > - Can the ALTO service technically provide that information? > > - Is the ALTO service willing to obtain and divulge that information? > > - Is it information that a client will find useful? > > - Can a client get that information without excessive privacy > > concerns(e.g. by sending large lists of peers)? > > - Is it information that a client cannot find easily some other way? > > > > After these criteria are met, the generality of the data will > > be considered for prioritizing standardization work, for > > example the number of operators and clients that are likely > > to be able to provide or use that particular data. > > The above again gets into our evaluation of what is important based on > what we know today and is limiting. This point does need some clarification and rewording. Thanks, yushun _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 11:23:38 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF53C28C0F9; Thu, 23 Oct 2008 11:23:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239E128C0EA; Thu, 23 Oct 2008 11:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.896 X-Spam-Level: X-Spam-Status: No, score=-104.896 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, 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 7kJwrswg7PE0; Thu, 23 Oct 2008 11:23:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A0B133A6ADA; Thu, 23 Oct 2008 11:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224786294; x=1256322294; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"toby.moncaster@bt.com"=20,=0D =0A=20=20=20=20=20=20=20=20"baford@mpi-sws.org"=0D=0A=09< baford@mpi-sws.org>|CC:=20"p2pi@ietf.org"=20,=20"tana@ietf.org"=20,=0D=0A=20=20=20 =20=20=20=20=20"tsv-area@ietf.org"=20 |Date:=20Thu,=2023=20Oct=202008=2011:24:49=20-0700 |Subject:=20RE:=20[tana]=20[p2pi]=20[tsv-area]=20TANA=20p roposed=20charter|Thread-Topic:=20[tana]=20[p2pi]=20[tsv- area]=20TANA=20proposed=20charter|Thread-Index:=20Ack1DpE +wfIDPfz/SuuHS5fsx+0rhAABtadwAAm7c8A=3D|Message-ID:=20|References:=20<20081021165051.GA64367@zod.isi.e du>=0D=0A=09<026F8EEDAD2C4342A993203088C1FC05088E47F0@ese almw109.eemea.ericsson.se>=0D=0A=09 =0D=0A=09=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5412"=3B=20a=3D"11327628"; bh=jaxz1W6xDpLAUn8mMho7V68XEXAa7vo32Qadu6bs8VY=; b=alkpScF7CVXSrZRH4hg+CZ44/oEpZ8aR2wqotxxah/l+ISMZ8nMiie2m FC8hmic+oUv7zQVoDh/rlfoxNkeV3TdDQMzuarZ5yUAgbFYWawL9OZx4E qF93xaM7Eb+lV6rM4PMWhZ6nC7SnE1Pjw4y789lFLCd5H+A8xJJYP9L/2 s=; X-IronPort-AV: E=McAfee;i="5300,2777,5412"; a="11327628" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2008 11:24:54 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9NIOrs0017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 11:24:54 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9NIOrij013017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Oct 2008 11:24:53 -0700 Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 11:24:52 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 11:24:52 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 23 Oct 2008 11:24:51 -0700 From: "Narayanan, Vidya" To: "toby.moncaster@bt.com" , "baford@mpi-sws.org" Date: Thu, 23 Oct 2008 11:24:49 -0700 Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter Thread-Index: Ack1DpE+wfIDPfz/SuuHS5fsx+0rhAABtadwAAm7c8A= Message-ID: References: <20081021165051.GA64367@zod.isi.edu> <026F8EEDAD2C4342A993203088C1FC05088E47F0@esealmw109.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tsv-area@ietf.org" , "tana@ietf.org" , "p2pi@ietf.org" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I do like BACKOFF as well. I think "File" captures what we are doing here quite well - it doesn't look like we are dealing with all kinds of large data - as I said in one of my earlier emails, video fits the large data bill, but, it doesn't look like we would consider that as part of this work. In fact, it would benefit to have the charter explicitly call out that this is meant for large data that can be modeled as file downloads or something to that effect. Vidya > -----Original Message----- > From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On > Behalf Of toby.moncaster@bt.com > Sent: Thursday, October 23, 2008 6:53 AM > To: baford@mpi-sws.org > Cc: p2pi@ietf.org; tana@ietf.org; tsv-area@ietf.org > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > Yes, that seems a much better name. Also really memorable > which helps. I think it can be traced back to Marshall > Eubanks. As you say flow sounds a bit limiting and so does > file. On the other hand it bears its meaning on its face so > quibbles about what the FF stands for are probably just > distractions... > > Toby > > > -----Original Message----- > > From: Bryan Ford [mailto:baford@mpi-sws.org] > > Sent: 23 October 2008 13:55 > > To: Moncaster,T,Toby,CXR9 R > > Cc: ingemar.s.johansson@ericsson.com; faber@ISI.EDU; > > Wesley.M.Eddy@nasa.gov; tsv-area@ietf.org; tana@ietf.org; > p2pi@ietf.org > > Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter > > > > On Oct 23, 2008, at 12:41 PM, > > wrote: > > > LETBET doesn't seem to me quite right. It seems to imply the WG > would > > > only work on a very limited subset of work from its charter. > > > > > > Having said that I can't think off-hand of a name that does sum > > things > > > up. Was playing round with NASTY (network-aware scavenger > transport) > > > but that has the same problem as the above. I would love > to fit it > > > to something like YIELD or GIVEWAY that sums up the idea in its > acronym. > > > > I personally liked the suggestion someone else made earlier > of "BACK- > > OFF" - meaning "Background Congestion Kontrol of File Flows" or > > something like that, wasn't it...? (Maybe we could come up with an > > alternate word for the second 'F' that doesn't make it sound so > > narrowly scoped.) > > > > Bryan > > > > > > > > > > > Toby > > > > > >> -----Original Message----- > > >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf > > > Of > > >> Ingemar Johansson S > > >> Sent: 22 October 2008 06:49 > > >> To: Ted Faber; Eddy, Wesley M. (GRC-RCN0)[VZ] > > >> Cc: p2pi@ietf.org; tana@ietf.org; TSV Area > > >> Subject: Re: [p2pi] [tsv-area] TANA proposed charter > > >> > > >> Hi > > >> > > >> Even though I understand that it is better to focus on > the charter > > > than > > >> in the name I too beleieve that TANA does not say much. > > >> > > >> I believe that somewhere along the track and also in the charter > the > > >> term "less than best effort transmission" was/is mentioned A > > >> possible name would then be > > >> > > >> LETBET (LEss Than Best Effort Transport) > > >> > > >> That said... there are a whole bunch of WG names out > there that at > > >> first glance does not say anything about the group. > > >> > > >> The charter looks OK from my perspective. > > >> > > >> /Ingemar > > >> > > >>> -----Original Message----- > > >>> From: tsv-area-bounces@ietf.org > > >>> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Ted Faber > > >>> Sent: den 21 oktober 2008 18:51 > > >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ] > > >>> Cc: TSV Area; tana@ietf.org; p2pi@ietf.org > > >>> Subject: Re: [tsv-area] TANA proposed charter > > >>> > > >>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. > > >>> (GRC-RCN0)[VZ] wrote: > > >>>> But if nobody else has a problem with the TANA name, > I'll keep my > > >>>> mouth shut so we don't waste time and energy. There are > > >>> bigger fish to fry! > > >>> > > >>> It should change. > > >>> > > >>> I care about congestion control and nothing in the expansion of > > >>> TANA indicated it was about congestion (to me). > > >>> > > >>> -- > > >>> Ted Faber > > >>> http://www.isi.edu/~faber PGP: > > >>> http://www.isi.edu/~faber/pubkeys.asc > > >>> Unexpected attachment on this mail? See > > >>> http://www.isi.edu/~faber/FAQ.html#SIG > > >>> > > >> _______________________________________________ > > >> p2pi mailing list > > >> p2pi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ > > > tana mailing list > > > tana@ietf.org > > > https://www.ietf.org/mailman/listinfo/tana > > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 12:31:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDC33A685C; Thu, 23 Oct 2008 12:31:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665AA3A685C for ; Thu, 23 Oct 2008 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_62=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 rvr5pjoXsvVF for ; Thu, 23 Oct 2008 12:31:47 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 14F893A67D6 for ; Thu, 23 Oct 2008 12:31:46 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52267689; Thu, 23 Oct 2008 15:32:42 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 15:32:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 15:32:41 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60289634A@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: AckzwVP5lOp2SgLzQqWiqkmcA8Lx6wBhMlt/ From: "Woundy, Richard" To: X-OriginalArrivalTime: 23 Oct 2008 19:32:42.0498 (UTC) FILETIME=[1E0DE620:01C93546] Cc: p2pi@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org PlRoZSBxdWVzdGlvbiBpcyB0aGUgc2ltcGxlciBjb29yZGluYXRlOiAid2hvJ3MgTVkgcmVzb2x2 ZXIgYW5kIHdobyBlbHNlIHVzZXMgaXQiLg0KDQpUaGlzIGlzIGFuIGludGVyZXN0aW5nIGlkZWEu DQoNCk9uZSBwZXJoYXBzIG9idmlvdXMgdGhvdWdodC4gSSB3b3VsZG4ndCB1c2UgdGhlIElQIGFk ZHJlc3MgYXMgdGhlIHNvbGUgaWRlbnRpZmllciBvZiB0aGUgRE5TIHJlc29sdmVyLiBMb3RzIG9m IGhvc3RzIG9uIGRpZmZlcmVudCBuZXR3b3JrcyBhcmUgbGlrZWx5IHRvIHVzZSAxOTIuMTY4Lngu MSBhcyB0aGVpciBETlMgcmVzb2x2ZXIsIGVnIHRoZWlyIGhvbWUgZ2F0ZXdheS4gOikNCg0KLS0g UmljaA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHAycGktYm91bmNl c0BpZXRmLm9yZyA8cDJwaS1ib3VuY2VzQGlldGYub3JnPg0KVG86IFZpamF5IEsuIEd1cmJhbmkg PHZrZ0BhbGNhdGVsLWx1Y2VudC5jb20+DQpDYzogcDJwaUBpZXRmLm9yZyA8cDJwaUBpZXRmLm9y Zz47IE5pY2hvbGFzIFdlYXZlciA8bndlYXZlckBJQ1NJLkJlcmtlbGV5LkVEVT4NClNlbnQ6IFR1 ZSBPY3QgMjEgMTc6MDk6MDcgMjAwOA0KU3ViamVjdDogUmU6IFtwMnBpXSBXRyBSZXZpZXc6IEFw cGxpY2F0aW9uLUxheWVyIFRyYWZmaWMgT3B0aW1pemF0aW9uIChhbHRvKQ0KDQpPbm8gaXMgbGV2 ZXJhZ2luZyBvZmYgQWthbWFpJ3MgRE5TIGluZm9ybWF0aW9uOiAgWW91IGRvIGEgZmV3IHF1ZXJp ZXMgIA0KdG8gYWthbWFpJ2VkIChhbmQgb3RoZXIgQ0ROJ2VkKSBkb21haW5zLCBhbmQgdXNlIHRo ZSByZXN1bHRzIGFzIGEgIA0KY29vcmRpbmF0ZSBzcGFjZS4NCg0KVGhlIHF1ZXN0aW9uIGlzIHRo ZSBzaW1wbGVyIGNvb3JkaW5hdGU6ICJ3aG8ncyBNWSByZXNvbHZlciBhbmQgd2hvICANCmVsc2Ug dXNlcyBpdCIuDQoNCg0KDQpPbiBPY3QgMjEsIDIwMDgsIGF0IDI6MDUgUE0sIFZpamF5IEsuIEd1 cmJhbmkgd3JvdGU6DQoNCj4gTmljaG9sYXMgV2VhdmVyIHdyb3RlOg0KPj4gSGV5LCBzdHVwaWQg dGhvdWdodC4uLg0KPj4gQ291bGQgeW91IGRvIHByb3hpbWl0eSBiYXNlZCBvbiAid2hvJ3MgeW91 ciBETlMgcmVzb2x2ZXIiPyAgRG8gYSAgDQo+PiBmZXcgbmFtZSBsb29rdXBzOiBvbmUgdG8gcmVn aXN0ZXIgWU9VIGFzIHVzaW5nIFlPVVIgRE5TIHJlc29sdmVyIHRvICANCj4+IHRoZSByZW1vdGUg Y29vcmRpbmF0b3IsIGFuZCBvbmUgdG8gZ2V0ICJ3aG8gYXJlIG90aGVyIHBlZXJzIHVzaW5nICAN Cj4+IHRoZSBzYW1lIHJlc29sdmVyIj8NCj4+IEFuIHVnbHksIFVHTFkgaGFjaywgYnV0IGl0IG1p Z2h0IGJlIGludGVyZXN0aW5nIHRvIHRoaW5rIGFib3V0Lg0KPj4gSGFzIGFueW9uZSBkb25lIHRo aXMgYWxyZWFkeT8NCj4NCj4gRG9lc24ndCBPbm8gWzFdIGRvIHRoYXQ/ICBPciBhbSBJIG1pc3Np bmcgc29tZXRoaW5nPyAgQ0ROcyBhbHNvDQo+IHVzZSBETlMgcmVkaXJlY3RzIHRvIHJlZGlyZWN0 IGNsaWVudHMgdG8gbmVhcmVzdCBzZXJ2ZXJzLg0KPg0KPiBbMV0gRGF2aWQgUi4gQ2hvZmZuZXMg YW5kIEZhYmnDoW4gRS4gQnVzdGFtYW50ZS4gVGFtaW5nIHRoZSBUb3JyZW50Og0KPiAgICBBIHBy YWN0aWNhbCBhcHByb2FjaCB0byByZWR1Y2luZyBjcm9zcy1JU1AgdHJhZmZpYyBpbiBQMlANCj4g ICAgc3lzdGVtcywgUHJvYy4gb2YgQUNNIFNJR0NPTU0gMjAwOCwgQXVndXN0IDIwMDguDQo+DQo+ IFRoYW5rcywNCj4NCj4gLSB2aWpheQ0KPiAtLSANCj4gVmlqYXkgSy4gR3VyYmFuaSwgQmVsbCBM YWJvcmF0b3JpZXMsIEFsY2F0ZWwtTHVjZW50DQo+IDE5NjAgTHVjZW50IExhbmUsIFJtLiA5Qy01 MzMsIE5hcGVydmlsbGUsIElsbGlub2lzIDYwNTY2IChVU0EpDQo+IEVtYWlsOiB2a2dAe2FsY2F0 ZWwtbHVjZW50LmNvbSxiZWxsLWxhYnMuY29tLGFjbS5vcmd9DQo+IFdXVzogICBodHRwOi8vd3d3 LmFsY2F0ZWwtbHVjZW50LmNvbS9iZWxsLWxhYnMNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gcDJwaSBtYWlsaW5nIGxpc3QNCj4gcDJwaUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycGkNCj4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnAycGkgbWFp bGluZyBsaXN0DQpwMnBpQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycGkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCnAycGkgbWFpbGluZyBsaXN0CnAycGlAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wMnBpCg== From p2pi-bounces@ietf.org Thu Oct 23 12:43:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8EA3A6C41; Thu, 23 Oct 2008 12:43:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FB83A6AAD for ; Thu, 23 Oct 2008 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, 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 srz0TkR5K8nj for ; Thu, 23 Oct 2008 12:42:58 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id D26223A6CAE for ; Thu, 23 Oct 2008 12:41:56 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9NJh54n007294; Thu, 23 Oct 2008 12:43:05 -0700 (PDT) Message-Id: <44E22385-AB0D-4CEB-B6F2-A86FE551FEE6@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "Woundy, Richard" In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60289634A@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 12:43:04 -0700 References: <74CCBBDF76102846AFA7B29F3A98D3F60289634A@PACDCEXCMB06.cable.comcast.com> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 23, 2008, at 12:32 PM, Woundy, Richard wrote: >> The question is the simpler coordinate: "who's MY resolver and who >> else uses it". > > This is an interesting idea. > > One perhaps obvious thought. I wouldn't use the IP address as the > sole identifier of the DNS resolver. Lots of hosts on different > networks are likely to use 192.168.x.1 as their DNS resolver, eg > their home gateway. :) Well, you use the last-hop resolver, by looking at the address from the authoritative server side, not from the client side. eg, query server.nettest.icir.org The answer is the recursive resolver which contacted our DNS server. (well, when our experimental server is running that is) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 13:24:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF053A6A2C; Thu, 23 Oct 2008 13:24:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667FB3A6A2C for ; Thu, 23 Oct 2008 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=0.227, 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 aFKyxI15AhmT for ; Thu, 23 Oct 2008 13:24:19 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 80BD93A6AA7 for ; Thu, 23 Oct 2008 13:24:16 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52271889; Thu, 23 Oct 2008 16:25:22 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 16:25:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 16:25:21 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60289634D@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ack1R6El0f3m8U4ySr+s0TwVv1oqFwABdfRO From: "Woundy, Richard" To: X-OriginalArrivalTime: 23 Oct 2008 20:25:22.0314 (UTC) FILETIME=[79738EA0:01C9354D] Cc: p2pi@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >Well, you use the last-hop resolver That makes more sense. :) In our network, we have a number of clusters of caching DNS servers. Two customer computers in the same geography may happen to use different caching servers in the same cluster. Two computers in different geographies may use different caching clusters. -- Rich ----- Original Message ----- From: Nicholas Weaver To: Woundy, Richard Cc: Nicholas Weaver ; p2pi@ietf.org Sent: Thu Oct 23 15:43:04 2008 Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On Oct 23, 2008, at 12:32 PM, Woundy, Richard wrote: >> The question is the simpler coordinate: "who's MY resolver and who >> else uses it". > > This is an interesting idea. > > One perhaps obvious thought. I wouldn't use the IP address as the > sole identifier of the DNS resolver. Lots of hosts on different > networks are likely to use 192.168.x.1 as their DNS resolver, eg > their home gateway. :) Well, you use the last-hop resolver, by looking at the address from the authoritative server side, not from the client side. eg, query server.nettest.icir.org The answer is the recursive resolver which contacted our DNS server. (well, when our experimental server is running that is) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 18:46:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81853A6AF4; Thu, 23 Oct 2008 18:46:33 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435383A6AC5; Thu, 23 Oct 2008 18:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.293 X-Spam-Level: X-Spam-Status: No, score=-105.293 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 qiv3ye3u3K4v; Thu, 23 Oct 2008 18:46:31 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1A56B3A67A3; Thu, 23 Oct 2008 18:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1224812871; x=1256348871; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Yu-Shun=20Wang=20,=20IESG =20IESG=20|CC:=20"p2pi@ietf.org"=20,=20"ietf@ietf.org"=20|Date:=20Thu ,=2023=20Oct=202008=2018:47:43=20-0700|Subject:=20RE:=20[ p2pi]=20WG=20Review:=20Application-Layer=20Traffic=20Opti mization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review: =20Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFf NfAAFNViIA=3D=3D|Message-ID:=20|References: =20<20081006203532.B1D673A68AF@core3.amsl.com>=0D=0A=20=0D=0A=20<43AEA9A9F7768B42A89F554F0EBF7ED82D17 8EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> |In-Reply-To:=20<43AEA9A9F7768B42A89F554F0EBF7ED82D178EC4 46@NA-EXMSG-C102.redmond.corp.microsoft.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5413"=3B=20a=3D"11347675"; bh=F9Pfl0YYEc6u5SzeqBug4xk1Qxrzb6aSKdjw3wyqPTM=; b=SAIa2abhK9zOdFG9pRMCCqdZF6x6zWvI+PM2LP50l+BhjYLEjH/uo9Ah sNoLS48uQnoRht5ZSfaVB6O9E0QsApvAWKtodOugKTv9ymcb2ZFY9Wh9w lk3M4mmD5WHTPAUjh72q+QfPhEH8xN38yQLSQEblGo6jznFIQmy9OfLdq o=; X-IronPort-AV: E=McAfee;i="5300,2777,5413"; a="11347675" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2008 18:47:50 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9O1loL7015868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 18:47:50 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9O1looB011779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Oct 2008 18:47:50 -0700 Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 18:47:49 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 18:47:49 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 23 Oct 2008 18:47:49 -0700 From: "Narayanan, Vidya" To: Yu-Shun Wang , IESG IESG Date: Thu, 23 Oct 2008 18:47:43 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfAAFNViIA== Message-ID: References: <20081006203532.B1D673A68AF@core3.amsl.com> <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> In-Reply-To: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Yushun, > > > > Add: "Peer selection is also a problem that has many different > > applications in p2p systems - e.g., identifying the best peer to > > download content from, identifying the best super peer to > contact in a > > system, using the best relay for NAT traversal, identifying > the best > > next hop for a query based on several criteria (e.g., quality, > > reputation, semantic expertise, etc.), etc." > > I actually think the proposed addition is somewhat redundant, > and could easily lead into ratholes on what are the metrics > for "best" and whether it is even possible to get the best. > The current charter tries to avoid that by saying > "better-than- random" selection gating mostly on getting > better performance and lowering the costs (as two examples). > Also, what's the "best" depends heavily on whom you ask. > ISP's notions of "best" > may not align with those of the end users. > > I am fine with the examples (targets for selections), but > let's try to avoid the debates on "best" again. > I'm fine with that. I agree that "best" is a relative word and causes confusion at best :) > > > > Other usages will be considered as extensions to the charter once > > > the work for the initial services has been completed. > > > > I think we should delete the sentence above. > > While it may seem redundant, I don't see anything wrong with > that. It just means we may have a narrow scope now, but we > will think about new extensions once we are done. > I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG. > > I read the list below somewhat differently. These are not for > relative importance of the information, but kind of a min bar > for what we want to do. While some may need re-wording, the > intent is fine, IMO. > I'm not so sure. Basically, it is a question of what usage these are evaluated based on. Let's take a couple of examples. Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset. But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information. Similarly, whether some information is useful to a client is totally contextual to the application as well. > > > - Can the ALTO service technically provide that information? > > > - Is the ALTO service willing to obtain and divulge that > information? > > > - Is it information that a client will find useful? > > > - Can a client get that information without excessive privacy > > > concerns(e.g. by sending large lists of peers)? > > > - Is it information that a client cannot find easily some > other way? > > > > > > After these criteria are met, the generality of the data will be > > > considered for prioritizing standardization work, for example the > > > number of operators and clients that are likely to be able to > > > provide or use that particular data. > > > > The above again gets into our evaluation of what is > important based on > > what we know today and is limiting. > > This point does need some clarification and rewording. > > Thanks, > yushun > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Oct 23 19:05:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA75D3A6828; Thu, 23 Oct 2008 19:05:44 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052173A67CC for ; Thu, 23 Oct 2008 19:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SSQ4e1Nm38ta for ; Thu, 23 Oct 2008 19:05:43 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id BF8233A67DB for ; Thu, 23 Oct 2008 19:05:36 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so609881rvf.49 for ; Thu, 23 Oct 2008 19:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=7It5JzmMSgHMgMrZ1dSqI5pkmN3ZO1KEaUmAzg0vpek=; b=XvtaWyeKRz6nD3p9SOTJxgjhYTgy3yMpmipMDhNWKgMhe9/OzRmk9izhg9/dPWiYvl 0MzAHaDrftY5uMaH/4Pz6tXHzr8UftDgoPMpz3RKxVxC69Az4LdNOdWG+mCcLgEaZFcI E0A2R2mLdMZn4HLTa58So3KxtiCyEtfGwNKfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=h5evCCRXEw4vyL22+lwbNLezjFlW1tfmwHw1p+Evz9QGOxrJEMiSx/zuc6p3eR01IQ H09A+NXRGBPHuXWhT2GMzg26RXxMFKdRDQFHmYUMbMpzdCFU9QY3ErgtTMispwNCtONf 22s6By/E15W3cZji27qhbfLYabvd91MEg+ue4= Received: by 10.140.201.8 with SMTP id y8mr826370rvf.28.1224814016390; Thu, 23 Oct 2008 19:06:56 -0700 (PDT) Received: by 10.140.173.21 with HTTP; Thu, 23 Oct 2008 19:06:56 -0700 (PDT) Message-ID: Date: Thu, 23 Oct 2008 19:06:56 -0700 From: "Lisa Dusseault" To: "Marshall Eubanks" In-Reply-To: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> MIME-Version: 1.0 References: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> Cc: p2pi@ietf.org, CARLINET Yannick RD-CORE-LAN Subject: Re: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0213817430==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0213817430== Content-Type: multipart/alternative; boundary="----=_Part_39765_27905855.1224814016392" ------=_Part_39765_27905855.1224814016392 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I requested an ALTO meeting. As a matter of process, it's scheduled as a BOF, and may be changed to a WG meeting if ALTO becomes a WG by that point. Lisa On Wed, Oct 22, 2008 at 7:43 AM, Marshall Eubanks wrote: > > On Oct 22, 2008, at 8:34 AM, CARLINET Yannick RD-CORE-LAN wrote: > > Dear All, >> >> Is an alto meeting planned for the 73th ietf meeting ? If yes when will we >> know the date of this wg meeting ? >> > > The current agenda can be found here : > > https://datatracker.ietf.org/meeting/73/agenda.html > > I do not see an ALTO meeting on it. > > Please note that IETF meeting agendas are subject to change at any time. > > Regards > Marshall > > > >> >> Thank you very much in advance >> Best regards >> >> >> -- >> | Yannick CARLINET - Research engineer >> | Orange Labs (FT R&D) - CORE/M2I >> | 2 ave. Pierre Marzin, 22307 Lannion, France >> | phone +33 2.96.05.03.25 | fax +33 2.96.05.37.84 >> | yannick.carlinet@orange-ftgroup.com >> >> >> >> >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_39765_27905855.1224814016392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I requested an ALTO meeting.  As a matter of process, it's scheduled as a BOF, and may be changed to a WG meeting if ALTO becomes a WG by that point.

Lisa

On Wed, Oct 22, 2008 at 7:43 AM, Marshall Eubanks <tme@multicasttech.com> wrote:

On Oct 22, 2008, at 8:34 AM, CARLINET Yannick RD-CORE-LAN wrote:

Dear All,

Is an alto meeting planned for the 73th ietf meeting ? If yes when will we
know the date of this wg meeting ?

The current agenda can be found here :

https://datatracker.ietf.org/meeting/73/agenda.html

I do not see an ALTO meeting on it.

Please note that IETF meeting agendas are subject to change at any time.

Regards
Marshall




Thank you very much in advance
Best regards


--
| Yannick CARLINET - Research engineer
| Orange Labs (FT R&D) - CORE/M2I
| 2 ave. Pierre Marzin, 22307 Lannion, France
| phone +33 2.96.05.03.25 | fax +33 2.96.05.37.84
| yannick.carlinet@orange-ftgroup.com






_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

------=_Part_39765_27905855.1224814016392-- --===============0213817430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0213817430==-- From p2pi-bounces@ietf.org Fri Oct 24 07:22:10 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE7E28C1C2; Fri, 24 Oct 2008 07:22:10 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FC328C1AB; Fri, 24 Oct 2008 07:22:09 -0700 (PDT) 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=[AWL=0.000, 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 yWysuNkOGCRZ; Fri, 24 Oct 2008 07:22:08 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id E1E5C28C1B1; Fri, 24 Oct 2008 07:22:07 -0700 (PDT) Received: from [172.30.10.114] ([69.7.112.42]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9OENIj1049061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Oct 2008 17:23:21 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: p2pi@ietf.org, tana@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 08:23:13 -0600 References: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8483/Fri Oct 24 06:01:54 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Fri, 24 Oct 2008 17:23:27 +0300 (EEST) Subject: Re: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 2008-10-23, at 20:06, ext Lisa Dusseault wrote: > I requested an ALTO meeting. As a matter of process, it's scheduled > as a > BOF, and may be changed to a WG meeting if ALTO becomes a WG by that > point. I did the same for TANA (or whatever the acronym will be.) I don't think I've seen either meeting on the current agenda though. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 07:26:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CCF3A6A65; Fri, 24 Oct 2008 07:26:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB1B3A6A65; Fri, 24 Oct 2008 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, 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 Pnvlzzsfh3IJ; Fri, 24 Oct 2008 07:26:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CBBFB3A67A1; Fri, 24 Oct 2008 07:26:28 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9OERcuJ004936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Oct 2008 16:27:38 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9OERZRT008418; Fri, 24 Oct 2008 16:27:37 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 16:27:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 16:27:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] alto wg meeting in Minneapolis ? Thread-Index: Ack15Bu6qnBgjPGhQLyl9vpjquCQSQAAEZzQ References: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Lars Eggert" , , X-OriginalArrivalTime: 24 Oct 2008 14:27:34.0577 (UTC) FILETIME=[A8189A10:01C935E4] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081024162738-115FBBB0-0EB2F288/0-0/0-15 X-purgate-size: 879/0 Subject: Re: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org TANA is on the list of Proposed BOFs (not necessarily officially approved) for IETF 73 (Minneapolis), ALTO is not Christian -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of ext Lars Eggert Sent: Friday, October 24, 2008 4:23 PM To: p2pi@ietf.org; tana@ietf.org Subject: Re: [p2pi] alto wg meeting in Minneapolis ? On 2008-10-23, at 20:06, ext Lisa Dusseault wrote: > I requested an ALTO meeting. As a matter of process, it's scheduled > as a > BOF, and may be changed to a WG meeting if ALTO becomes a WG by that > point. I did the same for TANA (or whatever the acronym will be.) I don't think I've seen either meeting on the current agenda though. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 07:50:58 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50AC28C0F1; Fri, 24 Oct 2008 07:50:58 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368673A6B15; Fri, 24 Oct 2008 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 aVQsjgW2MQLD; Fri, 24 Oct 2008 07:50:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 312DE28C0F1; Fri, 24 Oct 2008 07:50:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6661E33C43; Fri, 24 Oct 2008 10:52:18 -0400 (EDT) Date: Fri, 24 Oct 2008 10:52:18 -0400 From: John Leslie To: Stanislav Shalunov Message-ID: <20081024145218.GB88592@verdi> References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> User-Agent: Mutt/1.4.1i Cc: tana@ietf.org, p2pi@ietf.org Subject: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stanislav Shalunov wrote: > > A refreshed working copy of the draft charter... > > The TANA WG is chartered to standardize a congestion control mechanism > that should saturate the bottleneck, maintain low delay, and yield to > standard TCP. Nicely stated! However, I wonder how many of us are on the same page when it comes to the question of packet marking. Some of us quite clearly see this as a question of _how_ to use DiffServ; others of us see this as how to _avoid_ DiffServ. That is not necessarily a problem... > TANA is a transport-area WG that will focus on broadly applicable > techniques that allow large amounts of data to be consistently > transmitted without substantially affecting the delays experienced by > other users and applications. By the nature of a packet-forwarding internet, there will be delays due to queues filling. Thus marking packets as eligible for dropping as queues fill is a fundamental tool for controlling delay. In the particular cases that are driving this work, a majority of end-systems involved will have uplink bandwidth configured to be less than downlink bandwidth. Thus, uplink queues may tend to fill first; and packet marking for the benefit of the first uplink router would have an obvious payback... > The WG will work on the following: > > (1) An experimental congestion control algorithm for less-than-best- > effort "background" transmissions, i.e., an algorithm that attempts to > scavenge otherwise idle bandwidth for its transmissions in a way that > minimizes interference with regular best-effort traffic. This language calls for something other than DiffServ, which is fine by me -- DiffServ will not always be available. > Desired features of such an algorithm are: > * saturate the bottleneck, > * eliminate long standing queues and thus keep delay low when no other > traffic is present, > * quickly yield to traffic sharing the same bottleneck queue that uses > standard TCP congestion control, > * add little to the queueing delays induced by TCP traffic, > * operate well in networks with FIFO queueing with drop-tail discipline, > * where available, use explicit congestion notification (ECN), active > queue management (AQM), and/or end-to-end differentiated services > (DiffServ). ... which raises the question of _how_ to determine which of these (ECN, AQM, DiffServ) are available... It occurs to me that for the uplink, the ISP will tend to have the best information on which are available _and_ if several are available, which would serve best. Thus, having the ISP provide such information is something I wouldn't want to rule out. IMHO, the proposed charter is silent on that question, which is OK... But, this work is closely allied to the work in ALTO, which could in principle collect such information and pass it (unevaluated) to the p2p application. It's not instantly obvious whether the TANA and ALTO charters allow for this, and I'd be happier if that were obvious enough to prevent arguments after the WGs are formed. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 08:07:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F167028C12E; Fri, 24 Oct 2008 08:07:54 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9324C28C12E; Fri, 24 Oct 2008 08:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, 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 LvQbn1Ctd3kP; Fri, 24 Oct 2008 08:07:52 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3CD563A6881; Fri, 24 Oct 2008 08:07:52 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9OF9AEZ020053; Fri, 24 Oct 2008 08:09:11 -0700 (PDT) Message-Id: From: Nicholas Weaver To: John Leslie In-Reply-To: <20081024145218.GB88592@verdi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 08:09:10 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, tana@ietf.org, Nicholas Weaver Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 24, 2008, at 7:52 AM, John Leslie wrote: > > By the nature of a packet-forwarding internet, there will be delays > due to queues filling. Thus marking packets as eligible for dropping > as queues fill is a fundamental tool for controlling delay. > > In the particular cases that are driving this work, a majority of > end-systems involved will have uplink bandwidth configured to be less > than downlink bandwidth. Thus, uplink queues may tend to fill first; > and packet marking for the benefit of the first uplink router would > have an obvious payback... However, much of the problem arrises from the first uplink router, the one in the home, being horribly, HORRIBLY engineered. A simple test: A Linksys WRT64GL with the Linksys default firmware is my access router, connected to a generic DSL modem. I have a sustained ping to a remote system at ICSI, 30ms away. I start a full rate, SINGLE TCP flow to this remote system. The ping time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem (not sure which at this moment) has a 3 second packet buffer, and simple FIFO behavior. Any full rate upload and I can kiss my connection goodbye. Period. End of story. Have a nice day. Remember, there are two problems that a scavenger class service must accommodate: the criminally overbuffered home access devices and common congestion in the ISP's uplink. Packet marking may work great for the ISP's uplink, but I feel we must consider the access link devices to be stupid: Overbuffered, and with no support for any advanced queuing operation, ECN, DiffServe, or anything else, thus any scavenger class protocol can't rely on support for advanced traffic management features. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 09:11:52 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFA43A6AE9; Fri, 24 Oct 2008 09:11:52 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2721D28C1D9; Fri, 24 Oct 2008 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 0DflQngOPp0y; Fri, 24 Oct 2008 09:11:50 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 2CF743A69B9; Fri, 24 Oct 2008 09:11:50 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E2AFB33C41; Fri, 24 Oct 2008 12:12:46 -0400 (EDT) Date: Fri, 24 Oct 2008 12:12:46 -0400 From: John Leslie To: Nicholas Weaver Message-ID: <20081024161246.GD88592@verdi> References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nicholas Weaver wrote: > On Oct 24, 2008, at 7:52 AM, John Leslie wrote: >> >> By the nature of a packet-forwarding internet, there will be delays >> due to queues filling. Thus marking packets as eligible for dropping >> as queues fill is a fundamental tool for controlling delay. >> >> In the particular cases that are driving this work, a majority of >> end-systems involved will have uplink bandwidth configured to be less >> than downlink bandwidth. Thus, uplink queues may tend to fill first; >> and packet marking for the benefit of the first uplink router would >> have an obvious payback... > > However, much of the problem arrises from the first uplink router, the > one in the home, being horribly, HORRIBLY engineered. I agree, there are some horrible examples. > A simple test: A Linksys WRT64GL with the Linksys default firmware is > my access router, connected to a generic DSL modem. > > I have a sustained ping to a remote system at ICSI, 30ms away. > > I start a full rate, SINGLE TCP flow to this remote system. The ping > time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem (not > sure which at this moment) has a 3 second packet buffer, and simple > FIFO behavior. Any full rate upload and I can kiss my connection > goodbye. Period. End of story. Have a nice day. Fortunately, the Linksys _could_ be easily programmed to fix that -- and if the problem becomes obvious enough to enough buyers, the competition will fix it... > Remember, there are two problems that a scavenger class service must > accommodate: the criminally overbuffered home access devices and > common congestion in the ISP's uplink. Agreed. (And there are a number of different flavors of congestion in the uplink.) > Packet marking may work great for the ISP's uplink, but I feel we must > consider the access link devices to be stupid: Overbuffered, and with > no support for any advanced queuing operation, ECN, DiffServe, or > anything else, thus any scavenger class protocol can't rely on support > for advanced traffic management features. Agreed, we can't rely on it. But we shouldn't rule out optimizing the happy case where there's full support for one or more of these through to the actual bandwidth bottleneck. It's not actually all that hard to get there, for clueful users... -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:19:04 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0BE3A6BED; Fri, 24 Oct 2008 10:19:04 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4333D28C1C4; Fri, 24 Oct 2008 10:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.048, 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 kojgRaKqJaA0; Fri, 24 Oct 2008 10:19:02 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1581E28C150; Fri, 24 Oct 2008 10:19:01 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.17547146; Fri, 24 Oct 2008 13:19:54 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 13:19:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 13:19:53 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E6F9@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] alto wg meeting in Minneapolis ? Thread-Index: Ack15Bu6qnBgjPGhQLyl9vpjquCQSQAAEZzQAAYTrRA= References: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> From: "Livingood, Jason" To: "Schmidt, Christian 1. \(NSN - DE/Munich\)" , "ext Lars Eggert" , , X-OriginalArrivalTime: 24 Oct 2008 17:19:54.0377 (UTC) FILETIME=[BB18DF90:01C935FC] Subject: Re: [p2pi] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org How do we get ALTO on the list of proposed BoFs as well? Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Schmidt, Christian 1. (NSN - DE/Munich) > Sent: Friday, October 24, 2008 10:28 AM > To: ext Lars Eggert; p2pi@ietf.org; tana@ietf.org > Subject: Re: [p2pi] alto wg meeting in Minneapolis ? > > TANA is on the list of Proposed BOFs (not necessarily officially > approved) > for IETF 73 (Minneapolis), > ALTO is not > > Christian > > > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of ext Lars Eggert > Sent: Friday, October 24, 2008 4:23 PM > To: p2pi@ietf.org; tana@ietf.org > Subject: Re: [p2pi] alto wg meeting in Minneapolis ? > > On 2008-10-23, at 20:06, ext Lisa Dusseault wrote: > > I requested an ALTO meeting. As a matter of process, it's > scheduled > > as a BOF, and may be changed to a WG meeting if ALTO > becomes a WG by > > that point. > > I did the same for TANA (or whatever the acronym will be.) > > I don't think I've seen either meeting on the current agenda though. > > Lars > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:24:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48013A6BFD; Fri, 24 Oct 2008 10:24:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A143A6BFB; Fri, 24 Oct 2008 10:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, 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 aEFvZSNsQKZX; Fri, 24 Oct 2008 10:23:59 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id ADE153A6BD4; Fri, 24 Oct 2008 10:23:59 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9OHOnTd008358; Fri, 24 Oct 2008 10:25:14 -0700 (PDT) Message-Id: <13265179-F62E-480F-B233-0F6160EC5701@ICSI.Berkeley.EDU> From: Nicholas Weaver To: John Leslie In-Reply-To: <20081024161246.GD88592@verdi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 10:24:49 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> <20081024161246.GD88592@verdi> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, tana@ietf.org, Nicholas Weaver Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 24, 2008, at 9:12 AM, John Leslie wrote: >> >> >> I start a full rate, SINGLE TCP flow to this remote system. The ping >> time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem >> (not >> sure which at this moment) has a 3 second packet buffer, and simple >> FIFO behavior. Any full rate upload and I can kiss my connection >> goodbye. Period. End of story. Have a nice day. > > Fortunately, the Linksys _could_ be easily programmed to fix that -- > and if the problem becomes obvious enough to enough buyers, the > competition will fix it... I disagree. I've had DSL or cable modem connectivity for damn-near a decade now. And fixing it is easy: the data rates are trivial, the devices are often programmable, and the solution straightforward: just have only 30ms of packet buffer, not 3s. Yet these devices STILL have this problem. And the only reason that as a clued user it would be fixable if its the Linksys box is I DELIBERATELY purchased the version where I can replace the firmware to fix something the vendors refused to fix for themselves. And I just unplugged the linksys: its the DSL modem, purchased within the past 2.5 years. (The reason its not a problem for me is I don't use P2P apps, and only rarely upload large quantities of photos) So I think the conclusion should be there has been a market failure in this area, and that absent a miracle, this problem will remain. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:25:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433F128C1C4; Fri, 24 Oct 2008 10:25:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7AD3A6BE4; Fri, 24 Oct 2008 10:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_20=-0.74, 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 3OmpKGZr21zI; Fri, 24 Oct 2008 10:24:59 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1CF1D28C210; Fri, 24 Oct 2008 10:24:59 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.17548030; Fri, 24 Oct 2008 13:25:51 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 13:25:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 13:25:49 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E6FA@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: p2pi@ vs. tana@ / alto@ (decomm p2pi@?) Thread-Index: Ack1/Y4yiSLvN0WBRzeqo8DIyQ/nXA== From: "Livingood, Jason" To: , , X-OriginalArrivalTime: 24 Oct 2008 17:25:50.0884 (UTC) FILETIME=[8F978640:01C935FD] Subject: [p2pi] p2pi@ vs. tana@ / alto@ (decomm p2pi@?) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Seems like there is a lot of cross-posting, and that at least tana@ and alto@ lists are more targeted now. Is it time to deactivate the p2pi@ mailing list? Jason _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:30:47 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D87B28C140; Fri, 24 Oct 2008 10:30:47 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0B73A687D; Fri, 24 Oct 2008 10:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 ejUtEC55Yu6n; Fri, 24 Oct 2008 10:30:44 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 214A63A677C; Fri, 24 Oct 2008 10:30:43 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52310099; Fri, 24 Oct 2008 13:31:40 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 13:31:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 13:31:38 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E6FC@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] TANA proposed charter Thread-Index: Ackzf5FRx3f7mfXFQXKVESwVjHyNUACfpUiw References: From: "Livingood, Jason" To: "Stanislav Shalunov" , , , "TSV Area" X-OriginalArrivalTime: 24 Oct 2008 17:31:40.0152 (UTC) FILETIME=[5FC59780:01C935FE] Subject: Re: [p2pi] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0429858220==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0429858220== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C935FE.5F0C7D29" This is a multi-part message in MIME format. ------_=_NextPart_001_01C935FE.5F0C7D29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good charter so far. Agree that we need a better name. I intend to participate as a document author, document contributor, and a reviewer. =20 Jason ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Stanislav Shalunov Sent: Tuesday, October 21, 2008 9:17 AM To: tana@ietf.org; p2pi@ietf.org; TSV Area Subject: [p2pi] TANA proposed charter =09 =09 At the BoF in Dublin, we observed strong interest and consensus that the TANA work should go forward as a working group. Does the following proposed charter, based on the BoF description, capture what the community was interested in? Thanks, -- Stas Techniques for Advanced Networking Applications (TANA) WG =09 Chair(s): TBD =09 Transport Area Director(s): * Magnus Westerlund * Lars Eggert =09 Transport Area Advisor: * Lars Eggert =09 Mailing Lists: =09 General Discussion: tana@ietf.org To Subscribe: tana-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/tana/ =09 Description of Working Group: =09 The TANA WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. =09 Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without ECN fill the buffer at the head of the bottleneck link. This increases the delay experienced by other applications. In the best case, with an ideally sized buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. =09 The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. =09 TANA is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. =09 The WG will work on the following: =09 (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. =09 Desired features of such an algorithm are: * saturate the bottleneck, * eliminate long standing queues and thus keep delay low when no other traffic is present, * quickly yield to regular best-effort traffic that uses standard TCP congestion control, * add little to the queueing delays induced by TCP traffic, * operate well in today's typical networks with FIFO queueing with drop-tail discipline, * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). =09 Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. =09 (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent transport connections to one peer and/or to different peers. =09 Standard Internet congestion control result in different transport connections sharing bottleneck capacity. When an application uses several unchoked and not rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. =09 Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. =09 (3) The WG will discuss how to best take into account prior work in the area. The outcome will be either incorporated into the document specifying the experimental congestion control algorithm or into a separate document summarizing prior work. =09 =09 =09 Goals and Milestones =09 TBD Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC TBD Submit "Transport for Advanced Networking Applications (TANA)" to the IESG for consideration as an Experimental RFC =09 =09 Internet-Drafts =09 Transport for Advanced Networking Applications (TANA) Problem Statement =09 http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statemen t-01.txt =09 No Requests for Comments -- Stanislav Shalunov =20 =09 Hacking Startups =20 ------_=_NextPart_001_01C935FE.5F0C7D29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good charter so far.  Agree that we need a = better=20 name.  I intend to participate as a document author, document = contributor,=20 and a reviewer.
 
Jason

From: p2pi-bounces@ietf.org=20 [mailto:p2pi-bounces@ietf.org] On Behalf Of Stanislav=20 Shalunov
Sent: Tuesday, October 21, 2008 9:17 = AM
To:=20 tana@ietf.org; p2pi@ietf.org; TSV Area
Subject: [p2pi] TANA = proposed=20 charter

At the BoF in Dublin, we observed strong interest and consensus = that the=20 TANA work should go forward as a working group.  Does the = following=20 proposed charter, based on the BoF description, capture what the = community was=20 interested in?

Thanks,  -- Stas



Techniques for Advanced Networking Applications (TANA)=20 WG

Chair(s):
TBD

Transport Area Director(s):
* = Magnus=20 Westerlund <magnus.westerlund@ericsson= .com>
*=20 Lars Eggert <lars.eggert@nokia.com>
Transport=20 Area Advisor:
* Lars Eggert <lars.eggert@nokia.com>
Mailing=20 Lists:

General Discussion: tana@ietf.org
To = Subscribe: tana-request@ietf.org
In = Body:=20 (un)subscribe
Archive: http://www.ietf.org/m= ail-archive/web/tana/

Description=20 of Working Group:

The TANA WG is chartered to standardize a = congestion=20 control mechanism that should saturate the bottleneck, maintain low = delay, and=20 yield to standard TCP.

Applications that transmit large amounts = of data=20 for a long time with congestion-limited TCP, but without ECN fill the = buffer=20 at the head of the bottleneck link. This increases the delay = experienced by=20 other applications. In the best case, with an ideally sized buffer of = one RTT,=20 the delay doubles. In some cases, the extra delay may be much larger. = This is=20 a particularly acute and common case is when P2P applications upload = over thin=20 home uplinks: delays in these cases can sometimes be of the order of=20 seconds.

The IETF's standard end-to-end transport protocols = have not=20 been designed to minimize the extra delay introduced by them into=20 the
network. TCP, as a side effect of filling the buffer until it=20 experiences drop-tail loss, effectively maximizes the delay. While = this works=20 well for applications that are not delay-sensitive, it harms = interactive=20 applications that share the same bottleneck. VoIP and games are = particularly=20 affected, but even web browsing may become problematic.

TANA is = a=20 transport-area WG that will focus on broadly applicable techniques = that allow=20 large amounts of data to be consistently transmitted without = substantially=20 affecting the delays experienced by other users and = applications.

The=20 WG will work on the following:

(1) An experimental congestion = control=20 algorithm for less-than-best-effort "background" transmissions, i.e., = an=20 algorithm that attempts to scavenge otherwise idle bandwidth for its=20 transmissions in a way that minimizes interference with regular = best-effort=20 traffic.

Desired features of such an algorithm are:
* = saturate the=20 bottleneck,
* eliminate long standing queues and thus keep delay = low when=20 no other traffic is present,
* quickly yield to regular best-effort = traffic=20 that uses standard TCP congestion control,
* add little to the = queueing=20 delays induced by TCP traffic,
* operate well in today's typical = networks=20 with FIFO queueing with drop-tail discipline,
* where available, = use=20 explicit congestion notification (ECN), active queue management (AQM), = and/or=20 end-to-end differentiated services (DiffServ).

Application of = this=20 algorithm to existing transport protocols (TCP, SCTP, DCCP) is = expected to=20 occur in the working groups that maintain those protocols.

(2) = A=20 document that clarifies the current practices of application design = and=20 reasons behind them and discusses the tradeoffs surrounding the use of = many=20 concurrent transport connections to one peer and/or to different=20 peers.

Standard Internet congestion control result in different = transport connections sharing bottleneck capacity. When an application = uses=20 several unchoked and not rate-limited transport connections to = transfer=20 through a bottleneck, it may obtain a larger fraction of the = bottleneck than=20 if it had used fewer connections. Although capacity is the most = commonly=20 considered bottleneck resource, middlebox state table entries are also = an=20 important resource for an end system communication. Other resource = types may=20 exist, and the guidelines are expected to comprehensively discuss=20 them.

Applications use a variety of techniques to mitigate = these=20 concerns.  These techniques have not always been reviewed by the = IETF and=20 their interaction with TCP dynamics is poorly understood.  The WG = document the known techniques, discussing the consequences and, where=20 appropriate, provide guidance to application designers.

(3) The = WG will=20 discuss how to best take into account prior work in the area. =  The=20 outcome will be either incorporated into the document specifying the=20 experimental congestion control algorithm or into a separate document=20 summarizing prior work.



Goals and Milestones

TBD =  Submit "Multiple Transport Connections in Applications Design" = to the=20 IESG for consideration as an Informational RFC
TBD  Submit = "Transport=20 for Advanced Networking Applications (TANA)" to the IESG for = consideration as=20 an Experimental RFC


Internet-Drafts

Transport for = Advanced=20 Networking Applications (TANA) Problem Statement
http://www.ietf.org/internet-drafts/draft-shalunov-tana-= problem-statement-01.txt

No=20 Requests for Comments




------_=_NextPart_001_01C935FE.5F0C7D29-- --===============0429858220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0429858220==-- From p2pi-bounces@ietf.org Fri Oct 24 10:34:04 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B0B3A6BB0; Fri, 24 Oct 2008 10:34:04 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B7B3A6BE4; Fri, 24 Oct 2008 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 SvdFQ3WXE8eB; Fri, 24 Oct 2008 10:34:02 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 157153A687D; Fri, 24 Oct 2008 10:34:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 3C4A0E10DDB; Fri, 24 Oct 2008 13:35:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UnIeHzit5HO; Fri, 24 Oct 2008 13:35:23 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id C2221E10D4A; Fri, 24 Oct 2008 13:35:23 -0400 (EDT) Date: Fri, 24 Oct 2008 13:35:23 -0400 (EDT) From: Laird Popkin To: Nicholas Weaver Message-ID: <8043274.398381224869723771.JavaMail.root@dkny.pando.com> In-Reply-To: <13265179-F62E-480F-B233-0F6160EC5701@ICSI.Berkeley.EDU> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: Nicholas Weaver , tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org My understanding from talking with some vendors of home routers is that if there were a standard for proper behavior in this area, they would be happy to conform to it. But if there's not a standard, it's hard for them to get engineers and sub-vendors to implement "be smart". - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Nicholas Weaver" To: "John Leslie" Cc: p2pi@ietf.org, tana@ietf.org, "Nicholas Weaver" Sent: Friday, October 24, 2008 1:24:49 PM (GMT-0500) America/New_York Subject: Re: [p2pi] TANA proposed charter -- packet marking question On Oct 24, 2008, at 9:12 AM, John Leslie wrote: >> >> >> I start a full rate, SINGLE TCP flow to this remote system. The ping >> time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem >> (not >> sure which at this moment) has a 3 second packet buffer, and simple >> FIFO behavior. Any full rate upload and I can kiss my connection >> goodbye. Period. End of story. Have a nice day. > > Fortunately, the Linksys _could_ be easily programmed to fix that -- > and if the problem becomes obvious enough to enough buyers, the > competition will fix it... I disagree. I've had DSL or cable modem connectivity for damn-near a decade now. And fixing it is easy: the data rates are trivial, the devices are often programmable, and the solution straightforward: just have only 30ms of packet buffer, not 3s. Yet these devices STILL have this problem. And the only reason that as a clued user it would be fixable if its the Linksys box is I DELIBERATELY purchased the version where I can replace the firmware to fix something the vendors refused to fix for themselves. And I just unplugged the linksys: its the DSL modem, purchased within the past 2.5 years. (The reason its not a problem for me is I don't use P2P apps, and only rarely upload large quantities of photos) So I think the conclusion should be there has been a market failure in this area, and that absent a miracle, this problem will remain. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:40:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94ABB3A68F0; Fri, 24 Oct 2008 10:40:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26393A68F0; Fri, 24 Oct 2008 10:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 KF5XDzLPBn-4; Fri, 24 Oct 2008 10:40:18 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AA9ED3A6841; Fri, 24 Oct 2008 10:40:18 -0700 (PDT) Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 24 Oct 2008 10:41:40 -0700 Received: from NA-EXMSG-C102.redmond.corp.microsoft.com ([157.54.110.48]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.54.46.186]) with mapi; Fri, 24 Oct 2008 10:41:40 -0700 From: Yu-Shun Wang To: "Narayanan, Vidya" , IESG IESG Date: Fri, 24 Oct 2008 10:41:38 -0700 Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfAAFNViIAAfhK2w Message-ID: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC96F@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20081006203532.B1D673A68AF@core3.amsl.com> <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" , "ietf@ietf.org" Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Vidya, > > > > Other usages will be considered as extensions to the charter once > > > > the work for the initial services has been completed. > > > > > > I think we should delete the sentence above. > > > > While it may seem redundant, I don't see anything wrong with > > that. It just means we may have a narrow scope now, but we > > will think about new extensions once we are done. > > I actually believe that if we designed the protocols right, we don't > need a recharter to carry other types of information - we can allow > registration of new information types for ALTO beyond the life of the > WG. Agreed in principle, and I don't think anyone on the list would disagree we should design an extensible protocol/solution. The need for such wording is, imo, for the practical purpose of scoping a working group. Any new type of info the wg considers must be carefully evaluated for the impacts and such. The current charter just says we will focus on the protocol and certain types of info. Note that it doesn't say the protocol must NOT be extensible. (If it does, then we should change that.) <...> > > I read the list below somewhat differently. These are not for > > relative importance of the information, but kind of a min bar > > for what we want to do. While some may need re-wording, the > > intent is fine, IMO. > > I'm not so sure. Basically, it is a question of what usage these are > evaluated based on. Let's take a couple of examples. Whether the ALTO > service can provide a piece of information is dependent on various > factors - some things are dependent on whether such information is > available from other places today (e.g., topology or ASNs, etc.); I > think this set of questions has been written with that mindset. But, > there are others (e.g., quality, reputation, semantic expertise, etc.) > that are totally based on the type of the p2p overlay and whether > clients can provide that information. Similarly, whether some > information is useful to a client is totally contextual to the > application as well. Once again, I don't think we are that far apart, and in a sense, what is missing is really a note that the answers to these questions largely depend on the type of info they apply to. Although I still think these are fair questions to ask on the info under consideration. I would totally agree that these need re-wording for clarity. Let's wait for the next round of charter update. :-) Thanks, yushun > > > > - Can the ALTO service technically provide that information? > > > > - Is the ALTO service willing to obtain and divulge that > > > > information? > > > > - Is it information that a client will find useful? > > > > - Can a client get that information without excessive privacy > > > > concerns(e.g. by sending large lists of peers)? > > > > - Is it information that a client cannot find easily some > > > > other way? > > > > > > > > After these criteria are met, the generality of the data will be > > > > considered for prioritizing standardization work, for example the > > > > number of operators and clients that are likely to be able to > > > > provide or use that particular data. > > > > > > The above again gets into our evaluation of what is > > > important based on > > > what we know today and is limiting. > > > > This point does need some clarification and rewording. > > > > Thanks, > > yushun _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 10:41:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CA628C14C; Fri, 24 Oct 2008 10:41:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0903A6A69; Fri, 24 Oct 2008 10:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=0.189, 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 Eq0ibk++ED4q; Fri, 24 Oct 2008 10:41:24 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C3D213A6841; Fri, 24 Oct 2008 10:41:23 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52310873; Fri, 24 Oct 2008 13:42:15 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 13:42:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 13:42:14 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60289636A@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <13265179-F62E-480F-B233-0F6160EC5701@ICSI.Berkeley.EDU> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tana] [p2pi] TANA proposed charter -- packet marking question Thread-Index: Ack1/YqzPIVCLHb2QWCb5AbhSukfSAAAam4Q References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com><3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com><20081024145218.GB88592@verdi><20081024161246.GD88592@verdi> <13265179-F62E-480F-B233-0F6160EC5701@ICSI.Berkeley.EDU> From: "Woundy, Richard" To: "Nicholas Weaver" , "John Leslie" X-OriginalArrivalTime: 24 Oct 2008 17:42:14.0867 (UTC) FILETIME=[DA176A30:01C935FF] Cc: tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I suspect that cable modems and DSL modems have been over-buffered in the upstream direction for many years, and it will take many years to purge the old modems out of the installed base. So I believe it is important for 'TANA' transport to work in that environment. However, there may be an opportunity to point future modem developers in the correct direction, e.g. correct buffering, AQM and ECN. It would be helpful if the 'TANA' transport could take advantage of that support in the future. > just have only 30ms of packet buffer, not 3s I've heard from other experts that 100ms or so of packet buffer makes sense. I think we can agree that 1-3 seconds does not make sense. -- Rich -----Original Message----- From: tana-bounces@ietf.org [mailto:tana-bounces@ietf.org] On Behalf Of Nicholas Weaver Sent: Friday, October 24, 2008 1:25 PM To: John Leslie Cc: p2pi@ietf.org; tana@ietf.org; Nicholas Weaver Subject: Re: [tana] [p2pi] TANA proposed charter -- packet marking question On Oct 24, 2008, at 9:12 AM, John Leslie wrote: >> >> >> I start a full rate, SINGLE TCP flow to this remote system. The ping >> time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem >> (not >> sure which at this moment) has a 3 second packet buffer, and simple >> FIFO behavior. Any full rate upload and I can kiss my connection >> goodbye. Period. End of story. Have a nice day. > > Fortunately, the Linksys _could_ be easily programmed to fix that -- > and if the problem becomes obvious enough to enough buyers, the > competition will fix it... I disagree. I've had DSL or cable modem connectivity for damn-near a decade now. And fixing it is easy: the data rates are trivial, the devices are often programmable, and the solution straightforward: just have only 30ms of packet buffer, not 3s. Yet these devices STILL have this problem. And the only reason that as a clued user it would be fixable if its the Linksys box is I DELIBERATELY purchased the version where I can replace the firmware to fix something the vendors refused to fix for themselves. And I just unplugged the linksys: its the DSL modem, purchased within the past 2.5 years. (The reason its not a problem for me is I don't use P2P apps, and only rarely upload large quantities of photos) So I think the conclusion should be there has been a market failure in this area, and that absent a miracle, this problem will remain. _______________________________________________ tana mailing list tana@ietf.org https://www.ietf.org/mailman/listinfo/tana _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 11:18:07 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCDB3A68E8; Fri, 24 Oct 2008 11:18:07 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE6A3A68E4 for ; Fri, 24 Oct 2008 11:18:07 -0700 (PDT) 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 hMmHDzVaOEdU for ; Fri, 24 Oct 2008 11:18:06 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 6FEBB3A68E1 for ; Fri, 24 Oct 2008 11:18:05 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m9OIJQSe001970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 13:19:26 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9OIJPFP023679; Fri, 24 Oct 2008 13:19:25 -0500 (CDT) Message-ID: <49021199.8030802@alcatel-lucent.com> Date: Fri, 24 Oct 2008 13:19:05 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.14 (X11/20080521) MIME-Version: 1.0 To: "Livingood, Jason" References: <083CB532-07CC-4CFB-B448-EDBA39EF8D93@multicasttech.com> <45AEC6EF95942140888406588E1A660205B9E6F9@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E6F9@PACDCEXCMB04.cable.comcast.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: p2pi@ietf.org Subject: Re: [p2pi] [tana] alto wg meeting in Minneapolis ? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Livingood, Jason wrote: > How do we get ALTO on the list of proposed BoFs as well? I believe Lisa has already requested a BoF slot. It is caught somewhere in the bureaucratic snafu and should show up. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 11:31:51 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3393A689A; Fri, 24 Oct 2008 11:31:51 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5669F3A694E for ; Fri, 24 Oct 2008 11:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 kqb3MfarXY9C for ; Fri, 24 Oct 2008 11:31:49 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by core3.amsl.com (Postfix) with ESMTP id 201CF3A68C4 for ; Fri, 24 Oct 2008 11:31:49 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id c49so238146wra.17 for ; Fri, 24 Oct 2008 11:33:11 -0700 (PDT) Received: by 10.100.92.4 with SMTP id p4mr1340167anb.3.1224873190757; Fri, 24 Oct 2008 11:33:10 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id h9sm559792wxd.4.2008.10.24.11.33.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 11:33:10 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: tana@ietf.org, p2pi@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 11:33:06 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> X-Mailer: Apple Mail (2.929.2) Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 24, 2008, at 8:09 AM, Nicholas Weaver wrote: > NAT box or DSL modem (not sure which at this moment) has a 3 second > packet buffer, and simple FIFO behavior. I'm willing to bet it's the DSL modem and that the actual buffer size is a binary-round number, likely 64kB. The NAT box isn't naturally a bottleneck and the brand you have doesn't attempt to impose an artificial one. By the way, buffer provisioning for slow links is a problem that's harder than the "one RTT worth divided by whatnot" rule makes it out to be. If anyone who makes DSL/cable modems is listening, please don't just cut the buffer -- it may well do more harm than good. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 11:36:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5463A682A; Fri, 24 Oct 2008 11:36:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340E03A6879 for ; Fri, 24 Oct 2008 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 Ap+zoxgR+VC1 for ; Fri, 24 Oct 2008 11:36:18 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by core3.amsl.com (Postfix) with ESMTP id 4342F3A67AD for ; Fri, 24 Oct 2008 11:36:17 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id v27so472396ele.13 for ; Fri, 24 Oct 2008 11:37:39 -0700 (PDT) Received: by 10.231.15.205 with SMTP id l13mr1489026iba.0.1224873459066; Fri, 24 Oct 2008 11:37:39 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 34sm955043yxm.0.2008.10.24.11.37.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 11:37:38 -0700 (PDT) Message-Id: <612D668C-F7B8-43C7-9698-BA756B7E9914@shlang.com> From: Stanislav Shalunov To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E6FA@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 11:37:35 -0700 References: <45AEC6EF95942140888406588E1A660205B9E6FA@PACDCEXCMB04.cable.comcast.com> X-Mailer: Apple Mail (2.929.2) Cc: tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] [tana] p2pi@ vs. tana@ / alto@ (decomm p2pi@?) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Jason, tana@ietf exists, but alto@ietf doesn't seem to yet. I've been instructed to cross-post the proposed TANA charter to p2pi@, or I wouldn't do it. I'd prefer the TANA-specific discussion to move to tana@, but I still get a few (good) messages a day in the moderator queue from non-subscribers. Everyone, If you care about the TANA work, please subscribe to tana@ietf.org: https://www.ietf.org/mailman/listinfo/tana Thanks, -- Stas On Oct 24, 2008, at 10:25 AM, Livingood, Jason wrote: > Seems like there is a lot of cross-posting, and that at least tana@ > and > alto@ lists are more targeted now. Is it time to deactivate the p2pi@ > mailing list? > > Jason > _______________________________________________ > tana mailing list > tana@ietf.org > https://www.ietf.org/mailman/listinfo/tana -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 12:51:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9AA3A6859; Fri, 24 Oct 2008 12:51:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1583A6849 for ; Fri, 24 Oct 2008 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 atvYtb6pgvRd for ; Fri, 24 Oct 2008 12:51:19 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 403983A67AF for ; Fri, 24 Oct 2008 12:51:19 -0700 (PDT) Received: by gxk9 with SMTP id 9so132015gxk.13 for ; Fri, 24 Oct 2008 12:52:41 -0700 (PDT) Received: by 10.65.215.14 with SMTP id s14mr2985823qbq.47.1224877960690; Fri, 24 Oct 2008 12:52:40 -0700 (PDT) Received: by 10.65.234.2 with HTTP; Fri, 24 Oct 2008 12:52:40 -0700 (PDT) Message-ID: <3efc39a60810241252t7670ac41gbfaf550443ecd53b@mail.gmail.com> Date: Fri, 24 Oct 2008 12:52:40 -0700 From: "Robb Topolski" To: "John Leslie" In-Reply-To: <20081024145218.GB88592@verdi> MIME-Version: 1.0 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> Cc: tana@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0637110783==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0637110783== Content-Type: multipart/alternative; boundary="----=_Part_58387_14360526.1224877960698" ------=_Part_58387_14360526.1224877960698 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Oct 24, 2008 at 7:52 AM, John Leslie wrote: > However, I wonder how many of us are on the same page when it comes > to the question of packet marking. > > Some of us quite clearly see this as a question of _how_ to use > DiffServ; others of us see this as how to _avoid_ DiffServ. > > It's not clear to me what exactly you are referring to here. If DiffServ is something to be avoided, then something is wrong. I think the goal is something akin to "get the appropriate and desired next hop behavior if the ISP supports it" and get the ISPs out of the business of trying to guess. If you're worried about someone trying to use this work to game the system, then I think a quota on the exploited DSCPs could provide the necessary disincentive. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_58387_14360526.1224877960698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Oct 24, 2008 at 7:52 AM, John Leslie <john@jlc.net> wrote:
  However, I wonder how many of us are on the same page when it comes
to the question of packet marking.

  Some of us quite clearly see this as a question of _how_ to use
DiffServ; others of us see this as how to _avoid_ DiffServ.


It's not clear to me what exactly you are referring to here.  If DiffServ is something to be avoided, then something is wrong.

I think the goal is something akin to "get the appropriate and desired next hop behavior if the ISP supports it" and get the ISPs out of the business of trying to guess.  If you're worried about someone trying to use this work to game the system, then I think a quota on the exploited DSCPs could provide the necessary disincentive.

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_58387_14360526.1224877960698-- --===============0637110783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0637110783==-- From p2pi-bounces@ietf.org Fri Oct 24 13:24:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445F328C14F; Fri, 24 Oct 2008 13:24:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B40B28C131; Fri, 24 Oct 2008 13:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, 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 MeEJ2fu+JYFz; Fri, 24 Oct 2008 13:24:29 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 4C14A28C13F; Fri, 24 Oct 2008 13:24:29 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9OKPTMP028866; Fri, 24 Oct 2008 13:25:30 -0700 (PDT) Message-Id: <6C99C7B8-E8BD-4DEF-BE59-8326B65501D8@icsi.berkeley.edu> From: Nicholas Weaver To: Stanislav Shalunov In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 13:25:29 -0700 References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> X-Mailer: Apple Mail (2.929.2) Cc: p2pi@ietf.org, tana@ietf.org, Nicholas Weaver Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Oct 24, 2008, at 11:33 AM, Stanislav Shalunov wrote: > On Oct 24, 2008, at 8:09 AM, Nicholas Weaver wrote: >> NAT box or DSL modem (not sure which at this moment) has a 3 second >> packet buffer, and simple FIFO behavior. > > I'm willing to bet it's the DSL modem and that the actual buffer > size is a binary-round number, likely 64kB. Confirmed by subsequest testing. Although I think its 128 kB: Sustained transfer rate is >40 kB/s, and latency is ~3S. And my ISP has its own problem, the downlink is also overbuffered, but more like 1s. > By the way, buffer provisioning for slow links is a problem that's > harder than the "one RTT worth divided by whatnot" rule makes it out > to be. If anyone who makes DSL/cable modems is listening, please > don't just cut the buffer -- it may well do more harm than good. You're right. Point taken. But some of these are just SO far off what they should be that they really do need to be cut, badly. There is probably a good argument for 300ms, 100ms, and perhaps even 30ms (under the "better underbuffered then overbuffered" argument), and tradeoffs between maintaining peak TCP performance and maintaining interactivity if there isn't active queue management. This needs to be hashed out (TANA isn't the place, but it does need to be someplace.) And there may be arguments that you want something different on DSL (which is point to point) or DOCSIS (mediated shared access). Or even something adaptive. But 1s and 3s are just so far out there for typical residential networks and do represent a big issue, as such buffers mean that a single full-rate TCP flow makes the network completely unusable for interactive tasks. What is the right IETF working group that should address this issue, to provide better guidance to equipment makers? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Oct 24 13:34:22 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1143A6A2C; Fri, 24 Oct 2008 13:34:22 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254D53A6990; Fri, 24 Oct 2008 13:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7pDu1aBk90ki; Fri, 24 Oct 2008 13:34:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2186B3A6859; Fri, 24 Oct 2008 13:34:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,480,1220227200"; d="scan'208";a="95892750" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2008 20:35:36 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9OKZaCJ028373; Fri, 24 Oct 2008 13:35:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9OKZaU5019763; Fri, 24 Oct 2008 20:35:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Oct 2008 13:35:36 -0700 Received: from [10.32.241.68] ([10.32.241.68]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Oct 2008 13:35:35 -0700 Message-Id: <49FEC476-2F90-4572-A4B7-F7B2D79A3ABB@cisco.com> From: Bruce Davie To: Laird Popkin In-Reply-To: <8043274.398381224869723771.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 16:35:32 -0400 References: <8043274.398381224869723771.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 24 Oct 2008 20:35:35.0995 (UTC) FILETIME=[11A598B0:01C93618] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3780; t=1224880536; x=1225744536; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[p2pi]=20TANA=20proposed=20charter=20-- =20packet=20marking=20question |Sender:=20; bh=8I0lj5Y7EoMNhO3HZcgGj8YaiaGCIK3qm6Wr5dzeisE=; b=S3VZsYJKn79qSsCz7XeqM094m7Ges7yXqHSUpOzdXUSKpTkX+6q03fubaV 0qsmdLqnDh2S6rF3/hZk6SmDlRbJEfwCHr2Me4TDsIfzGdsSLn4Lc+oL+RD+ iuPjEkIQDp; Authentication-Results: sj-dkim-4; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: p2pi@ietf.org, tana@ietf.org, Nicholas Weaver Subject: Re: [p2pi] TANA proposed charter -- packet marking question X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org It's actually not that easy to get a router and an access device (DSL modem or cable modem) to do the right thing when they are in separate boxes separated by an Ethernet: the router knows how to do smart queuing but there's no queue on the Ethernet; the access device isn't smart enough to do, say, Diffserv in its queue facing the uplink. (My home configuration works pretty well, but is so far from a typical home configuration that it's not worth talking about.) As was noted in the BoF in Dublin, getting well designed routers and access devices out into the world and properly configured, and getting all the end systems to use Diffserv marking is a solution that we're not likely to see soon. That is why the charter says that goals of the algorithm are: > * operate well in networks with FIFO queueing with drop-tail > discipline, > * where available, use explicit congestion notification (ECN), > active queue management (AQM), and/or end-to-end differentiated > services (DiffServ). The first bullet says "deal with the world as it is"; the second says "deal with the world as you wish it were" I think that is a very sensible approach. Bruce On Oct 24, 2008, at 1:35 PM, Laird Popkin wrote: > My understanding from talking with some vendors of home routers is > that if there were a standard for proper behavior in this area, they > would be happy to conform to it. But if there's not a standard, it's > hard for them to get engineers and sub-vendors to implement "be > smart". > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Nicholas Weaver" > To: "John Leslie" > Cc: p2pi@ietf.org, tana@ietf.org, "Nicholas Weaver" > > Sent: Friday, October 24, 2008 1:24:49 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] TANA proposed charter -- packet marking question > > > On Oct 24, 2008, at 9:12 AM, John Leslie wrote: >>> >>> >>> I start a full rate, SINGLE TCP flow to this remote system. The >>> ping >>> time jumps up to 3 seconds! Yes, the stupid NAT box or DSL modem >>> (not >>> sure which at this moment) has a 3 second packet buffer, and simple >>> FIFO behavior. Any full rate upload and I can kiss my connection >>> goodbye. Period. End of story. Have a nice day. >> >> Fortunately, the Linksys _could_ be easily programmed to fix that -- >> and if the problem becomes obvious enough to enough buyers, the >> competition will fix it... > > I disagree. > > I've had DSL or cable modem connectivity for damn-near a decade now. > And fixing it is easy: the data rates are trivial, the devices are > often programmable, and the solution straightforward: just have only > 30ms of packet buffer, not 3s. Yet these devices STILL have this > problem. > > And the only reason that as a clued user it would be fixable if its > the Linksys box is I DELIBERATELY purchased the version where I can > replace the firmware to fix something the vendors refused to fix for > themselves. And I just unplugged the linksys: its the DSL modem, > purchased within the past 2.5 years. > > (The reason its not a problem for me is I don't use P2P apps, and only > rarely upload large quantities of photos) > > So I think the conclusion should be there has been a market failure in > this area, and that absent a miracle, this problem will remain. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Oct 26 21:52:54 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910743A6825; Sun, 26 Oct 2008 21:52:54 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F093A67DB for ; Sun, 26 Oct 2008 21:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 hEYlIHfllCU0 for ; Sun, 26 Oct 2008 21:52:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 9D7CF3A6850 for ; Sun, 26 Oct 2008 21:52:50 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1853607rvf.49 for ; Sun, 26 Oct 2008 21:52:50 -0700 (PDT) Received: by 10.140.127.20 with SMTP id z20mr2985414rvc.77.1225083169952; Sun, 26 Oct 2008 21:52:49 -0700 (PDT) Received: by 10.141.69.3 with HTTP; Sun, 26 Oct 2008 21:52:49 -0700 (PDT) Message-ID: <3efc39a60810262152t69b45422h8dcdf3797b47a164@mail.gmail.com> Date: Sun, 26 Oct 2008 21:52:49 -0700 From: "Robb Topolski" To: "Stanislav Shalunov" In-Reply-To: <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com> MIME-Version: 1.0 References: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com> <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com> Cc: "p2pi@ietf.org" , "tana@ietf.org" , "Das, Saumitra" , "tsv-area@ietf.org" Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096812619==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0096812619== Content-Type: multipart/alternative; boundary="----=_Part_33673_5140037.1225083169940" ------=_Part_33673_5140037.1225083169940 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline For reasons I don't quite understand, my view of this conversation is very fragmented. On Tue, Oct 21, 2008 at 3:02 PM, Stanislav Shalunov wrote: > The genesis of TANA was at the P2PI workshop. A lot of people there were > concerned about multiple connections used by P2P apps. Some concerns are > meritorious, others require mostly just information -- there, apparently, > exists a belief that P2P apps are designed to open multiple TCP connections > to the same destination to circumvent TCP fairness. (I even have an inkling > of how that one could get started.) > People also said that P2P applications filled up all available bandwidth, with no explanation provided as to how these applications exceed the limits programmatically imposed by the ISP. Before anyone redefines fairness, we need data on the current situation. We need to ensure that redefining fairness isn't simply suppressing a market choice. One ISP is reportedly prioritizing HTTP above most other traffic. If, 15 years ago, someone prioritized Gopher over all other traffic, then probably never would have succeeded it. Please let's not write this problem statement without data confirming the problem and the size of the fairness bias (which probably does exist on paper, but we have no data as to the extent given these applications at ISP-subscriber speeds and P2P latencies). Also, I think the name change is useful since there is not inkling that this >> really is about congestion control. Scavenger Network Congestion Protocols >> sounds good. >> > > White ball noted. That makes three. Incidentally, does anyone *dislike* > this name? > > I worry about the idea of moving congestion management and packet handling instructions up a layer in the network stack. Worry is not fatal, but it fogs up an area of clarity. I also worry that the last two attempts to help transit providers understand their customer's packets handling needs haven't really been seriously trialled by ISPs as far as I know. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_33673_5140037.1225083169940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline For reasons I don't quite understand, my view of this conversation is very fragmented.


On Tue, Oct 21, 2008 at 3:02 PM, Stanislav Shalunov <shalunov@shlang.com> wrote:
The genesis of TANA was at the P2PI workshop.  A lot of people there were concerned about multiple connections used by P2P apps.  Some concerns are meritorious, others require mostly just information -- there, apparently, exists a belief that P2P apps are designed to open multiple TCP connections to the same destination to circumvent TCP fairness.  (I even have an inkling of how that one could get started.)

People also said that P2P applications filled up all available bandwidth, with no explanation provided as to how these applications exceed the limits programmatically imposed by the ISP.  

Before anyone redefines fairness, we need data on the current situation.  We need to ensure that redefining fairness isn't simply suppressing a market choice.  One ISP is reportedly prioritizing HTTP above most other traffic.  If, 15 years ago, someone prioritized Gopher over all other traffic, then probably never would have succeeded it. 

Please let's not write this problem statement without data confirming the problem and the size of the fairness bias (which probably does exist on paper, but we have no data as to the extent given these applications at ISP-subscriber speeds and P2P latencies). 
 

Also, I think the name change is useful since there is not inkling that this really is about congestion control. Scavenger Network Congestion Protocols sounds good.

White ball noted.  That makes three.  Incidentally, does anyone *dislike* this name?


I worry about the idea of moving congestion management and packet handling instructions up a layer in the network stack.   Worry is not fatal, but it fogs up an area of clarity.  I also worry that the last two attempts to help transit providers understand their customer's packets handling needs haven't really been seriously trialled by ISPs as far as I know. 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
------=_Part_33673_5140037.1225083169940-- --===============0096812619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============0096812619==-- From p2pi-bounces@ietf.org Mon Oct 27 16:17:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C1528C0E0; Mon, 27 Oct 2008 16:17:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A293A6813 for ; Mon, 27 Oct 2008 16:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001] 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 ezZIA6aG0HBa for ; Mon, 27 Oct 2008 16:17:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id CA5C33A6BBC for ; Mon, 27 Oct 2008 16:17:19 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2500089wfd.31 for ; Mon, 27 Oct 2008 16:17:03 -0700 (PDT) Received: by 10.142.240.19 with SMTP id n19mr2984530wfh.191.1225149423071; Mon, 27 Oct 2008 16:17:03 -0700 (PDT) Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 24sm1363740wff.17.2008.10.27.16.17.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Oct 2008 16:17:01 -0700 (PDT) Message-Id: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com> From: Stanislav Shalunov To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 16:16:59 -0700 X-Mailer: Apple Mail (2.929.2) Cc: Richard Woundy Subject: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1370749547==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1370749547== Content-Type: multipart/alternative; boundary=Apple-Mail-671--118399711 --Apple-Mail-671--118399711 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit We put together a first iteration of a very simple ALTO solution draft. We hope this will be useful as an example point in the solutions space and thus allow to refine the requirements document and the problem statement. http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.txt Abstract The ALTO Information Export Service is a simple way to convey ISP routing policy preferences to applications. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer and content delivery networks. Applications already have access to great amount of underlying topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to download to every client. What is missing is the routing policy information -- what does the local ISP actually prefer? This document describes a very simple mechanism that would allow to export such information to applications. While such service would primarily be provided by the network, i.e., the local ISP, third parties could also operate this service. -- Stanislav Shalunov --Apple-Mail-671--118399711 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
We put together a first = iteration of a very simple ALTO solution draft.  We hope this will = be useful as an example point in the solutions space and thus allow to = refine the requirements document and the problem = statement.


Abstract

   The ALTO Information Export Service is a simple way to = convey ISP
   routing policy preferences to = applications.  Applications that could
   use = this service are those that have a choice in = connection
   endpoints.  Examples of such = applications are peer-to-peer and
   content = delivery networks.

   Applications = already have access to great amount of underlying
   = topology information.  For example, views of the Internet = routing
   table are easily available at looking = glass servers and entirely
   practical to download = to every client.  What is missing is the
   = routing policy information -- what does the local ISP = actually
   = prefer?

   This document describes a = very simple mechanism that would allow to
   export = such information to applications.  While such service = would
   primarily be provided by the network, i.e., = the local ISP, third
   parties could also operate = this service.



= --Apple-Mail-671--118399711-- --===============1370749547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1370749547==-- From p2pi-bounces@ietf.org Tue Oct 28 10:23:19 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBA828C349; Tue, 28 Oct 2008 10:23:19 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA7328C327 for ; Tue, 28 Oct 2008 10:23:17 -0700 (PDT) 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 k6jVjQLg++4A for ; Tue, 28 Oct 2008 10:23:16 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id B53A828C2D4 for ; Tue, 28 Oct 2008 10:23:16 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 31C4933C36; Tue, 28 Oct 2008 13:23:16 -0400 (EDT) Date: Tue, 28 Oct 2008 13:23:16 -0400 From: John Leslie To: Stanislav Shalunov Message-ID: <20081028172316.GC7530@verdi> References: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stanislav Shalunov wrote: > > We put together a first iteration of a very simple ALTO solution > draft. We hope this will be useful as an example point in the > solutions space and thus allow to refine the requirements document and > the problem statement. > > http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.txt ] ... ] 7. Mapping IPs to ASNs I expect ISPs will sometimes mean different things by "preferring" ASNs. (This is a pretty generic problem with ASNs in ALTO.) ISPs generally peer with a limited number of ASNs, and reach IPs "owned" by other ASNs through routes from the ASNs they directly peer with. What actually causes an ISP to "prefer" a set of IPs is knowing that they will use a route to them through a particular AS they peer with. This is _not_ the same as which AS "owns" the IP in question. (Nor is "owned by an AS" necessarily a meaningful statement for a CIDR block.) BGP looking-glass views show which ASNs "originate" routes to a CIDR block. It is not particularly unusual to find more than one AS "originating" such a route. Thus, looking-glass results cannot assure that the route a packet will actually follow to reach an IP address _ever_ passes through a particular AS. Looking-glass views _will_ generally show "holes" punched in CIDR blocks "owned" by one AS for the purpose of balancing traffic to a multihomed customer of that AS (even though it may be that _none_ of the traffic will actually pass through the "owner" AS). But looking- glass views tend to contain routes that are never seen by routers not "near the backbone". The routing view which actually matters is the view of the ISP router which dispatches the particular packet at a peering point. Thus, IMHO, the ISP should usually be the provider of the mapping of IPs to ASNs. (This mapping may change several times per second when routes "flap", but that's a balancing act the ISP is best able to attempt.) In any case, if ALTO provides ASN "preferences" at all we should provide a mechanism for the ISP to perform mapping of IP to ASN. (IMHO, at least...) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 28 14:30:04 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A38B28C31A; Tue, 28 Oct 2008 14:30:04 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C8028C316 for ; Tue, 28 Oct 2008 14:30:03 -0700 (PDT) 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 9f8eHjBCMDR6 for ; Tue, 28 Oct 2008 14:30:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 3F55A28C30A for ; Tue, 28 Oct 2008 14:30:02 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9SLTwc5017951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Oct 2008 16:29:58 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m9SLTwfX029956 for ; Tue, 28 Oct 2008 16:29:58 -0500 (CDT) Message-ID: <49078456.10304@alcatel-lucent.com> Date: Tue, 28 Oct 2008 16:29:58 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "p2pi@ietf.org" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [p2pi] ALTO session scheduled X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Folks: The preliminary agenda (https://datatracker.ietf.org/meeting/73/agenda.html) shows that alto has been scheduled for a 2 hour slot Tues, Nov. 18. Note that this is a preliminary agenda, so it could well be that they move us around before the final one is published. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 28 16:02:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA5728C32B; Tue, 28 Oct 2008 16:02:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9088428C32F for ; Tue, 28 Oct 2008 16:02:02 -0700 (PDT) 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 mI-OT6CuJrWb for ; Tue, 28 Oct 2008 16:01:55 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 46A7F3A6931 for ; Tue, 28 Oct 2008 16:01:55 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52469714; Tue, 28 Oct 2008 19:01:13 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 19:01:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 19:00:35 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F6028963B5@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <20081028172316.GC7530@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack5IfFnziqzqTA+S7a0lPNtm6F0ogADRzeA References: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com> <20081028172316.GC7530@verdi> From: "Woundy, Richard" To: "John Leslie" , "Stanislav Shalunov" X-OriginalArrivalTime: 28 Oct 2008 23:01:13.0313 (UTC) FILETIME=[13258510:01C93951] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > The routing view which actually matters is the view of the ISP router which dispatches the particular packet at a peering point. Thus, IMHO, the ISP should usually be the provider of the mapping of IPs to ASNs. Before this email, my opinion was that if an ISP wanted to include ASN(s) in the policy to be returned by the ALTO service, then the ISP should also supply the IP prefix to ASN mappings, so that the combined ALTO service guidance came from a consistent information source (the ISP). But I didn't have a strong opinion against using a looking glass server instead for the IP-to-ASN mappings. If I understood John correctly, the looking glass server's view of IP-to-ASN mappings may depend on the server's location in the Internet topology, and that view may not be equivalent to the view of the ISP providing the ALTO service. Here is one example: Within one ISP's backbone, there may be a set of specific IPv4 prefixes coming from many origin AS's. Within another ISP's backbone, these specific prefixes may have been replaced (and subsumed) by a single aggregate prefix with a different origin AS (e.g. the first backbone). Therefore, the looking glass servers for the first and second backbones would differ on the correct origin AS with respect to this aggregated prefix. Here is a relevant RIPE presentation (from 2003) in which they faced similar problems with reporting ASNs in traceroutes: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra ceroutes.pdf. In the scenario of the RIPE presentation, the route information in the Internet Routing Registries and in the global BGP routes were often at odds with one another; slides 8, 10, and 11 describe some interesting cases that relate to this discussion about looking glasses. John, in short, I think you make a very good point. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of John Leslie Sent: Tuesday, October 28, 2008 1:23 PM To: Stanislav Shalunov Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service Stanislav Shalunov wrote: > > We put together a first iteration of a very simple ALTO solution > draft. We hope this will be useful as an example point in the > solutions space and thus allow to refine the requirements document and > the problem statement. > > http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx t ] ... ] 7. Mapping IPs to ASNs I expect ISPs will sometimes mean different things by "preferring" ASNs. (This is a pretty generic problem with ASNs in ALTO.) ISPs generally peer with a limited number of ASNs, and reach IPs "owned" by other ASNs through routes from the ASNs they directly peer with. What actually causes an ISP to "prefer" a set of IPs is knowing that they will use a route to them through a particular AS they peer with. This is _not_ the same as which AS "owns" the IP in question. (Nor is "owned by an AS" necessarily a meaningful statement for a CIDR block.) BGP looking-glass views show which ASNs "originate" routes to a CIDR block. It is not particularly unusual to find more than one AS "originating" such a route. Thus, looking-glass results cannot assure that the route a packet will actually follow to reach an IP address _ever_ passes through a particular AS. Looking-glass views _will_ generally show "holes" punched in CIDR blocks "owned" by one AS for the purpose of balancing traffic to a multihomed customer of that AS (even though it may be that _none_ of the traffic will actually pass through the "owner" AS). But looking- glass views tend to contain routes that are never seen by routers not "near the backbone". The routing view which actually matters is the view of the ISP router which dispatches the particular packet at a peering point. Thus, IMHO, the ISP should usually be the provider of the mapping of IPs to ASNs. (This mapping may change several times per second when routes "flap", but that's a balancing act the ISP is best able to attempt.) In any case, if ALTO provides ASN "preferences" at all we should provide a mechanism for the ISP to perform mapping of IP to ASN. (IMHO, at least...) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 28 16:49:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECBA3A6931; Tue, 28 Oct 2008 16:49:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509903A68D8 for ; Tue, 28 Oct 2008 16:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cNx1jbxT57on for ; Tue, 28 Oct 2008 16:49:48 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 345913A6805 for ; Tue, 28 Oct 2008 16:49:44 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 28 Oct 2008 16:49:42 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 16:48:51 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2008 19:48:47 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Oct 2008 23:48:46 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 28 Oct 2008 16:48:38 -0700 From: Reinaldo Penno To: "Woundy, Richard" , John Leslie , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack5IfFnziqzqTA+S7a0lPNtm6F0ogADRzeAAAopHPc= In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6028963B5@PACDCEXCMB06.cable.comcast.com> Mime-version: 1.0 X-OriginalArrivalTime: 28 Oct 2008 23:48:47.0861 (UTC) FILETIME=[B896FA50:01C93957] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree with you Rich. Getting an accurate mapping of IP to 'owner' ASs is not an easy task. Some people spent a lot of time on this. I did not know this presentation. Here is a another very good reference: Towards an Accurate AS-Level Traceroute Tool Zhuoqing Morley Mao Jennifer Rexford Jia Wang Randy H. Katz UC Berkeley AT&T Labs=ADResearch AT&T Labs=ADResearch UC Berkeley zmao@cs.berkeley.edu jrex@research.att.com jiawang@research.att.com randy@cs.berkeley.edu In this paper they discuss in detail all the roadblocks to have a traceroute tool that maps IP to ASs. Thanks, Reinaldo On 10/28/08 4:00 PM, "Woundy, Richard" wrote: >> The routing view which actually matters is the view of the ISP router > which dispatches the particular packet at a peering point. Thus, IMHO, > the ISP should usually be the provider of the mapping of IPs to ASNs. > = > Before this email, my opinion was that if an ISP wanted to include > ASN(s) in the policy to be returned by the ALTO service, then the ISP > should also supply the IP prefix to ASN mappings, so that the combined > ALTO service guidance came from a consistent information source (the > ISP). But I didn't have a strong opinion against using a looking glass > server instead for the IP-to-ASN mappings. > = > If I understood John correctly, the looking glass server's view of > IP-to-ASN mappings may depend on the server's location in the Internet > topology, and that view may not be equivalent to the view of the ISP > providing the ALTO service. > = > Here is one example: Within one ISP's backbone, there may be a set of > specific IPv4 prefixes coming from many origin AS's. Within another > ISP's backbone, these specific prefixes may have been replaced (and > subsumed) by a single aggregate prefix with a different origin AS (e.g. > the first backbone). Therefore, the looking glass servers for the first > and second backbones would differ on the correct origin AS with respect > to this aggregated prefix. > = > Here is a relevant RIPE presentation (from 2003) in which they faced > similar problems with reporting ASNs in traceroutes: > http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra > ceroutes.pdf. In the scenario of the RIPE presentation, the route > information in the Internet Routing Registries and in the global BGP > routes were often at odds with one another; slides 8, 10, and 11 > describe some interesting cases that relate to this discussion about > looking glasses. > = > John, in short, I think you make a very good point. > = > -- Rich > = > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Tuesday, October 28, 2008 1:23 PM > To: Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO Information Export Service > = > Stanislav Shalunov wrote: >> = >> We put together a first iteration of a very simple ALTO solution >> draft. We hope this will be useful as an example point in the >> solutions space and thus allow to refine the requirements document and > = >> the problem statement. >> = >> = > http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx > t > ] ... > ] 7. Mapping IPs to ASNs > = > I expect ISPs will sometimes mean different things by "preferring" > ASNs. (This is a pretty generic problem with ASNs in ALTO.) > = > ISPs generally peer with a limited number of ASNs, and reach IPs > "owned" by other ASNs through routes from the ASNs they directly peer > with. > = > What actually causes an ISP to "prefer" a set of IPs is knowing that > they will use a route to them through a particular AS they peer with. > This is _not_ the same as which AS "owns" the IP in question. (Nor is > "owned by an AS" necessarily a meaningful statement for a CIDR block.) > = > BGP looking-glass views show which ASNs "originate" routes to a > CIDR block. It is not particularly unusual to find more than one AS > "originating" such a route. Thus, looking-glass results cannot assure > that the route a packet will actually follow to reach an IP address > _ever_ passes through a particular AS. > = > Looking-glass views _will_ generally show "holes" punched in CIDR > blocks "owned" by one AS for the purpose of balancing traffic to a > multihomed customer of that AS (even though it may be that _none_ of > the traffic will actually pass through the "owner" AS). But looking- > glass views tend to contain routes that are never seen by routers > not "near the backbone". > = > The routing view which actually matters is the view of the ISP > router which dispatches the particular packet at a peering point. > Thus, IMHO, the ISP should usually be the provider of the mapping of > IPs to ASNs. > = > (This mapping may change several times per second when routes > "flap", but that's a balancing act the ISP is best able to attempt.) > = > In any case, if ALTO provides ASN "preferences" at all we should > provide a mechanism for the ISP to perform mapping of IP to ASN. > (IMHO, at least...) > = > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Oct 28 21:05:56 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F693A689C; Tue, 28 Oct 2008 21:05:56 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCF13A6A95 for ; Tue, 28 Oct 2008 21:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 a9BFKSp8tfGa for ; Tue, 28 Oct 2008 21:05:53 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9D8B93A67FB for ; Tue, 28 Oct 2008 21:05:53 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9T45lIT011548; Wed, 29 Oct 2008 00:05:48 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9T45lai024465; Wed, 29 Oct 2008 00:05:47 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m9T45iOH024460; Wed, 29 Oct 2008 00:05:45 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 29 Oct 2008 00:05:44 -0400 (EDT) From: Salman Abdul Baset To: Reinaldo Penno In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-824023566-1225253147=:24142" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: p2pi@ietf.org, "Woundy, Richard" Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org 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-824023566-1225253147=:24142 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Mapping IP addresses to AS numbers by quering RIRs: http://www.bugest.net/software/aslookup/index-e.html -s On Tue, 28 Oct 2008, Reinaldo Penno wrote: > I agree with you Rich. Getting an accurate mapping of IP to 'owner' ASs is > not an easy task. Some people spent a lot of time on this. I did not know > this presentation. > > Here is a another very good reference: > > Towards an Accurate AS-Level Traceroute Tool > Zhuoqing Morley Mao Jennifer Rexford Jia Wang Randy H. Katz > UC Berkeley AT&T Labs­Research AT&T Labs­Research UC Berkeley > zmao@cs.berkeley.edu jrex@research.att.com jiawang@research.att.com > randy@cs.berkeley.edu > > In this paper they discuss in detail all the roadblocks to have a traceroute > tool that maps IP to ASs. > > Thanks, > > Reinaldo > > > On 10/28/08 4:00 PM, "Woundy, Richard" > wrote: > >>> The routing view which actually matters is the view of the ISP router >> which dispatches the particular packet at a peering point. Thus, IMHO, >> the ISP should usually be the provider of the mapping of IPs to ASNs. >> >> Before this email, my opinion was that if an ISP wanted to include >> ASN(s) in the policy to be returned by the ALTO service, then the ISP >> should also supply the IP prefix to ASN mappings, so that the combined >> ALTO service guidance came from a consistent information source (the >> ISP). But I didn't have a strong opinion against using a looking glass >> server instead for the IP-to-ASN mappings. >> >> If I understood John correctly, the looking glass server's view of >> IP-to-ASN mappings may depend on the server's location in the Internet >> topology, and that view may not be equivalent to the view of the ISP >> providing the ALTO service. >> >> Here is one example: Within one ISP's backbone, there may be a set of >> specific IPv4 prefixes coming from many origin AS's. Within another >> ISP's backbone, these specific prefixes may have been replaced (and >> subsumed) by a single aggregate prefix with a different origin AS (e.g. >> the first backbone). Therefore, the looking glass servers for the first >> and second backbones would differ on the correct origin AS with respect >> to this aggregated prefix. >> >> Here is a relevant RIPE presentation (from 2003) in which they faced >> similar problems with reporting ASNs in traceroutes: >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra >> ceroutes.pdf. In the scenario of the RIPE presentation, the route >> information in the Internet Routing Registries and in the global BGP >> routes were often at odds with one another; slides 8, 10, and 11 >> describe some interesting cases that relate to this discussion about >> looking glasses. >> >> John, in short, I think you make a very good point. >> >> -- Rich >> >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >> John Leslie >> Sent: Tuesday, October 28, 2008 1:23 PM >> To: Stanislav Shalunov >> Cc: p2pi@ietf.org >> Subject: Re: [p2pi] ALTO Information Export Service >> >> Stanislav Shalunov wrote: >>> >>> We put together a first iteration of a very simple ALTO solution >>> draft. We hope this will be useful as an example point in the >>> solutions space and thus allow to refine the requirements document and >> >>> the problem statement. >>> >>> >> http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx >> t >> ] ... >> ] 7. Mapping IPs to ASNs >> >> I expect ISPs will sometimes mean different things by "preferring" >> ASNs. (This is a pretty generic problem with ASNs in ALTO.) >> >> ISPs generally peer with a limited number of ASNs, and reach IPs >> "owned" by other ASNs through routes from the ASNs they directly peer >> with. >> >> What actually causes an ISP to "prefer" a set of IPs is knowing that >> they will use a route to them through a particular AS they peer with. >> This is _not_ the same as which AS "owns" the IP in question. (Nor is >> "owned by an AS" necessarily a meaningful statement for a CIDR block.) >> >> BGP looking-glass views show which ASNs "originate" routes to a >> CIDR block. It is not particularly unusual to find more than one AS >> "originating" such a route. Thus, looking-glass results cannot assure >> that the route a packet will actually follow to reach an IP address >> _ever_ passes through a particular AS. >> >> Looking-glass views _will_ generally show "holes" punched in CIDR >> blocks "owned" by one AS for the purpose of balancing traffic to a >> multihomed customer of that AS (even though it may be that _none_ of >> the traffic will actually pass through the "owner" AS). But looking- >> glass views tend to contain routes that are never seen by routers >> not "near the backbone". >> >> The routing view which actually matters is the view of the ISP >> router which dispatches the particular packet at a peering point. >> Thus, IMHO, the ISP should usually be the provider of the mapping of >> IPs to ASNs. >> >> (This mapping may change several times per second when routes >> "flap", but that's a balancing act the ISP is best able to attempt.) >> >> In any case, if ALTO provides ASN "preferences" at all we should >> provide a mechanism for the ISP to perform mapping of IP to ASN. >> (IMHO, at least...) >> >> -- >> John Leslie >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > > ---559023410-824023566-1225253147=:24142 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ---559023410-824023566-1225253147=:24142-- From p2pi-bounces@ietf.org Tue Oct 28 21:23:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB993A67FB; Tue, 28 Oct 2008 21:23:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235293A67E2 for ; Tue, 28 Oct 2008 21:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sIG0K4Z+oq-o for ; Tue, 28 Oct 2008 21:23:23 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BA4A53A67C1 for ; Tue, 28 Oct 2008 21:23:12 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 28 Oct 2008 21:23:23 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 21:22:42 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 21:22:41 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 00:22:40 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Oct 2008 04:22:39 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 28 Oct 2008 21:22:30 -0700 From: Reinaldo Penno To: Salman Abdul Baset Message-ID: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack5ffTyF9hrongj1EmiGkePvBGXag== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 29 Oct 2008 04:22:40.0752 (UTC) FILETIME=[FB5B2700:01C9397D] Cc: p2pi@ietf.org, "Woundy, Richard" Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Interesting. How do I interpret its results? For example, first IP addresses I put. ./aslookup -r 200.200.200.1 | more Who owns this prefix? Is it AS7132 (SBC), AS4230(Embratel) or AS28513(Telmex)? 751:route: 200.200.200.0/24 descr: cccoe.k12.ca.us origin: AS7132 mnt-by: MAINT-AS7132 changed: backbone@sbc.com 20030317 source: RADB route: 200.200.0.0/16 descr: EMBRATEL BRAZIL origin: AS4230 remarks: ------------------------------------------------- remarks: For SECURITY issues, please send messages only to remarks: abuse@embratel.net.br remarks: ------------------------------------------------- notify: netadmin@embratel.net.br mnt-by: MAINT-EMBRATEL changed: netadmin@embratel.net.br 20070222 source: NTTCOM route: 200.200.0.0/16 descr: EMBRATEL origin: AS28513 mnt-by: TELMEX-MNT changed: noc@reduno.com.mx 20081014 source: LEVEL3 DATA Type C Complete On 10/28/08 9:05 PM, "Salman Abdul Baset" wrote: > Mapping IP addresses to AS numbers by quering RIRs: > http://www.bugest.net/software/aslookup/index-e.html > = > -s > = > On Tue, 28 Oct 2008, Reinaldo Penno wrote: > = >> I agree with you Rich. Getting an accurate mapping of IP to 'owner' ASs = is >> not an easy task. Some people spent a lot of time on this. I did not know >> this presentation. >> = >> Here is a another very good reference: >> = >> Towards an Accurate AS-Level Traceroute Tool >> Zhuoqing Morley Mao Jennifer Rexford Jia Wang Randy H. Katz >> UC Berkeley AT&T Labs=ADResearch AT&T Labs=ADResearch UC Berkeley >> zmao@cs.berkeley.edu jrex@research.att.com jiawang@research.att.com >> randy@cs.berkeley.edu >> = >> In this paper they discuss in detail all the roadblocks to have a tracer= oute >> tool that maps IP to ASs. >> = >> Thanks, >> = >> Reinaldo >> = >> = >> On 10/28/08 4:00 PM, "Woundy, Richard" >> wrote: >> = >>>> The routing view which actually matters is the view of the ISP router >>> which dispatches the particular packet at a peering point. Thus, IMHO, >>> the ISP should usually be the provider of the mapping of IPs to ASNs. >>> = >>> Before this email, my opinion was that if an ISP wanted to include >>> ASN(s) in the policy to be returned by the ALTO service, then the ISP >>> should also supply the IP prefix to ASN mappings, so that the combined >>> ALTO service guidance came from a consistent information source (the >>> ISP). But I didn't have a strong opinion against using a looking glass >>> server instead for the IP-to-ASN mappings. >>> = >>> If I understood John correctly, the looking glass server's view of >>> IP-to-ASN mappings may depend on the server's location in the Internet >>> topology, and that view may not be equivalent to the view of the ISP >>> providing the ALTO service. >>> = >>> Here is one example: Within one ISP's backbone, there may be a set of >>> specific IPv4 prefixes coming from many origin AS's. Within another >>> ISP's backbone, these specific prefixes may have been replaced (and >>> subsumed) by a single aggregate prefix with a different origin AS (e.g. >>> the first backbone). Therefore, the looking glass servers for the first >>> and second backbones would differ on the correct origin AS with respect >>> to this aggregated prefix. >>> = >>> Here is a relevant RIPE presentation (from 2003) in which they faced >>> similar problems with reporting ASNs in traceroutes: >>> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra >>> ceroutes.pdf. In the scenario of the RIPE presentation, the route >>> information in the Internet Routing Registries and in the global BGP >>> routes were often at odds with one another; slides 8, 10, and 11 >>> describe some interesting cases that relate to this discussion about >>> looking glasses. >>> = >>> John, in short, I think you make a very good point. >>> = >>> -- Rich >>> = >>> -----Original Message----- >>> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >>> John Leslie >>> Sent: Tuesday, October 28, 2008 1:23 PM >>> To: Stanislav Shalunov >>> Cc: p2pi@ietf.org >>> Subject: Re: [p2pi] ALTO Information Export Service >>> = >>> Stanislav Shalunov wrote: >>>> = >>>> We put together a first iteration of a very simple ALTO solution >>>> draft. We hope this will be useful as an example point in the >>>> solutions space and thus allow to refine the requirements document and >>> = >>>> the problem statement. >>>> = >>>> = >>> http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx >>> t >>> ] ... >>> ] 7. Mapping IPs to ASNs >>> = >>> I expect ISPs will sometimes mean different things by "preferring" >>> ASNs. (This is a pretty generic problem with ASNs in ALTO.) >>> = >>> ISPs generally peer with a limited number of ASNs, and reach IPs >>> "owned" by other ASNs through routes from the ASNs they directly peer >>> with. >>> = >>> What actually causes an ISP to "prefer" a set of IPs is knowing that >>> they will use a route to them through a particular AS they peer with. >>> This is _not_ the same as which AS "owns" the IP in question. (Nor is >>> "owned by an AS" necessarily a meaningful statement for a CIDR block.) >>> = >>> BGP looking-glass views show which ASNs "originate" routes to a >>> CIDR block. It is not particularly unusual to find more than one AS >>> "originating" such a route. Thus, looking-glass results cannot assure >>> that the route a packet will actually follow to reach an IP address >>> _ever_ passes through a particular AS. >>> = >>> Looking-glass views _will_ generally show "holes" punched in CIDR >>> blocks "owned" by one AS for the purpose of balancing traffic to a >>> multihomed customer of that AS (even though it may be that _none_ of >>> the traffic will actually pass through the "owner" AS). But looking- >>> glass views tend to contain routes that are never seen by routers >>> not "near the backbone". >>> = >>> The routing view which actually matters is the view of the ISP >>> router which dispatches the particular packet at a peering point. >>> Thus, IMHO, the ISP should usually be the provider of the mapping of >>> IPs to ASNs. >>> = >>> (This mapping may change several times per second when routes >>> "flap", but that's a balancing act the ISP is best able to attempt.) >>> = >>> In any case, if ALTO provides ASN "preferences" at all we should >>> provide a mechanism for the ISP to perform mapping of IP to ASN. >>> (IMHO, at least...) >>> = >>> -- >>> John Leslie >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> = >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> = >> = _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 06:55:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2235528C0E8; Wed, 29 Oct 2008 06:55:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD803A6D0F for ; Wed, 29 Oct 2008 06:55:19 -0700 (PDT) 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 5PUDg6csZ5ED for ; Wed, 29 Oct 2008 06:55:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 46E603A6AAF for ; Wed, 29 Oct 2008 06:55:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TDtBo03643; Wed, 29 Oct 2008 14:55:11 +0100 (CET) Received: from [192.168.0.100] (ams3-vpn-dhcp4622.cisco.com [10.61.82.13]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TDtAG03604; Wed, 29 Oct 2008 14:55:10 +0100 (CET) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 29 Oct 2008 14:55:04 +0100 From: stefano previdi To: "Woundy, Richard" , John Leslie , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack5IfFnziqzqTA+S7a0lPNtm6F0ogADRzeAACe40Jw= In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6028963B5@PACDCEXCMB06.cable.comcast.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: "Woundy, Richard" > >> The routing view which actually matters is the view of the ISP router >> which dispatches the particular packet at a peering point. Thus, IMHO, >> the ISP should usually be the provider of the mapping of IPs to ASNs. > > Before this email, my opinion was that if an ISP wanted to include > ASN(s) in the policy to be returned by the ALTO service, then the ISP > should also supply the IP prefix to ASN mappings, so that the combined > ALTO service guidance came from a consistent information source (the > ISP). But I didn't have a strong opinion against using a looking glass > server instead for the IP-to-ASN mappings. > > If I understood John correctly, the looking glass server's view of > IP-to-ASN mappings may depend on the server's location in the Internet > topology, and that view may not be equivalent to the view of the ISP > providing the ALTO service. that is right. BGP is a path vector protocol which means that the visibility any router gets from its BGP peers, correspond to the selection mechanisms those peers have done (vector-based protocols: first select best route, then advertise best route). This is valid for any looking glass server as well as for any ALTO server, which implies that any preference scheme may vary according to each SP location/pop where it is computed. s. > Here is one example: Within one ISP's backbone, there may be a set of > specific IPv4 prefixes coming from many origin AS's. Within another > ISP's backbone, these specific prefixes may have been replaced (and > subsumed) by a single aggregate prefix with a different origin AS (e.g. > the first backbone). Therefore, the looking glass servers for the first > and second backbones would differ on the correct origin AS with respect > to this aggregated prefix. > > Here is a relevant RIPE presentation (from 2003) in which they faced > similar problems with reporting ASNs in traceroutes: > http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra > ceroutes.pdf. In the scenario of the RIPE presentation, the route > information in the Internet Routing Registries and in the global BGP > routes were often at odds with one another; slides 8, 10, and 11 > describe some interesting cases that relate to this discussion about > looking glasses. > > John, in short, I think you make a very good point. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Tuesday, October 28, 2008 1:23 PM > To: Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO Information Export Service > > Stanislav Shalunov wrote: >> >> We put together a first iteration of a very simple ALTO solution >> draft. We hope this will be useful as an example point in the >> solutions space and thus allow to refine the requirements document and > >> the problem statement. >> >> > http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx > t > ] ... > ] 7. Mapping IPs to ASNs > > I expect ISPs will sometimes mean different things by "preferring" > ASNs. (This is a pretty generic problem with ASNs in ALTO.) > > ISPs generally peer with a limited number of ASNs, and reach IPs > "owned" by other ASNs through routes from the ASNs they directly peer > with. > > What actually causes an ISP to "prefer" a set of IPs is knowing that > they will use a route to them through a particular AS they peer with. > This is _not_ the same as which AS "owns" the IP in question. (Nor is > "owned by an AS" necessarily a meaningful statement for a CIDR block.) > > BGP looking-glass views show which ASNs "originate" routes to a > CIDR block. It is not particularly unusual to find more than one AS > "originating" such a route. Thus, looking-glass results cannot assure > that the route a packet will actually follow to reach an IP address > _ever_ passes through a particular AS. > > Looking-glass views _will_ generally show "holes" punched in CIDR > blocks "owned" by one AS for the purpose of balancing traffic to a > multihomed customer of that AS (even though it may be that _none_ of > the traffic will actually pass through the "owner" AS). But looking- > glass views tend to contain routes that are never seen by routers > not "near the backbone". > > The routing view which actually matters is the view of the ISP > router which dispatches the particular packet at a peering point. > Thus, IMHO, the ISP should usually be the provider of the mapping of > IPs to ASNs. > > (This mapping may change several times per second when routes > "flap", but that's a balancing act the ISP is best able to attempt.) > > In any case, if ALTO provides ASN "preferences" at all we should > provide a mechanism for the ISP to perform mapping of IP to ASN. > (IMHO, at least...) > > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 08:23:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08713A6D3F; Wed, 29 Oct 2008 08:23:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACB93A6D3F for ; Wed, 29 Oct 2008 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 xL2kb7sZz6GI for ; Wed, 29 Oct 2008 08:23:37 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 87DA03A69F0 for ; Wed, 29 Oct 2008 08:23:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9DB8FE10ADA; Wed, 29 Oct 2008 11:23:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO2muK4GjcIp; Wed, 29 Oct 2008 11:23:16 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 5FDF1E10B1B; Wed, 29 Oct 2008 11:23:16 -0400 (EDT) Date: Wed, 29 Oct 2008 11:23:16 -0400 (EDT) From: Laird Popkin To: stefano previdi Message-ID: <1603497045.408271225293796368.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: Richard Woundy , p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Keep in mind that ASNs are just an option in ALTO (as we're discussing it so far), so even if the P2P network uses a public IP to ASN mapping database, the ISP can provide their own IP prefix guidance without referencing ASNs if they care to. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" To: "Richard Woundy" , "John Leslie" , "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Wednesday, October 29, 2008 9:55:04 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO Information Export Service > From: "Woundy, Richard" > >> The routing view which actually matters is the view of the ISP router >> which dispatches the particular packet at a peering point. Thus, IMHO, >> the ISP should usually be the provider of the mapping of IPs to ASNs. > > Before this email, my opinion was that if an ISP wanted to include > ASN(s) in the policy to be returned by the ALTO service, then the ISP > should also supply the IP prefix to ASN mappings, so that the combined > ALTO service guidance came from a consistent information source (the > ISP). But I didn't have a strong opinion against using a looking glass > server instead for the IP-to-ASN mappings. > > If I understood John correctly, the looking glass server's view of > IP-to-ASN mappings may depend on the server's location in the Internet > topology, and that view may not be equivalent to the view of the ISP > providing the ALTO service. that is right. BGP is a path vector protocol which means that the visibility any router gets from its BGP peers, correspond to the selection mechanisms those peers have done (vector-based protocols: first select best route, then advertise best route). This is valid for any looking glass server as well as for any ALTO server, which implies that any preference scheme may vary according to each SP location/pop where it is computed. s. > Here is one example: Within one ISP's backbone, there may be a set of > specific IPv4 prefixes coming from many origin AS's. Within another > ISP's backbone, these specific prefixes may have been replaced (and > subsumed) by a single aggregate prefix with a different origin AS (e.g. > the first backbone). Therefore, the looking glass servers for the first > and second backbones would differ on the correct origin AS with respect > to this aggregated prefix. > > Here is a relevant RIPE presentation (from 2003) in which they faced > similar problems with reporting ASNs in traceroutes: > http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra > ceroutes.pdf. In the scenario of the RIPE presentation, the route > information in the Internet Routing Registries and in the global BGP > routes were often at odds with one another; slides 8, 10, and 11 > describe some interesting cases that relate to this discussion about > looking glasses. > > John, in short, I think you make a very good point. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Tuesday, October 28, 2008 1:23 PM > To: Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO Information Export Service > > Stanislav Shalunov wrote: >> >> We put together a first iteration of a very simple ALTO solution >> draft. We hope this will be useful as an example point in the >> solutions space and thus allow to refine the requirements document and > >> the problem statement. >> >> > http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx > t > ] ... > ] 7. Mapping IPs to ASNs > > I expect ISPs will sometimes mean different things by "preferring" > ASNs. (This is a pretty generic problem with ASNs in ALTO.) > > ISPs generally peer with a limited number of ASNs, and reach IPs > "owned" by other ASNs through routes from the ASNs they directly peer > with. > > What actually causes an ISP to "prefer" a set of IPs is knowing that > they will use a route to them through a particular AS they peer with. > This is _not_ the same as which AS "owns" the IP in question. (Nor is > "owned by an AS" necessarily a meaningful statement for a CIDR block.) > > BGP looking-glass views show which ASNs "originate" routes to a > CIDR block. It is not particularly unusual to find more than one AS > "originating" such a route. Thus, looking-glass results cannot assure > that the route a packet will actually follow to reach an IP address > _ever_ passes through a particular AS. > > Looking-glass views _will_ generally show "holes" punched in CIDR > blocks "owned" by one AS for the purpose of balancing traffic to a > multihomed customer of that AS (even though it may be that _none_ of > the traffic will actually pass through the "owner" AS). But looking- > glass views tend to contain routes that are never seen by routers > not "near the backbone". > > The routing view which actually matters is the view of the ISP > router which dispatches the particular packet at a peering point. > Thus, IMHO, the ISP should usually be the provider of the mapping of > IPs to ASNs. > > (This mapping may change several times per second when routes > "flap", but that's a balancing act the ISP is best able to attempt.) > > In any case, if ALTO provides ASN "preferences" at all we should > provide a mechanism for the ISP to perform mapping of IP to ASN. > (IMHO, at least...) > > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 08:33:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDDB3A68DB; Wed, 29 Oct 2008 08:33:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0A328C29F for ; Wed, 29 Oct 2008 08:33:16 -0700 (PDT) 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 TjaPvdVEKfpf for ; Wed, 29 Oct 2008 08:33:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 374103A687E for ; Wed, 29 Oct 2008 08:33:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TFX9W09822; Wed, 29 Oct 2008 16:33:09 +0100 (CET) Received: from [192.168.0.100] (ams3-vpn-dhcp4622.cisco.com [10.61.82.13]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TFX8G09809; Wed, 29 Oct 2008 16:33:08 +0100 (CET) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 29 Oct 2008 16:33:03 +0100 From: stefano previdi To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack526Gv4EZK9KXOEd2VNgAX8vOM8g== In-Reply-To: <1603497045.408271225293796368.JavaMail.root@dkny.pando.com> Mime-version: 1.0 Cc: Richard Woundy , p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: Laird Popkin > > Keep in mind that ASNs are just an option in ALTO (as we're discussing it so > far), so even if the P2P network uses a public IP to ASN mapping database, the > ISP can provide their own IP prefix guidance without referencing ASNs if they > care to. I agree. However, I also believe on the usefulness BGP can deliver in ranking preferences. The point to keep in mind is that BGP is location-dependent in terms of computation (which may not be the case for other routing protocols). s. > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "stefano previdi" > To: "Richard Woundy" , "John Leslie" > , "Stanislav Shalunov" > Cc: p2pi@ietf.org > Sent: Wednesday, October 29, 2008 9:55:04 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO Information Export Service > >> From: "Woundy, Richard" >> >>> The routing view which actually matters is the view of the ISP router >>> which dispatches the particular packet at a peering point. Thus, IMHO, >>> the ISP should usually be the provider of the mapping of IPs to ASNs. >> >> Before this email, my opinion was that if an ISP wanted to include >> ASN(s) in the policy to be returned by the ALTO service, then the ISP >> should also supply the IP prefix to ASN mappings, so that the combined >> ALTO service guidance came from a consistent information source (the >> ISP). But I didn't have a strong opinion against using a looking glass >> server instead for the IP-to-ASN mappings. >> >> If I understood John correctly, the looking glass server's view of >> IP-to-ASN mappings may depend on the server's location in the Internet >> topology, and that view may not be equivalent to the view of the ISP >> providing the ALTO service. > > that is right. BGP is a path vector protocol which means that the visibility > any router gets from its BGP peers, correspond to the selection mechanisms > those peers have done (vector-based protocols: first select best route, then > advertise best route). > > This is valid for any looking glass server as well as for any ALTO server, > which implies that any preference scheme may vary according to each SP > location/pop where it is computed. > > s. > >> Here is one example: Within one ISP's backbone, there may be a set of >> specific IPv4 prefixes coming from many origin AS's. Within another >> ISP's backbone, these specific prefixes may have been replaced (and >> subsumed) by a single aggregate prefix with a different origin AS (e.g. >> the first backbone). Therefore, the looking glass servers for the first >> and second backbones would differ on the correct origin AS with respect >> to this aggregated prefix. >> >> Here is a relevant RIPE presentation (from 2003) in which they faced >> similar problems with reporting ASNs in traceroutes: >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra >> ceroutes.pdf. In the scenario of the RIPE presentation, the route >> information in the Internet Routing Registries and in the global BGP >> routes were often at odds with one another; slides 8, 10, and 11 >> describe some interesting cases that relate to this discussion about >> looking glasses. >> >> John, in short, I think you make a very good point. >> >> -- Rich >> >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >> John Leslie >> Sent: Tuesday, October 28, 2008 1:23 PM >> To: Stanislav Shalunov >> Cc: p2pi@ietf.org >> Subject: Re: [p2pi] ALTO Information Export Service >> >> Stanislav Shalunov wrote: >>> >>> We put together a first iteration of a very simple ALTO solution >>> draft. We hope this will be useful as an example point in the >>> solutions space and thus allow to refine the requirements document and >> >>> the problem statement. >>> >>> >> http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx >> t >> ] ... >> ] 7. Mapping IPs to ASNs >> >> I expect ISPs will sometimes mean different things by "preferring" >> ASNs. (This is a pretty generic problem with ASNs in ALTO.) >> >> ISPs generally peer with a limited number of ASNs, and reach IPs >> "owned" by other ASNs through routes from the ASNs they directly peer >> with. >> >> What actually causes an ISP to "prefer" a set of IPs is knowing that >> they will use a route to them through a particular AS they peer with. >> This is _not_ the same as which AS "owns" the IP in question. (Nor is >> "owned by an AS" necessarily a meaningful statement for a CIDR block.) >> >> BGP looking-glass views show which ASNs "originate" routes to a >> CIDR block. It is not particularly unusual to find more than one AS >> "originating" such a route. Thus, looking-glass results cannot assure >> that the route a packet will actually follow to reach an IP address >> _ever_ passes through a particular AS. >> >> Looking-glass views _will_ generally show "holes" punched in CIDR >> blocks "owned" by one AS for the purpose of balancing traffic to a >> multihomed customer of that AS (even though it may be that _none_ of >> the traffic will actually pass through the "owner" AS). But looking- >> glass views tend to contain routes that are never seen by routers >> not "near the backbone". >> >> The routing view which actually matters is the view of the ISP >> router which dispatches the particular packet at a peering point. >> Thus, IMHO, the ISP should usually be the provider of the mapping of >> IPs to ASNs. >> >> (This mapping may change several times per second when routes >> "flap", but that's a balancing act the ISP is best able to attempt.) >> >> In any case, if ALTO provides ASN "preferences" at all we should >> provide a mechanism for the ISP to perform mapping of IP to ASN. >> (IMHO, at least...) >> >> -- >> John Leslie >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 08:47:48 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46B33A69D2; Wed, 29 Oct 2008 08:47:48 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9A93A6D27 for ; Wed, 29 Oct 2008 08:47:47 -0700 (PDT) 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 gxi7dYP8lRjj for ; Wed, 29 Oct 2008 08:47:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id C55233A6894 for ; Wed, 29 Oct 2008 08:47:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F3C5333C31; Wed, 29 Oct 2008 11:47:44 -0400 (EDT) Date: Wed, 29 Oct 2008 11:47:44 -0400 From: John Leslie To: Laird Popkin Message-ID: <20081029154744.GF7530@verdi> References: <1603497045.408271225293796368.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1603497045.408271225293796368.JavaMail.root@dkny.pando.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Laird Popkin wrote: > > Keep in mind that ASNs are just an option in ALTO (as we're discussing > it so far), so even if the P2P network uses a public IP to ASN mapping > database, the ISP can provide their own IP prefix guidance without > referencing ASNs if they care to. Indeed they can -- (by omitting any ASN guidance at all). But then, why include the option? The advantage of including an ASN option, IMHO, is that a policy can be stated in a reasonably static manner using ASNs -- provided that the meaning of those ASNs is clearly "where my routers will forward packets". This avoids having to frequently update policy as routing tables change and having to state policy for hundreds of thousands of CIDR blocks. A downside is that ALTO clients may lack up-to-the-minute routing information when mapping IPs to ASNs. That, IMHO, is something to work on when the ALTO WG is formed. Several "good-enough" approaches suggest themselves... But if clients are encouraged to use mapping quite unrelated to the actual routing, then policy stated in ASNs is actively misleading. I would much prefer not to _design_ misleading policy into ALTO. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 09:47:42 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DD13A681B; Wed, 29 Oct 2008 09:47:42 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF5E3A681B for ; Wed, 29 Oct 2008 09:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 pae+oDRk5VtH for ; Wed, 29 Oct 2008 09:47:39 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 618FF3A635F for ; Wed, 29 Oct 2008 09:47:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5E850E10B1A; Wed, 29 Oct 2008 12:47:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+kPzl6l9mYv; Wed, 29 Oct 2008 12:47:19 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id E4289E10B10; Wed, 29 Oct 2008 12:47:19 -0400 (EDT) Date: Wed, 29 Oct 2008 12:47:19 -0400 (EDT) From: Laird Popkin To: John Leslie Message-ID: <1901116948.409151225298839875.JavaMail.root@dkny.pando.com> In-Reply-To: <20081029154744.GF7530@verdi> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree with your analysis, up until the last paragraph. I don't understand why you say that "policy stated in ASNs is actively misleading" though. Keep in mind that ALTO helps p2p networks find good endpoints, not good routes - that's done by BGP, OSPF, etc., when actually exchanging data. That is, a p2p network knows that it can exchange data between a addresses within (to make up an example) AT&T NYC and Verizon NYC, but it can't control the actual route that the data flows through. Of course, selecting endpoints that have cheap routes between them makes it likely that those cheap routes are actually used, but that's more a matter of the lower layers working properly than anything ALTO allows ISPs to directly express. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Laird Popkin" Cc: p2pi@ietf.org Sent: Wednesday, October 29, 2008 11:47:44 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO Information Export Service Laird Popkin wrote: > > Keep in mind that ASNs are just an option in ALTO (as we're discussing > it so far), so even if the P2P network uses a public IP to ASN mapping > database, the ISP can provide their own IP prefix guidance without > referencing ASNs if they care to. Indeed they can -- (by omitting any ASN guidance at all). But then, why include the option? The advantage of including an ASN option, IMHO, is that a policy can be stated in a reasonably static manner using ASNs -- provided that the meaning of those ASNs is clearly "where my routers will forward packets". This avoids having to frequently update policy as routing tables change and having to state policy for hundreds of thousands of CIDR blocks. A downside is that ALTO clients may lack up-to-the-minute routing information when mapping IPs to ASNs. That, IMHO, is something to work on when the ALTO WG is formed. Several "good-enough" approaches suggest themselves... But if clients are encouraged to use mapping quite unrelated to the actual routing, then policy stated in ASNs is actively misleading. I would much prefer not to _design_ misleading policy into ALTO. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 09:47:57 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87CC28C3A2; Wed, 29 Oct 2008 09:47:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68ED28C3B2 for ; Wed, 29 Oct 2008 09:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IqRHbLmYpOAa for ; Wed, 29 Oct 2008 09:47:55 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 749EA28C3A2 for ; Wed, 29 Oct 2008 09:47:53 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:47:51 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:47:51 +0100 Received: from [10.229.8.94] ([10.229.8.94]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:47:39 +0100 Message-ID: <490893A5.4000705@telecomitalia.it> Date: Wed, 29 Oct 2008 17:47:33 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "p2pi@ietf.org" References: <49089104.2010406@telecomitalia.it> In-Reply-To: <49089104.2010406@telecomitalia.it> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 29 Oct 2008 16:47:39.0124 (UTC) FILETIME=[0DA97340:01C939E6] Subject: Re: [p2pi] Agenda requests for Minneapolis X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302431668==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1302431668== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040204040104080405050704" This is a cryptographically signed message in MIME format. --------------ms040204040104080405050704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Of course the session is confirmed for _Tuesday_, not Thursday. My bad. Enrico Enrico Marocco wrote: > The ALTO session for Minneapolis is confirmed for Thu afternoon also on > the "final" agenda (which, as usual, is never really final). If you want > to request a slot, please send a private message to me and Vijay > indicating the subject of the presentation and how much time you think > will be needed. > > Factors considered in allocating slots will include how much attention > the subject has received on the list, whether there is a draft > associated to the presentation and whether the session will be a BoF or > a WG meeting. --------------ms040204040104080405050704 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjkxNjQ3MzNaMCMG CSqGSIb3DQEJBDEWBBQ2YfERsE5AmS+9E/WfsassEn5oETBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBADk4r0TioEQi nNviK6IsluLvp9h7MUtj3WmV8fkVxRvnDwWu/FoGFeOmiy/i17ELiWZzWhVAapgFI4hWzouO tI/fCO8kxI/breVHtMa9Twq4lYDTgdzrYbZKCHw/kpsf6zHToGL6bRMnY/zoWfF/PU1NzY5f UiR9H0gdUMCiDPpYx5IxCSoLM4Di9BQT7vqyXYZvERicC0QGKI7Lu1t/O8irpWQzfLbEkWMI FfQHqozxcIkArVV73O7Z9u2LEpsx6u2IywObfn66b4QPZylDA5kdmfwE03M5eSFxG8JHAK6W zNEXYeClL4UOps5E/rn/Q5iDAwcrLOx9H4WCgSk4sAoAAAAAAAA= --------------ms040204040104080405050704-- --===============1302431668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1302431668==-- From p2pi-bounces@ietf.org Wed Oct 29 09:47:57 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1BF28C3BA; Wed, 29 Oct 2008 09:47:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527BE28C392 for ; Wed, 29 Oct 2008 09:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CPnDzSOROv8P for ; Wed, 29 Oct 2008 09:47:55 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 1C2D928C2CA for ; Wed, 29 Oct 2008 09:47:54 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:36:27 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:36:27 +0100 Received: from [10.229.8.94] ([10.229.8.94]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:36:26 +0100 Message-ID: <49089104.2010406@telecomitalia.it> Date: Wed, 29 Oct 2008 17:36:20 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "p2pi@ietf.org" X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 29 Oct 2008 16:36:26.0331 (UTC) FILETIME=[7CA562B0:01C939E4] Subject: [p2pi] Agenda requests for Minneapolis X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886743646==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1886743646== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080801060406060102040308" This is a cryptographically signed message in MIME format. --------------ms080801060406060102040308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The ALTO session for Minneapolis is confirmed for Thu afternoon also on the "final" agenda (which, as usual, is never really final). If you want to request a slot, please send a private message to me and Vijay indicating the subject of the presentation and how much time you think will be needed. Factors considered in allocating slots will include how much attention the subject has received on the list, whether there is a draft associated to the presentation and whether the session will be a BoF or a WG meeting. -- Ciao, Enrico --------------ms080801060406060102040308 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjkxNjM2MjBaMCMG CSqGSIb3DQEJBDEWBBQTJTalLoPZ2oQOTNxflHe0Wa24DzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABFy454aXHzz J93CnnegCVJ+iMdsZtUuw6YzFUXjO/IbvVwSoy/1jbvIGKPqTQVzjssK6ZoQYyeTxjVrX03P +rjQMs1vAenCEyWx74d72vz/rx8pmY4SbC0PTSUi5EJFzUE10quBFbXgLa/4YtFWc8Rh7i94 YZPZhp8tP8pfQnQoDPqYzDpneExtSAlG9ZPiyWGdgXdWdtzkMasQeyM3AoQiFoV5oeZDT/UX tjz/XhBki4+l8Y/2RSJtWWPFN8M/NMoMo/vJxPFFSPZVTVG7bonkfsz1IN6TlbGk89j93I+w MfWBfCuXM8J0SYM9kjfsSYCdNyIyzbEN1VJk7WPE6aYAAAAAAAA= --------------ms080801060406060102040308-- --===============1886743646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --===============1886743646==-- From p2pi-bounces@ietf.org Wed Oct 29 10:19:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EDD3A6A37; Wed, 29 Oct 2008 10:19:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C448D3A6B08 for ; Wed, 29 Oct 2008 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mm3LpYrbsN-B for ; Wed, 29 Oct 2008 10:18:59 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id CF5B53A6A37 for ; Wed, 29 Oct 2008 10:18:57 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 29 Oct 2008 10:18:58 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 10:16:25 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 10:16:25 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 13:16:15 -0400 Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Oct 2008 17:08:51 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 29 Oct 2008 10:08:42 -0700 From: Reinaldo Penno To: Laird Popkin , John Leslie Message-ID: Thread-Topic: [p2pi] ALTO Information Export Service Thread-Index: Ack56P5lRuaDvvto+06trRwyXzCANw== In-Reply-To: <1901116948.409151225298839875.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 29 Oct 2008 17:16:15.0172 (UTC) FILETIME=[0C819840:01C939EA] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org If you say "prefer this ASN" (since you are implicitly or explicitly for that matter) assuming that prefix 1.1.1/24 is hosted in that ASN but is actually not, then is misleading, yes? On 10/29/08 9:47 AM, "Laird Popkin" wrote: > I agree with your analysis, up until the last paragraph. > > I don't understand why you say that "policy stated in ASNs is actively > misleading" though. Keep in mind that ALTO helps p2p networks find good > endpoints, not good routes - that's done by BGP, OSPF, etc., when actually > exchanging data. That is, a p2p network knows that it can exchange data > between a addresses within (to make up an example) AT&T NYC and Verizon NYC, > but it can't control the actual route that the data flows through. Of course, > selecting endpoints that have cheap routes between them makes it likely that > those cheap routes are actually used, but that's more a matter of the lower > layers working properly than anything ALTO allows ISPs to directly express. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "John Leslie" > To: "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Wednesday, October 29, 2008 11:47:44 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO Information Export Service > > Laird Popkin wrote: >> >> Keep in mind that ASNs are just an option in ALTO (as we're discussing >> it so far), so even if the P2P network uses a public IP to ASN mapping >> database, the ISP can provide their own IP prefix guidance without >> referencing ASNs if they care to. > > Indeed they can -- (by omitting any ASN guidance at all). > > But then, why include the option? > > The advantage of including an ASN option, IMHO, is that a policy can > be stated in a reasonably static manner using ASNs -- provided that the > meaning of those ASNs is clearly "where my routers will forward packets". > > This avoids having to frequently update policy as routing tables change > and having to state policy for hundreds of thousands of CIDR blocks. > > A downside is that ALTO clients may lack up-to-the-minute routing > information when mapping IPs to ASNs. That, IMHO, is something to work > on when the ALTO WG is formed. Several "good-enough" approaches suggest > themselves... > > But if clients are encouraged to use mapping quite unrelated to the > actual routing, then policy stated in ASNs is actively misleading. I > would much prefer not to _design_ misleading policy into ALTO. > > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 10:56:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AE73A680C; Wed, 29 Oct 2008 10:56:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723113A680C for ; Wed, 29 Oct 2008 10:56:39 -0700 (PDT) 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 voAwh9EPPJwc for ; Wed, 29 Oct 2008 10:56:38 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 8130C3A6405 for ; Wed, 29 Oct 2008 10:56:38 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9230C33C33; Wed, 29 Oct 2008 13:56:30 -0400 (EDT) Date: Wed, 29 Oct 2008 13:56:30 -0400 From: John Leslie To: Reinaldo Penno Message-ID: <20081029175630.GH7530@verdi> References: <1901116948.409151225298839875.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Reinaldo Penno wrote: > On 10/29/08 9:47 AM, "Laird Popkin" wrote: > >> I don't understand why you say that "policy stated in ASNs is actively >> misleading" though. Keep in mind that ALTO helps p2p networks find good >> endpoints, not good routes - that's done by BGP, OSPF, etc., when >> actually exchanging data. So far as I know, ALTO is completely unrelated to "finding good routes" (which, BTW, is an issue possibly worth pursuing for multihomed users). While we hope that ALTO will help "find good endpoints", we're talking about a (small) piece of ALTO only loosely related to that -- ISP policy. >> selecting endpoints that have cheap routes between them makes it likely >> that those cheap routes are actually used, but that's more a matter of >> the lower layers working properly ... which is mostly the responsibility of the ISP... >> than anything ALTO allows ISPs to directly express. It's premature, IMHO, to talk of what ALTO "allows". > If you say "prefer this ASN" (since you are implicitly or explicitly for > that matter) assuming that prefix 1.1.1/24 is hosted in that ASN but is > actually not, then is misleading, yes? Any case where the publisher of information assumes one meaning while the user assumes a different one, I would call "misleading". Reinaldo raises an issue -- whether an ISP might want to express an opinion on whether CIDR blocks served by a particular AS are better or worse than "average". I must admit (as an ISP) that I would not. But perhaps some ISP might -- and if so, they should be able to list list opinions about ASNs separately from their own routing preferences. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Oct 29 13:10:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950753A69D4; Wed, 29 Oct 2008 13:10:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34E63A6AC9 for ; Wed, 29 Oct 2008 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] 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 MxVd6hIvZe-l for ; Wed, 29 Oct 2008 13:10:26 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 9810C3A6ACF for ; Wed, 29 Oct 2008 13:10:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id BB526E10C1C; Wed, 29 Oct 2008 16:10:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl-bhzto6pXG; Wed, 29 Oct 2008 16:10:20 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 42B5EE10B39; Wed, 29 Oct 2008 16:10:20 -0400 (EDT) Date: Wed, 29 Oct 2008 16:10:20 -0400 (EDT) From: Laird Popkin To: John Leslie Message-ID: <1489995511.410311225311020089.JavaMail.root@dkny.pando.com> In-Reply-To: <1704010086.410291225310002807.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.77] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO Information Export Service X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I suspect that we're in "violent agreement". Yes, ALTO can't "find good routes". But there is a relationship between ALTO and routing in an indirect sense - the goal of ALTO is to help applications "find peers that the ISP can probably find better routes to than random peers". - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Reinaldo Penno" Cc: "Laird Popkin" , p2pi@ietf.org Sent: Wednesday, October 29, 2008 1:56:30 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO Information Export Service Reinaldo Penno wrote: > On 10/29/08 9:47 AM, "Laird Popkin" wrote: > >> I don't understand why you say that "policy stated in ASNs is actively >> misleading" though. Keep in mind that ALTO helps p2p networks find good >> endpoints, not good routes - that's done by BGP, OSPF, etc., when >> actually exchanging data. So far as I know, ALTO is completely unrelated to "finding good routes" (which, BTW, is an issue possibly worth pursuing for multihomed users). While we hope that ALTO will help "find good endpoints", we're talking about a (small) piece of ALTO only loosely related to that -- ISP policy. >> selecting endpoints that have cheap routes between them makes it likely >> that those cheap routes are actually used, but that's more a matter of >> the lower layers working properly ... which is mostly the responsibility of the ISP... >> than anything ALTO allows ISPs to directly express. It's premature, IMHO, to talk of what ALTO "allows". > If you say "prefer this ASN" (since you are implicitly or explicitly for > that matter) assuming that prefix 1.1.1/24 is hosted in that ASN but is > actually not, then is misleading, yes? Any case where the publisher of information assumes one meaning while the user assumes a different one, I would call "misleading". Reinaldo raises an issue -- whether an ISP might want to express an opinion on whether CIDR blocks served by a particular AS are better or worse than "average". I must admit (as an ISP) that I would not. But perhaps some ISP might -- and if so, they should be able to list list opinions about ASNs separately from their own routing preferences. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi