From p2pi-bounces@ietf.org Wed Jul 2 21:37: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 E2C483A683B; Wed, 2 Jul 2008 21:37: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 C1E5C3A683B for ; Wed, 2 Jul 2008 21:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=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 tE++C0QuoRTI for ; Wed, 2 Jul 2008 21:37:52 -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 326D23A680D for ; Wed, 2 Jul 2008 21:37:52 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so736835wfd.31 for ; Wed, 02 Jul 2008 21:38:01 -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 :content-transfer-encoding:content-disposition:references; bh=nE3wbduVrakjmKN/t3Oc8pwX+p0lOsPCPxo3u9THQAU=; b=VkTTmUt8rU+gPOoVrMQQSdxd0sgh3Z7RBfyhTVW+8b2IgZx9FEVxu3k2ItgEx6zYi+ 3D8dEgtbp1VtajfXfOzeStUkXoDPiitlnY2y8dc+fBxQn6svwZjRJ11rzCzq3Zoc8YK9 j9Be+bvLwUO2VliRLCPNw59Xm0SXUTan7Diyo= 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:content-transfer-encoding:content-disposition :references; b=PLX/jnulN7wiYMyiRdcrrVk+ybpvx672Ji1YD5OtQQs6h6esbiUJR7kgj8wRu/rsqt MrNkztUSuFwIGofbcsKcrEeWoZEyjIcq41g8U2IRojsKfm75cYHscp/8L3T3h0Gfv3mn 4XsBDbGQK8y8Gy4WzxK0SxD77Y7mfz0d7QjfM= Received: by 10.142.232.20 with SMTP id e20mr3386029wfh.109.1215059880849; Wed, 02 Jul 2008 21:38:00 -0700 (PDT) Received: by 10.142.164.4 with HTTP; Wed, 2 Jul 2008 21:38:00 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 00:38:00 -0400 From: "Anthony Bryan" To: "Enrico Marocco" , p2pi@ietf.org In-Reply-To: <486B3473.1060906@telecomitalia.it> MIME-Version: 1.0 Content-Disposition: inline References: <48695BE8.7020803@telecomitalia.it> <486B3473.1060906@telecomitalia.it> Subject: Re: [p2pi] New version of the problem statement 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 Wed, Jul 2, 2008 at 3:55 AM, Enrico Marocco wrote: > (I keep cc'ing Vijay, who is running the ALTO BoF with me and is > certainly interested in this) Sorry, I accidentally did not reply all before. > I think this is a very interesting discussion, I'd suggest to move it on > the ALTO mailing list (more info at http://alto.tilab.com). Ok, I've added it in & here's my initial message so people can follow along: Metalink is an XML format for describing downloads and how to get files. Usually this is lists of mirrors, way to get files over P2P, checksums, digital signatures, and other metadata. It's supported by about 30 applications, mostly download managers, web browsers, FTP clients, & P2P clients. See http://en.wikipedia.org/wiki/Metalink for more info. For instance, we allow for geographical location and priority for sources to be listed (like in section 3.5 of your document). ftp://ftp.example.com/example.ext ftp://ftp.example.net/example.ext http://example.com/example.ext http://example.net/example.ext http://example.org/example.ext.torrent > Anthony Bryan wrote: >> Great. ALTO seems like the type of thing we would include in >> Metalinks, it's all just information that clients might use. For >> instance, some P2P apps support exporting/importing .metalinks - where >> someone might want to share specific versions of a document. They >> could contain the hashes that identify those specific files and how to >> get them specifically from that person. > > Actually I was seeing it the other way around. ALTO is supposed to be a > service to help users select the best sources for a given content > according to their needs. It was initially thought for peer selection in > file-sharing application, but could be also used, for example, for > finding the closest mirror. > > If I understood it correctly, Metalink's information is related to the > content only (i.e. two different users accessing the same content use > identical Metalink files) while ALTO information is specific to the > querying user (i.e. two identical queries from users in different > locations generate different responses). What seems a reasonable > scenario is: 1. the user finds Metalink information for the content he > wants to get, 2. modifies such information according to his needs and > preferences (e.g. expands BitTorrent entries with current peers), 3. > sends such information to an ALTO service, together with his network > location information (his IP address or whatever kind of geolocation > information he is able to gather), 4. the ALTO service returns such > information with priority values modified according to user's network > location. Would this make sense? Yes, makes sense from what I understand. This is your domain so, if you think it fits the bill I will support it :) Most Metalink files are identical but some producers like MirrorBrain, which powers openSUSE downloads, create downloader specific Metalink files catered to a person's geographical location. http://www.mirrorbrain.org/ -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 4 08:08: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 5227B3A6B17; Fri, 4 Jul 2008 08:08: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 E5D3A3A69F9 for ; Fri, 4 Jul 2008 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 UH-r0GTh2C84 for ; Fri, 4 Jul 2008 08:08:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CF8403A6A0C for ; Fri, 4 Jul 2008 08:08:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 54B092C000358 for ; Fri, 4 Jul 2008 17:08:17 +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 5tThxFgCZjgk for ; Fri, 4 Jul 2008 17:08:17 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 389192C000305 for ; Fri, 4 Jul 2008 17:08:12 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.208]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 17:08:01 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Fri, 04 Jul 2008 17:08:01 +0200 Date: Fri, 4 Jul 2008 17:08:00 +0200 From: Sebastian Kiesel To: p2pi@ietf.org Message-ID: <20080704150800.GA32691@foo.nw.neclab.eu> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-OriginalArrivalTime: 04 Jul 2008 15:08:01.0309 (UTC) FILETIME=[C04684D0:01C8DDE7] Subject: [p2pi] [Internet-Drafts@ietf.org: I-D Action:draft-kiesel-alto-reqs-00.txt] 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 ----- Forwarded message from Internet-Drafts@ietf.org ----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-kiesel-alto-reqs-00.txt Date: Fri, 4 Jul 2008 07:30:01 -0700 (PDT) Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application-Layer Traffic Optimization (ALTO) Requirements Author(s) : S. Kiesel, et al. Filename : draft-kiesel-alto-reqs-00.txt Pages : 20 Date : 2008-07-04 Many Internet applications are used to access resources, such as server processes or pieces of information, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer filesharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one host out of several candidates for providing a desired resource. These recommendations shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to optimize performance (or Quality of Experience) in the application while minimizing resource consumption in the underlying network infrastructure. This document enumerates an initial set of requirements for ALTO and solicits feedback and discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiesel-alto-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 4 08:10: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 892253A685E; Fri, 4 Jul 2008 08:10: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 EE69F3A685E for ; Fri, 4 Jul 2008 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRutCrBkJ+Nu for ; Fri, 4 Jul 2008 08:10:06 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id 4592C3A6819 for ; Fri, 4 Jul 2008 08:10:06 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 17:10:12 +0200 Received: from GRFHUB705RM001.griffon.local ([10.19.3.69]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 17:10:12 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.19.3.70) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 4 Jul 2008 17:10:12 +0200 Message-ID: <486E3D3A.2070008@telecomitalia.it> Date: Fri, 4 Jul 2008 17:09:46 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Anthony Bryan References: <48695BE8.7020803@telecomitalia.it> <486B3473.1060906@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 04 Jul 2008 15:10:12.0676 (UTC) FILETIME=[0E938840:01C8DDE8] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement 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="===============0281760621==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0281760621== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902020505050506050900" --------------ms010902020505050506050900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony Bryan wrote: > Most Metalink files are identical but some producers like MirrorBrain, > which powers openSUSE downloads, create downloader specific Metalink > files catered to a person's geographical location. > > http://www.mirrorbrain.org/ The ApacheCon presentation is enlightening, it makes me wonder if anyone has ever thought about a generic Metalink customizer. Also, do you think that an extension for indicating peers sharing actual content pieces nested in ed2k and bittorrent URIs would fit in Metalink overall design? According to me, that would make it look pretty much like a possible solution for ALTO. -- Ciao, Enrico --------------ms010902020505050506050900 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDQxNTA5NDZaMCMG CSqGSIb3DQEJBDEWBBQrN0z8gX3jgjMUpvX1YsqOCscIETBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBACS6rdzC14j+ KD6WBsG8TLhDeN9N4NBUIeq1mgoBx8fmBpjkvBJKcmX3krHBVROmoOPzTZiR1U63ZWvkhXRW YZb8/feA84dEl47E48cNkio2nmUIqYxuJEywoZrd3rHWl+bBzx6a1qvrKkL/swnsKWeDl2Tu jp9aRFtFcw9/xXGKmYe4p0uqFSZTpIuX1rem5seeJ7GtEGLAlLeBD+RuuIm0Qhle0iRLXTz/ jKXWuwvdJME3sgK5Y6Ir970L71EYWoEpyASJrOW4kq+t6HqYVnwXRWGjZcTgS8xuUIQzgOQd S2k0e4lDvKLkavx7YTbN8FmyEjTdx3f4pCAkQcmMOn0AAAAAAAA= --------------ms010902020505050506050900-- --===============0281760621== 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 --===============0281760621==-- From p2pi-bounces@ietf.org Fri Jul 4 09:14: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 687333A6AB0; Fri, 4 Jul 2008 09:14: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 D8F093A6819 for ; Fri, 4 Jul 2008 09:14: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 RZvQ018beSlW for ; Fri, 4 Jul 2008 09:14:11 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id EFB253A6AB0 for ; Fri, 4 Jul 2008 09:14:10 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so753274pyg.24 for ; Fri, 04 Jul 2008 09:14:14 -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 :content-transfer-encoding:content-disposition:references; bh=0Kktl+19d1GVIPZNEyVxIt4WtwB4lbRvv7GRH6whYtQ=; b=Linqk82d9tGcMVvWtZbCbQHimF/2RrZWjQUzY87XVIbBI6YqbJTM6DuiF61eNoH4Y0 IEuAJsPCsi6oiee/UYwW5DNKTl2Y+f53bJ/resXb2oxWrEcGILmSAl5sdlLCGLIu/PIt l7haq6t69xTBxeXzCUuItG9x8YNm0gP455Z9c= 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:content-transfer-encoding:content-disposition :references; b=cd/lX6cwRSXTV1/dwyz6hM19K+wptDTu16Lbtnx4lt6xVSoYlzWN+rfYwH/lwnZM1E 5Mn0YDeQO67RpLF6EkGOgbKI1GNF9V2QkC6eh6/OZ8b6J+yU7+P6o1d4ItkI1h2GtdIJ sgs1RSbgVKlVOzVXTvMV6gWy/ggQ38FUR1Cb0= Received: by 10.142.177.7 with SMTP id z7mr298879wfe.88.1215188053817; Fri, 04 Jul 2008 09:14:13 -0700 (PDT) Received: by 10.142.164.4 with HTTP; Fri, 4 Jul 2008 09:14:13 -0700 (PDT) Message-ID: Date: Fri, 4 Jul 2008 12:14:13 -0400 From: "Anthony Bryan" To: "Enrico Marocco" In-Reply-To: <486E3D3A.2070008@telecomitalia.it> MIME-Version: 1.0 Content-Disposition: inline References: <48695BE8.7020803@telecomitalia.it> <486B3473.1060906@telecomitalia.it> <486E3D3A.2070008@telecomitalia.it> Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement 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 Fri, Jul 4, 2008 at 11:09 AM, Enrico Marocco wrote: > Anthony Bryan wrote: >> Most Metalink files are identical but some producers like MirrorBrain, >> which powers openSUSE downloads, create downloader specific Metalink >> files catered to a person's geographical location. >> >> http://www.mirrorbrain.org/ > > The ApacheCon presentation is enlightening, it makes me wonder if anyone > has ever thought about a generic Metalink customizer. Yes, it is a great presentation, isn't it? Those interested can find it here: http://www.mirrorbrain.org/presentations What do you mean by generic customizer? Do you mean besides country/priority information for resources? The current apps for creating Metalinks are listed at http://www.metalinker.org/implementation.html#generate . Besides MirrorBrain, there is Geo McFly which is an on the fly generator of metalinks based on client's geographical location. > Also, do you think that an extension for indicating peers sharing actual > content pieces nested in ed2k and bittorrent URIs would fit in Metalink > overall design? According to me, that would make it look pretty much > like a possible solution for ALTO. We crave extensions and I think that would fit. :) Currently, there are no Metalink clients that support ed2k but there are 5 that support BitTorrent. I would recommend consulting the authors of aria2 (command line, cross platform, open source), KGet (GUI, open source), and Retriever (GUI, cross platform, closed source). I'm guessing that because of the open source & responsive nature of the aria2 project, you could get a demo up & running in no time. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 4 10:19: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 AD0D03A6B79; Fri, 4 Jul 2008 10:19: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 A5F2D3A6B60 for ; Fri, 4 Jul 2008 10:19:50 -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 nSjAKa5ZpopK for ; Fri, 4 Jul 2008 10:19:49 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id DAE963A6B94 for ; Fri, 4 Jul 2008 10:19:48 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 19:19:54 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 19:19:53 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 4 Jul 2008 19:19:52 +0200 Message-ID: <486E5BB6.10804@telecomitalia.it> Date: Fri, 4 Jul 2008 19:19:50 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Anthony Bryan References: <48695BE8.7020803@telecomitalia.it> <486B3473.1060906@telecomitalia.it> <486E3D3A.2070008@telecomitalia.it> In-Reply-To: X-OriginalArrivalTime: 04 Jul 2008 17:19:53.0456 (UTC) FILETIME=[2C485700:01C8DDFA] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement 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="===============0344022674==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0344022674== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000100020405010402080507" --------------ms000100020405010402080507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony Bryan wrote: >> The ApacheCon presentation is enlightening, it makes me wonder if anyone >> has ever thought about a generic Metalink customizer. > > Yes, it is a great presentation, isn't it? Those interested can find > it here: http://www.mirrorbrain.org/presentations > > What do you mean by generic customizer? Do you mean besides > country/priority information for resources? I was thinking of sort of a service which arranges priorities in submitted Metalink files according to the location of the querying host, the finer granularity, the better. I guess this is something similar to what Geo McFly does. -- Ciao, Enrico --------------ms000100020405010402080507 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDQxNzE5NTBaMCMG CSqGSIb3DQEJBDEWBBTneyepXmw2jOFN5tj3di1HUPOPgDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAAYsXSH+EfgY bviqjvs78q1bvTk6pjL5ekXcRQgzpjnsWhSEoLq/VSwPp+5ItkC3tNL/ElE2LrfgJn4xQN5H aFfwvps1yVPuWvToRMloWEQPSPUXYcNbsiQlxFA/3i/uqGERurXgkPIMxwzyY2KupBgGFrsZ 7OGRGIhG30Wb/gvwHd1qsOtQTmgfnXSb55rSnMvCFaDqUSXESyr5FIt3humXgzqWS6o7PnP2 KFQWa538Q+nugxlsLOP3BAauBXzb4HuB3wySWK8jGxNJk4LlGzhC00UxkRJf0gKQRDMVFm1u PoRiEAoJshusERB5EN1uM3n+naW4GQyKU7JwGX56p1kAAAAAAAA= --------------ms000100020405010402080507-- --===============0344022674== 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 --===============0344022674==-- From p2pi-bounces@ietf.org Mon Jul 7 07:52: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 9937C3A6872; Mon, 7 Jul 2008 07:52: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 5848F3A68D7 for ; Mon, 7 Jul 2008 07:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vewtZYNneqJ7 for ; Mon, 7 Jul 2008 07:52:13 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id 279B33A6870 for ; Mon, 7 Jul 2008 07:52:12 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 16:52:17 +0200 Received: from grfhub703rm001.griffon.local ([10.19.3.10]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 16:52:17 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.19.3.42) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 7 Jul 2008 16:52:17 +0200 Message-ID: <48722D89.3050302@telecomitalia.it> Date: Mon, 7 Jul 2008 16:51:53 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "p2pi@ietf.org" X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 07 Jul 2008 14:52:17.0896 (UTC) FILETIME=[0D325E80:01C8E041] Subject: [p2pi] Agenda requests for 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="===============0400494101==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0400494101== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090909030402090101070608" --------------ms090909030402090101070608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The ALTO BoF is currently scheduled for Tuesday 28, 9:00-11:30. According to draft-narten-successful-bof-03, the agenda is being assembled focusing on the problem statement rather than on specific solution proposals. If you want to request a slot on the agenda for a presentation you think may help people better understand and scope the problem, please send a private email to Vijay and me. -- Ciao, Enrico --------------ms090909030402090101070608 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDcxNDUxNTNaMCMG CSqGSIb3DQEJBDEWBBSWd9/qzUEoQuImSx10pXVg5uuh1DBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAEK1hGdRuntq rYu0u1pk/gdzI+LyQe4YpU1RlwPTYnICMU64h2qX0emwuVEHvWzwBBURsAA51IjrX7yxsxgv U8HSKSlujwXmx01xR+3Ot/1EqhD00X1HRDtjq0RFkHnxYE4pIIETqpk7N051Y7kINunAtGU5 Ljbf7gkyIV/B5Oao/Kqy0mJVh03qKO+3D33doPDGj2pwxspbAdKgZ1KRE0CghH/Iv6OssxWY sEKd8khO8PuNkWVudvvNxreEZCLG0od0/AcHHSVOi3Fuzgzw2+4ROtJPVaygtiDynQEMI7bG bF6cUK8OXp6oiDfHqce0XIuuSwXYFc+C3emxfQwNoOUAAAAAAAA= --------------ms090909030402090101070608-- --===============0400494101== 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 --===============0400494101==-- From p2pi-bounces@ietf.org Mon Jul 7 23:33: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 DA82D3A6896; Mon, 7 Jul 2008 23:33: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 18F3B3A6939 for ; Mon, 7 Jul 2008 23:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.929, 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 YH+FXvbfxqN3 for ; Mon, 7 Jul 2008 23:33:29 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id DFBAA3A67E5 for ; Mon, 7 Jul 2008 23:33:28 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 08:33:36 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 08:33:36 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 8 Jul 2008 08:33:35 +0200 Message-ID: <48730A27.6000103@telecomitalia.it> Date: Tue, 8 Jul 2008 08:33:11 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Song Haibin References: <018401c8e0ab$380a2ec0$4c09a40a@china.huawei.com> In-Reply-To: <018401c8e0ab$380a2ec0$4c09a40a@china.huawei.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 08 Jul 2008 06:33:36.0088 (UTC) FILETIME=[8CD28D80:01C8E0C4] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Agenda requests for 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="===============1915032181==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1915032181== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010300070302000600010702" --------------ms010300070302000600010702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Song Haibin wrote: > Tuesday should be July 29. July 28 is Monday. Could you please clarify the > scheduled date for ALTO BoF? Yes, sorry, the ALTO BoF is actually scheduled for Tue Jul 29, 9.00-11.30. The final meeting agenda is now available at https://datatracker.ietf.org/meeting/72/agenda.html -- Ciao, Enrico --------------ms010300070302000600010702 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDgwNjMzMTFaMCMG CSqGSIb3DQEJBDEWBBQ4txMuu1waatBucbaRQ4oxfFJJkDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAAOtdLANBzae M9m6xf+EZbL+oe/dQICvaAM0cOaCoTEOQua7ndZG60odc+VS11vXXgHR3/2C7CoTnytFjXod KAxnMi9ui0MA7el4XQN7UuYCn9qtgiCsuI6J4K4ygkph+taIY48+IX1am4bc4IU/GXl6FPUj FxFlSxRHVf4tANVY8dq7a1vReB/pESH7NMm6bj+006Q1IB++sfIl+S2zfGQYCyoe9FVXATSC VjNmBB3L2/K2boOfZ2KM26v5K9wlOGXCONMxqAWiczwmYGzlNtX14VTVsuBUMdK7J7+eDlOv OgR7QXorjXrLU26ijdBQ0lGdETSog/63K50w/tUvVnEAAAAAAAA= --------------ms010300070302000600010702-- --===============1915032181== 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 --===============1915032181==-- From p2pi-bounces@ietf.org Tue Jul 8 00:33: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 57D783A69A8; Tue, 8 Jul 2008 00:33: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 C51FD3A68AA for ; Tue, 8 Jul 2008 00:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0+5C9yKDJhAN for ; Tue, 8 Jul 2008 00:33:43 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 274663A687A for ; Tue, 8 Jul 2008 00:33:42 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.stgw.sel.alcatel.de [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m687Xkl1026666 for ; Tue, 8 Jul 2008 09:33:46 +0200 Received: from [149.204.61.47] ([149.204.61.47]) by SLFSNX.rcs.alcatel-research.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 09:33:46 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-originalarrivaltime: 08 Jul 2008 07:33:46.0194 (UTC) FILETIME=[F49D0320:01C8E0CC] user-agent: Thunderbird 1.5.0.14 (Windows/20071210) Content-class: urn:content-classes:message Date: Tue, 8 Jul 2008 09:33:40 +0200 Message-ID: <48731854.90302@alcatel-lucent.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D: Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem Thread-Index: AcjgzPSkeiPTQu+cSPeP84ED1z9nnQ== From: "TOMSU, Marco" To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: [p2pi] New I-D: Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem 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="===============0940664626==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0940664626== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E0CC.F47F6900" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E0CC.F47F6900 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-hilt-alto-survey-00.txt has been posted to = the IETF repository. http://www.ietf.org/internet-drafts/draft-hilt-alto-survey-00.txt Title: A Survey on Research on the Application-Layer Traffic = Optimization (ALTO) Problem Creation_date: 2008-07-03 Abstract: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used traditionally for file-sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. We refer to this as the Application Layer Traffic Optimization (ALTO) problem. In this draft we present a survey of existing literature on discovering topology characteristics. ------_=_NextPart_001_01C8E0CC.F47F6900 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable New I-D: Survey on Research on the Application-Layer Traffic = Optimization (ALTO) Problem

A new version of I-D, draft-hilt-alto-survey-00.txt = has been posted to the IETF repository.

http://www.ietf.org/internet-drafts/draft-hilt-alto-survey-00.txt
Title:           A Survey = on Research on the Application-Layer Traffic Optimization (ALTO) = Problem
Creation_date:   2008-07-03

Abstract:
A significant part of the Internet traffic today is generated by
peer-to-peer (P2P) applications used traditionally for file-sharing,
and more recently for real-time communications and live media
streaming.  Such applications discover a route to each other = through
an overlay network with little knowledge of the underlying network
topology.  As a result, they may choose peers based on = information
deduced from empirical measurements, which can lead to suboptimal
choices.  We refer to this as the Application Layer Traffic
Optimization (ALTO) problem.  In this draft we present a survey = of
existing literature on discovering topology characteristics.

------_=_NextPart_001_01C8E0CC.F47F6900-- --===============0940664626== 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 --===============0940664626==-- From p2pi-bounces@ietf.org Tue Jul 8 05:31: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 663C03A684D; Tue, 8 Jul 2008 05:31: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 8DE103A684D for ; Tue, 8 Jul 2008 05:31:00 -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 hhn6IUJnaRxF for ; Tue, 8 Jul 2008 05:30:56 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 3DFCD3A6830 for ; Tue, 8 Jul 2008 05:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:mime-version:to:cc:subject:content-type: content-transfer-encoding; q=dns/txt; s=selucl; bh=mSHOsMowhS40I FguYhWWZHzoLIE=; b=svIUmCUdgI51LQRFLIAV38CE84Xr7S3nVXYZxJfVT0ebX FxXwZsSOsK1beXYLSXADPvkk045vjk19NT97DPL8G08ZmH2Stbr5Xr6I1fsQx4Fz zBgDzPIpf2fBt6Q+nfLzyDNLLQxmimPMTSzhTd4y9MkyjRR0PmA7Y5ZS7dBZl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:mime-version:to:cc:subject:content-type: content-transfer-encoding; q=dns; s=selucl; b=J75Bl6sdgKB9XyBUPV P5IfQxmtxSUCdhMgAqKNPqGd82grYdBu4EAmDeJ87za0gaBMJtEchYYnoMQkVbxs QGwa2uBHvlqhuDx7bIX97HvhoEbn3OK6rigBTMUy0TmLqh0L8qnLaIUcMchTvfcI uVfFcDs7CH6oZ390TYfE32aos= Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 8 Jul 2008 14:31:04 +0200 (CEST) Message-ID: <48735DC8.9020709@uclouvain.be> Date: Tue, 08 Jul 2008 14:30:00 +0200 From: Damien Saucez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: p2pi@ietf.org X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 21251F0197.E652D X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: [p2pi] ALTO BoF - generalize the problem 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 Dear all, We believe that the ALTO problem can't be restricted to the P2P case only. As already discussed on this mailing list, we must consider the problem to be addressed by ALTO in its whole in order to build a solution that is application independent. In other words, the techniques that will be developped in ALTO must not rely on a particular kind of application or traffic. This approach is required in order to build a traffic optimization scheme that is future-proof and can thus address future application needs. Indeed, experience has known that global trends in applications and traffic can dramatically change within a few years and even less sometimes. However, being application independant is not sufficient. As some works already investigate (see summary in the ALTO survey), traffic optimization can be improved by allowing cross layer cooperation. For these purposes, we propose 1. To extend the scope of ALTO so as to consider a global framework that allows traffic optimization. This framework should not only be application independant but also layer independant. Layer independence should allow for cooperation between applications and operators (with or without a third party involved). 2. To phase the workplan. Firstly, a crisp outline must be given for the problem we are trying to solve. Secondly, a set of design goals must be written to facilitate consensus. Finally, an application/layer independant architectural framework must be worked on to solve the problem with the current but also the future Internet traffic. Regards, Damien Saucez -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 2:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Why should the Traffic Optimization not be restricted to the Application-Layer? Author(s) : D. Saucez, D. Papadimitriou Filename : draft-saucez-alto-generalized-alto-00.txt Pages : 8 Date : 2008-07-07 The Application-Layer Traffic Optimization (ALTO) problem is being discussed within the IETF and more globally by the research community and some enterprises. In this memo, we argue that it is important to conceive general-purpose mechanisms to solve this problem. By general-purpose we say not only application independent but also layer independent mechanism. The generality can be obtained because the underlying problem is the same regardless the application or the layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saucez-alto-generalized-alto-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 8 06:06: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 AD9193A693E; Tue, 8 Jul 2008 06:06: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 8D24D3A693E for ; Tue, 8 Jul 2008 06:06:34 -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=[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 NeeuLLAHfHVg for ; Tue, 8 Jul 2008 06:06:33 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 96C483A690A for ; Tue, 8 Jul 2008 06:06:33 -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 12038870; Tue, 08 Jul 2008 09:06:42 -0400 Message-Id: <9363D216-4041-412B-BC16-9BC8A89F93DF@multicasttech.com> From: Marshall Eubanks To: Enrico Marocco In-Reply-To: <48730A27.6000103@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 8 Jul 2008 09:06:41 -0400 References: <018401c8e0ab$380a2ec0$4c09a40a@china.huawei.com> <48730A27.6000103@telecomitalia.it> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Agenda requests for 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 Jul 8, 2008, at 2:33 AM, Enrico Marocco wrote: > Song Haibin wrote: >> Tuesday should be July 29. July 28 is Monday. Could you please >> clarify the >> scheduled date for ALTO BoF? > > Yes, sorry, the ALTO BoF is actually scheduled for Tue Jul 29, > 9.00-11.30. > > The final meeting agenda Of course, keep in mind that IETF schedules are never really final until they happen and can certainly change between now and Dublin. Regards Marshall > is now available at > https://datatracker.ietf.org/meeting/72/agenda.html > > -- > 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 Jul 8 06:42: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 EA4ED28C0DD; Tue, 8 Jul 2008 06:42: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 B60DB3A6887 for ; Tue, 8 Jul 2008 06:42: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 qjFh-N9TK2bY for ; Tue, 8 Jul 2008 06:42:13 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 452973A67F9 for ; Tue, 8 Jul 2008 06:42:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 23F552C000303; Tue, 8 Jul 2008 15:42:22 +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 h3X7Uc0evGCn; Tue, 8 Jul 2008 15:42:22 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id DE9582C00035C; Tue, 8 Jul 2008 15:42:01 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Jul 2008 15:42:03 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> In-reply-to: <48735DC8.9020709@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjg9pjZwN9h2RvFTj+8EKJgsRCm5QABmzPg References: <48735DC8.9020709@uclouvain.be> From: "Saverio Niccolini" To: "Damien Saucez" , Cc: PAPADIMITRIOU Dimitri , Olivier Bonaventure Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 > As already discussed on this mailing list, we > must consider the problem to be addressed by ALTO in its > whole in order to build a solution that is application > independent. In other words, the techniques that will be > developped in ALTO must not rely on a particular kind of > application or traffic. This approach is required in order to > build a traffic optimization scheme that is future-proof and > can thus address future application needs. Indeed, experience > has known that global trends in applications and traffic can > dramatically change within a few years and even less sometimes. > However, being application independant is not sufficient. As > some works already investigate (see summary in the ALTO > survey), traffic optimization can be improved by allowing > cross layer cooperation. I do not get your point, ALTO is already application independent as such. I do not see any application-specific wording in the problem statement. Also it is indeed cross-layer since it will consider applications gathering info from IP layer and routing to make better decisions, in addition to decide based on application-layer metrics. For conveying requirements from the application layer to lower layers you can also check out the various QoS framework proposals by IETF and other bodies. If you want to consider other layer then maybe this BoF is not the right one for you, for transport issues you should better refer to the TANA BoF. > For these purposes, we propose > > 1. To extend the scope of ALTO so as to consider a global > framework that allows traffic optimization. This framework > should not only be application independant but also layer > independant. Layer independence should allow for cooperation > between applications and operators (with or without a third > party involved). Traffic optmization is already in the scope of ALTO, ALTO is starting from a real-world problem that is documented, before extending it too broadly beyond that to make "THE GENERAL FRAMEWORK" you should state better what is the motivation for that and reflect carefully if it is possible to get such a work chartered at all. ALTO instead addresses a clear operational discussed already in the P2P-I meeting in May and we all agree we need solutions for this, while I do not see why I would need yet another traffic optimization framework to control QoS in operators networks (maybe better go to ETSI TISPAN?) > 2. To phase the workplan. Firstly, a crisp outline must be > given for the problem we are trying to solve. Secondly, a set > of design goals must be written to facilitate consensus. > Finally, an application/layer independant architectural > framework must be worked on to solve the problem with the > current but also the future Internet traffic. The problem statement is there and is much more clear than "let's build the general traffic optimization framework" As I said I think ALTO is already application-independent and cross-layer thus I see no point discussing this issue further. Cheers, Saverio > > Regards, > > Damien Saucez > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 2:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Why should the Traffic Optimization > not be restricted to the Application-Layer? > Author(s) : D. Saucez, D. Papadimitriou > Filename : draft-saucez-alto-generalized-alto-00.txt > Pages : 8 > Date : 2008-07-07 > > The Application-Layer Traffic Optimization (ALTO) problem is > being discussed within the IETF and more globally by the > research community and some enterprises. In this memo, we > argue that it is important to conceive general-purpose > mechanisms to solve this problem. By general-purpose we say > not only application independent but also layer independent > mechanism. The generality can be obtained because the > underlying problem is the same regardless the application or > the layer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saucez-alto-generali > zed-alto-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ 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 Jul 8 07:04: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 E00A53A6867; Tue, 8 Jul 2008 07:04: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 887583A6867 for ; Tue, 8 Jul 2008 07:04:38 -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 Mh5StmrPmbXq for ; Tue, 8 Jul 2008 07:04:34 -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 2EBF53A6810 for ; Tue, 8 Jul 2008 07:04:34 -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 m68E4Z921565; Tue, 8 Jul 2008 16:04:35 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m68E4WA03791; Tue, 8 Jul 2008 16:04:32 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 08 Jul 2008 16:04:20 +0200 From: stefano previdi To: Damien Saucez , Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjhA4RAwrhznkz2Ed2IwwAX8vOM8g== In-Reply-To: <48735DC8.9020709@uclouvain.be> Mime-version: 1.0 Cc: PAPADIMITRIOU Dimitri , Olivier Bonaventure Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Damien, We've clearly specified in the requirements draft that p2p application is one possible but not the only one (this should partially address your concerns). So, ALTO being already application agnostic, nothing prevents you to consider ALTO providing a service which can be consumed by any other entity residing in any other layer (even the one where ALTO operates). s. > From: Damien Saucez > > Dear all, > > We believe that the ALTO problem can't be restricted to the P2P case > only. As already discussed on this mailing list, we must consider the > problem to be addressed by ALTO in its whole in order to build a > solution that is application independent. In other words, the techniques > that will be developped in ALTO must not rely on a particular kind of > application or traffic. This approach is required in order to build a > traffic optimization scheme that is future-proof and can thus address > future application needs. Indeed, experience has known that global > trends in applications and traffic can dramatically change within a few > years and even less sometimes. > > However, being application independant is not sufficient. As some works > already investigate (see summary in the ALTO survey), traffic > optimization can be improved by allowing cross layer cooperation. > > For these purposes, we propose > > 1. To extend the scope of ALTO so as to consider a global framework that > allows traffic optimization. This framework should not only be > application independant but also layer independant. Layer independence > should allow for cooperation between applications and operators (with or > without a third party involved). > > 2. To phase the workplan. Firstly, a crisp outline must be given for the > problem we are trying to solve. Secondly, a set of design goals must be > written to facilitate consensus. Finally, an application/layer > independant architectural framework must be worked on to solve the > problem with the current but also the future Internet traffic. > > Regards, > > Damien Saucez > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 2:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Why should the Traffic Optimization not be restricted to the > Application-Layer? > Author(s) : D. Saucez, D. Papadimitriou > Filename : draft-saucez-alto-generalized-alto-00.txt > Pages : 8 > Date : 2008-07-07 > > The Application-Layer Traffic Optimization (ALTO) problem is being > discussed within the IETF and more globally by the research community > and some enterprises. In this memo, we argue that it is important to > conceive general-purpose mechanisms to solve this problem. By > general-purpose we say not only application independent but also > layer independent mechanism. The generality can be obtained because > the underlying problem is the same regardless the application or the > layer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saucez-alto-generalized-alto-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > 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 Jul 8 07:21: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 ED5A63A692B; Tue, 8 Jul 2008 07:21: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 49E9B3A6A61 for ; Tue, 8 Jul 2008 07:21: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 U+VpwgeimmoL for ; Tue, 8 Jul 2008 07:21:34 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 741773A6894 for ; Tue, 8 Jul 2008 07:21:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5437EE10B9C; Tue, 8 Jul 2008 10:21:39 -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 d00hmpyyP6yQ; Tue, 8 Jul 2008 10:21:26 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id F0937E10BA7; Tue, 8 Jul 2008 10:21:26 -0400 (EDT) Date: Tue, 8 Jul 2008 10:21:26 -0400 (EDT) From: Laird Popkin To: stefano previdi Message-ID: <1954432644.482991215526886948.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org, Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: - ALTO is application independent. That is, while the ALTO was inspired by the issues raised by p2p applications, there's nothing specific to p2p applications in the ALTO proposal, and it's intended to be useful for other applications. In particular, we ALTO being very useful for (for example) identifying relays for NAT traversal for VOIP, or connecting players optimally in MMORPGs. If there any requirements that assume p2p, please point them out so that they can be generalized. - ALTO is focused on the application level, as there is another effort (TANA) addressing transport level issues. The two efforts are (hopefully) being coordinated. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" To: "Damien Saucez" , p2pi@ietf.org Cc: "PAPADIMITRIOU Dimitri" , "Olivier Bonaventure" Sent: Tuesday, July 8, 2008 10:04:20 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem Damien, We've clearly specified in the requirements draft that p2p application is one possible but not the only one (this should partially address your concerns). So, ALTO being already application agnostic, nothing prevents you to consider ALTO providing a service which can be consumed by any other entity residing in any other layer (even the one where ALTO operates). s. > From: Damien Saucez > > Dear all, > > We believe that the ALTO problem can't be restricted to the P2P case > only. As already discussed on this mailing list, we must consider the > problem to be addressed by ALTO in its whole in order to build a > solution that is application independent. In other words, the techniques > that will be developped in ALTO must not rely on a particular kind of > application or traffic. This approach is required in order to build a > traffic optimization scheme that is future-proof and can thus address > future application needs. Indeed, experience has known that global > trends in applications and traffic can dramatically change within a few > years and even less sometimes. > > However, being application independant is not sufficient. As some works > already investigate (see summary in the ALTO survey), traffic > optimization can be improved by allowing cross layer cooperation. > > For these purposes, we propose > > 1. To extend the scope of ALTO so as to consider a global framework that > allows traffic optimization. This framework should not only be > application independant but also layer independant. Layer independence > should allow for cooperation between applications and operators (with or > without a third party involved). > > 2. To phase the workplan. Firstly, a crisp outline must be given for the > problem we are trying to solve. Secondly, a set of design goals must be > written to facilitate consensus. Finally, an application/layer > independant architectural framework must be worked on to solve the > problem with the current but also the future Internet traffic. > > Regards, > > Damien Saucez > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 2:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Why should the Traffic Optimization not be restricted to the > Application-Layer? > Author(s) : D. Saucez, D. Papadimitriou > Filename : draft-saucez-alto-generalized-alto-00.txt > Pages : 8 > Date : 2008-07-07 > > The Application-Layer Traffic Optimization (ALTO) problem is being > discussed within the IETF and more globally by the research community > and some enterprises. In this memo, we argue that it is important to > conceive general-purpose mechanisms to solve this problem. By > general-purpose we say not only application independent but also > layer independent mechanism. The generality can be obtained because > the underlying problem is the same regardless the application or the > layer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saucez-alto-generalized-alto-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > 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 Jul 8 07:41: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 456A53A68D6; Tue, 8 Jul 2008 07:41: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 487D53A68D6 for ; Tue, 8 Jul 2008 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 dzHWecFcAK9P for ; Tue, 8 Jul 2008 07:40:58 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 8C0723A68A0 for ; Tue, 8 Jul 2008 07:40:57 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m68Ef5KG018537; Tue, 8 Jul 2008 16:41:05 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jul 2008 16:41:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 16:40:46 +0200 Message-ID: <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjg9pjZwN9h2RvFTj+8EKJgsRCm5QABmzPgAAEJmeA= References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> From: "PAPADIMITRIOU Dimitri" To: "Saverio Niccolini" , "Damien Saucez" , X-OriginalArrivalTime: 08 Jul 2008 14:41:05.0101 (UTC) FILETIME=[A697BFD0:01C8E108] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: Olivier Bonaventure Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Saverio Niccolini [mailto:Saverio.Niccolini@nw.neclab.eu] > Sent: Tuesday, July 08, 2008 3:42 PM > To: Damien Saucez; p2pi@ietf.org > Cc: Olivier Bonaventure; PAPADIMITRIOU Dimitri > Subject: RE: [p2pi] ALTO BoF - generalize the problem > > > As already discussed on this mailing list, we > > must consider the problem to be addressed by ALTO in its > > whole in order to build a solution that is application > > independent. In other words, the techniques that will be > > developped in ALTO must not rely on a particular kind of > > application or traffic. This approach is required in order to > > build a traffic optimization scheme that is future-proof and > > can thus address future application needs. Indeed, experience > > has known that global trends in applications and traffic can > > dramatically change within a few years and even less sometimes. > > However, being application independant is not sufficient. As > > some works already investigate (see summary in the ALTO > > survey), traffic optimization can be improved by allowing > > cross layer cooperation. > > I do not get your point, ALTO is already application independent > as such. I do not see any application-specific wording in the > problem statement. as such referring to the problem statement, i see: Section 1: "This document describes the problem of optimizing traffic generated by P2P applications using information provided by third parties. Section 2 introduces the problem and the main issues to keep in mind when designing a solution, while Section 3 describes some use cases where both P2P users and network operators would benefit from such a solution." Section 2: "Addressing the Application-Layer Traffic Optimization (ALTO) problem means, on the one hand, providing topology information regarding the underlying network and, on the other hand, enhancing P2P applications in order to use such information to select the best endpoints among those that are available for the connections they are going to establish." Section 2.1.1. "2.1.1. Information Distribution As a direct consequence of the total distribution of the Internet, it seems almost impossible to centralize all information P2P applications may need to optimize traffic they generate. It is quite likely that such information would be highly distributed, for example, at an ISP or domain level. It is also reasonable to expect that, in some cases, the same network administrators will control provision of such information." Section 2.1.2 "... therefore, in order to succeed and achieve wide adoption, any solution should provide a method to help P2P applications in peer selection without explicitly disclosing topology of the underlying network." Section 3, mainly focuses on p2p, three of the 5 sections 3.x have the word p2p in their first sentence and 3.1 is almost about the same. > Also it is indeed cross-layer since it will consider applications > gathering info from IP layer and routing to make better decisions, > in addition to decide based on application-layer metrics. > > For conveying requirements from the application layer to lower layers > you can also check out the various QoS framework proposals by IETF > and other bodies. > > If you want to consider other layer then maybe this BoF is not the > right one for you, for transport issues you should better refer to > the TANA BoF. So if i understand your reasoning an operator will have to host a specific entity per requesting "layer" or applicative space ? even if the mechanism to gather info from IP layer and routing to make better decisions would be the same ? > > For these purposes, we propose > > > > 1. To extend the scope of ALTO so as to consider a global > > framework that allows traffic optimization. This framework > > should not only be application independant but also layer > > independant. Layer independence should allow for cooperation > > between applications and operators (with or without a third > > party involved). > > Traffic optmization is already in the scope of ALTO, ALTO is starting > from a real-world problem that is documented, before extending it too > broadly beyond that to make "THE GENERAL FRAMEWORK" you should state > better what is the motivation for that and reflect carefully if it is > possible to get such a work chartered at all. simply because without cooperation - the self-fishness vs resource sharing problem will remain unadressed. > ALTO instead addresses a clear operational discussed already in the > P2P-I meeting in May and we all agree we need solutions for this > while I do not see why I would need yet another traffic > optimization framework > to control QoS in operators networks (maybe better go to ETSI TISPAN?) you are over-reading the initial e-mail i think. but very surprisingly you question the issue of cooperation while that statement is clearly in the problem statement, Section 2, you seem to support ""cooperating" with external services aware of the network topology could greatly optimize the traffic they generate. > > 2. To phase the workplan. Firstly, a crisp outline must be > > given for the problem we are trying to solve. Secondly, a set > > of design goals must be written to facilitate consensus. > > Finally, an application/layer independant architectural > > framework must be worked on to solve the problem with the > > current but also the future Internet traffic. > > The problem statement is there and is much more clear than > "let's build the general traffic optimization framework" > > As I said I think ALTO is already application-independent and > cross-layer thus I see no point discussing this issue further. reading your reply i feel like a BoF wouldn't even be necessary... the message you do not get apparently is that p2p traffic results in issue today but tomorrow it will be another type of application. -d. > Cheers, > Saverio > > > > > Regards, > > > > Damien Saucez > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Monday, July 07, 2008 2:00 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-saucez-alto-generalized-alto-00.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > Title : Why should the Traffic Optimization > > not be restricted to the Application-Layer? > > Author(s) : D. Saucez, D. Papadimitriou > > Filename : draft-saucez-alto-generalized-alto-00.txt > > Pages : 8 > > Date : 2008-07-07 > > > > The Application-Layer Traffic Optimization (ALTO) problem is > > being discussed within the IETF and more globally by the > > research community and some enterprises. In this memo, we > > argue that it is important to conceive general-purpose > > mechanisms to solve this problem. By general-purpose we say > > not only application independent but also layer independent > > mechanism. The generality can be obtained because the > > underlying problem is the same regardless the application or > > the layer. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-saucez-alto-generali > > zed-alto-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail > > reader implementation to automatically retrieve the ASCII > > version of the Internet-Draft. > > > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > > > > > ============================================================ > Dr. Saverio Niccolini > Manager, Real-Time Communications Group > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > 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 Jul 8 08:38: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 849A83A6A47; Tue, 8 Jul 2008 08:38: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 826EF3A6A47 for ; Tue, 8 Jul 2008 08:38: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 DFWYk5XhWpBi for ; Tue, 8 Jul 2008 08:38:38 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8C7593A686C for ; Tue, 8 Jul 2008 08:38:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A9BE92C0004E3; Tue, 8 Jul 2008 17:38:47 +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 KiJHP6kLEvdU; Tue, 8 Jul 2008 17:38:47 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 8555E2C000303; Tue, 8 Jul 2008 17:38:27 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Jul 2008 17:37:35 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACD70@VENUS.office> In-reply-to: <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjg9pjZwN9h2RvFTj+8EKJgsRCm5QABmzPgAAEJmeAAAvnmEA== References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> From: "Saverio Niccolini" To: "PAPADIMITRIOU Dimitri" , "Damien Saucez" , Cc: Olivier Bonaventure Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Ok, I now get your point: you do not like P2P as being the application ALTO is focusing on. Actually: -- P2P is written in the problem statement and in every motivation of ALTO because P2P are the type of applications motivating Application Layer Traffic Optmization. --> this is a real-world problem IETf is here to address In your draft you are not providing evidence why the general framework would be needed by other type of applications, thus I do not see why the group should be considering this option. As such I see: P2P are motivating this work and there is not evidence that other type of applications would need what you call "the general framework" Moreover: -- if you look at the requirements draft (http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) there is an explicit sentence where it is written: "The goal of ALTO is to provide information which can help peer-to- peer (P2P) applications to make better decisions with respect to peer selection. However, ALTO may be useful for non-P2P applications as well." In the requirement draft P2P applications are only used as examples but the requirements are general for every type of application. This express why I said: "ALTO is not application specific". As last thing: I think we do not agree on terminology: you can not say ALTO is application specific if it considers a class of applications (P2P ones) and it also meant to be useful for non-P2P ones. P2P is indeed NOT application-specific, any type of application can use the P2P paradigm. Maybe you want to re-phrase your statement? Cheers, Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ 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 Jul 8 08:53:53 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 8BBAB3A6869; Tue, 8 Jul 2008 08:53:53 -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 F3A293A6909 for ; Tue, 8 Jul 2008 08:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.465, 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 XgZrx2CgyxZt for ; Tue, 8 Jul 2008 08:53:51 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 868C43A6803 for ; Tue, 8 Jul 2008 08:53:33 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 17:52:32 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 17:52:32 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 8 Jul 2008 17:52:32 +0200 Message-ID: <48738D27.2020006@telecomitalia.it> Date: Tue, 8 Jul 2008 17:52:07 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 08 Jul 2008 15:52:32.0592 (UTC) FILETIME=[A222F500:01C8E112] Cc: Bonaventure , "p2pi@ietf.org" , Saverio Niccolini , Olivier@core3.amsl.com Subject: Re: [p2pi] ALTO BoF - generalize the problem 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="===============0226131559==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0226131559== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060702020107010807050901" --------------ms060702020107010807050901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PAPADIMITRIOU Dimitri wrote: >> I do not get your point, ALTO is already application independent >> as such. I do not see any application-specific wording in the >> problem statement. > > as such referring to the problem statement, i see: > > [...] Actually the problem statement is application independent (in that it does not address one particular application), but does not aim at covering all conceivable applications; instead, it focuses on a subset of them which share similar characteristics and generally refers to them as P2P, even if it covers also client/server use cases (in S3.5 in version 01, more extensively in the version under refinement.) >> Also it is indeed cross-layer since it will consider applications >> gathering info from IP layer and routing to make better decisions, >> in addition to decide based on application-layer metrics. >> >> For conveying requirements from the application layer to lower layers >> you can also check out the various QoS framework proposals by IETF >> and other bodies. >> >> If you want to consider other layer then maybe this BoF is not the >> right one for you, for transport issues you should better refer to >> the TANA BoF. > > So if i understand your reasoning an operator will have to host a > specific entity per requesting "layer" or applicative space ? even if > the mechanism to gather info from IP layer and routing to make better > decisions would be the same ? Of course, if the same mechanism developed in ALTO could also be used at network layers other than the application layer (from what I've read, I may see a case for using something like ALTO in LISP), there is nothing wrong in using it. -- Ciao, Enrico --------------ms060702020107010807050901 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDgxNTUyMDdaMCMG CSqGSIb3DQEJBDEWBBSaS6q4ThiZKn+cq6FmqtgpqE32NTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBADHnuKwR81pX uxKt+9aAyp7JI8ItkBmY/bnoc/YpvwY/Yu20TxAZpM3oC1ea0WQoICAfjNngtZIwPpbyGRRb rOV+puVPXgOiCRD3G+38ckpHGiOSxbldHhCuE6b/4qAle0npkZiBPMv+DFzfRDWfCFQLv/d+ MpNDp4JrRv7DW+WnnPPPuLnW7UEc9vFrtRTpYwJe+/dRBScp8z//srQwLCnTIRmfzYmUW5fQ qALP+aM5lWNv4GJl4C0UYVJnOQbJXPrhDrYgtm/VBuzUNldceV//wbirKD7WHCKtkBoefwSj /GpoHT81dKbtQwFGgMNX21VGJxFty18pwyMeSc4a6zgAAAAAAAA= --------------ms060702020107010807050901-- --===============0226131559== 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 --===============0226131559==-- From p2pi-bounces@ietf.org Tue Jul 8 09:25: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 178ED28C19B; Tue, 8 Jul 2008 09:25: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 2EEDB28C19B for ; Tue, 8 Jul 2008 09:25:05 -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 d6oAhWpdKOPG for ; Tue, 8 Jul 2008 09:24:54 -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 2D04428C184 for ; Tue, 8 Jul 2008 09:24:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,324,1212364800"; d="scan'208";a="50173874" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2008 16:25:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m68GP1t0026731 for ; Tue, 8 Jul 2008 09:25:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m68GP0o1027491 for ; Tue, 8 Jul 2008 16:25:01 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, 8 Jul 2008 09:24:44 -0700 Received: from [10.32.241.72] ([10.32.241.72]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 09:24:44 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <48738D27.2020006@telecomitalia.it> References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <48738D27.2020006@telecomitalia.it> Message-Id: From: Bruce Davie Date: Tue, 8 Jul 2008 12:24:38 -0400 To: p2pi@ietf.org X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 08 Jul 2008 16:24:44.0117 (UTC) FILETIME=[216A4850:01C8E117] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1796; t=1215534301; x=1216398301; 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[p2pi]=20ALTO=20BoF=20-=20generalize=20 the=20problem=20(not) |Sender:=20; bh=SCxUdS0xJnzaKTTq2LZI+FaCt0YP2wehts/fEDtC4Tk=; b=vE13BaZP4nEYxFX0PkJa2Z4ZnRYesPEC5E/6rSVhNEK7ocZhxRiP5pqLGy WAQTKncSDz4NaQXI/fUdhhqr5+lqENBetYL7cTkERoB7QGa8WmYx2eFTLbIq sfqj5fFVpYlpmHB6nBkjWWPfs2mFhK8zSCFdUerRwtovAy/3Sw7NQ=; Authentication-Results: sj-dkim-1; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [p2pi] ALTO BoF - generalize the problem (not) 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 couple of points: - while one can find plenty of quotes in draft-marocco-alto- problem-statement-01.txt that reflect the fact that p2p apps are a main motivation for this BOF, one could also point to many statements in draft-kiesel-alto-reqs-00.txt that indicate the desire to be broader than just p2p apps, for example: "The goal of ALTO is to provide information which can help peer-to- peer (P2P) applications to make better decisions with respect to peer selection. However, ALTO may be useful for non-P2P applications as well. For example, clients of client-server applications may use information provided by ALTO to select one of several servers or information replicas..." - a BOF which has too broad a scope is unlikely to lead successfully to a working group. So let's not get carried away with generalizing the problem to the point where it is no longer "well-scoped and solvable" (in the words of draft-narten-successful-bof-03.txt) Bruce Davie On Jul 8, 2008, at 11:52 AM, Enrico Marocco wrote: > PAPADIMITRIOU Dimitri wrote: >>> I do not get your point, ALTO is already application independent >>> as such. I do not see any application-specific wording in the >>> problem statement. >> >> as such referring to the problem statement, i see: >> >> [...] > > Actually the problem statement is application independent (in that it > does not address one particular application), but does not aim at > covering all conceivable applications; instead, it focuses on a subset > of them which share similar characteristics and generally refers to > them > as P2P, even if it covers also client/server use cases (in S3.5 in > version 01, more extensively in the version under refinement.) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 8 09:31: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 693A53A69B8; Tue, 8 Jul 2008 09:31: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 2E9883A69B8 for ; Tue, 8 Jul 2008 09:31:53 -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 iPoBGaBmmFcZ for ; Tue, 8 Jul 2008 09:31:52 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id BEE993A693E for ; Tue, 8 Jul 2008 09:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:mime-version:to:cc:subject:references: in-reply-to:content-type:content-transfer-encoding; q=dns/txt; s= selucl; bh=HB+/bnfsz9WQ+wwCMs9JH6zF7vc=; b=Rxab+ZMz5gxU/ScB9Y6Ju aa/qDPZVK7+A+Ilnl+BeIGDoXC3ytaovO3PMgpYXr7165KfP6u+IlGnFAOo4qZAw vPpGdz0beayeaSWMIViYi9VZC+pqI0yu4kDXKYDGKhXJFEvCVlTu6ZJr140aJky8 guWNgTHqRuJoapmvWecrng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=KxQrn ItexB589gmEXlKWpL/S0K5M3Fy3UPaS7iSExTmkN53XOC6EmYge2ZEAUG1ufx+dw 632cJi91UUPbGvzaF2WDH+xwzdqtazyYRZEwLAkVULCnV7B7kxHVJjo7sJuJt01B TNZn2dlh1erwK26hNDdnNjH5zf6Wqe9B7RBVPQ= Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 8 Jul 2008 18:31:56 +0200 (CEST) Message-ID: <48739643.4090409@uclouvain.be> Date: Tue, 08 Jul 2008 18:30:59 +0200 From: Damien Saucez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saverio Niccolini References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1ACD70@VENUS.office> X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 443A91C6D41.1C1CF X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Olivier Bonaventure , p2pi@ietf.org, PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Saverio, Saverio Niccolini wrote: >Ok, > >I now get your point: >you do not like P2P as being the application ALTO is focusing on. > > > We are not against P2Ps and we know that P2P is a major application for the ALTO problem. However, we think that it is really important to focus ALTO on all the applications and not on to say "ok, ALTO works also with other applications than P2P". Of course, when I read the drafts and the mails, I can see that you what to be independent, but it seems to be a secondary requirement and for me the genericity is the key of ALTO. >Actually: >-- P2P is written in the problem statement and in every motivation of ALTO >because P2P are the type of applications motivating Application Layer Traffic >Optmization. --> this is a real-world problem IETf is here to address > > > P2P is not the only real-world problem. We are from the routing world and we observe that you have the same problems as us and surprisingly the same solutions (the oracle and IDIPS have been designed independently and are more or less the same, the oracle was for P2P and IDIPS comes from NAROS discussed for the IPv6 multihoming problem), so what the draft says is to work together to avoid making systems doing the same things independently (waste or ressources). >In your draft you are not providing evidence why the general framework would >be needed by other type of applications, thus I do not see why the group should >be considering this option. > >As such I see: P2P are motivating this work and there is not evidence that other >type of applications would need what you call "the general framework" > > > >Moreover: >-- if you look at the requirements draft (http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) >there is an explicit sentence where it is written: >"The goal of ALTO is to provide information which can help peer-to- >peer (P2P) applications to make better decisions with respect to peer >selection. However, ALTO may be useful for non-P2P applications as >well." > >In the requirement draft P2P applications are only used as examples >but the requirements are general for every type of application. > >This express why I said: "ALTO is not application specific". > > > >As last thing: >I think we do not agree on terminology: >you can not say ALTO is application specific if it considers a class of >applications (P2P ones) and it also meant to be useful for non-P2P ones. > >P2P is indeed NOT application-specific, any type of application can use the >P2P paradigm. > > > Sure, we don't say alto is related to application XYZ, but is limited to the application layer (AL stands for Application Layer) and people working on the problem mainly come from the P2P world. Once again, the idea of the discussion is to insist on the fact that ALTO can be very generic without sacrifying anything. IDIPS works with LISP, SHIM6, dual stack machines, P2P, FTP or CDNs so our solutions (P4P, oracle) should probably also work with many different paradigms and what we would like is to extend ALTO to that point. >Maybe you want to re-phrase your statement? > > > >Cheers, >Saverio > > Thanks for your discussion Saverio. Damien Saucez > >============================================================ >Dr. Saverio Niccolini >Manager, Real-Time Communications Group >NEC Laboratories Europe, Network Research Division >Kurfuerstenanlage 36, D-69115 Heidelberg >Tel. +49 (0)6221 4342-118 >Fax: +49 (0)6221 4342-155 >e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >============================================================ >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 Jul 8 09:48: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 E94203A691A; Tue, 8 Jul 2008 09:48: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 647973A691A for ; Tue, 8 Jul 2008 09:48: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=[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 q0n0jzK5+kkc for ; Tue, 8 Jul 2008 09:48:13 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DC1673A67E5 for ; Tue, 8 Jul 2008 09:48:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1B50E2C000358; Tue, 8 Jul 2008 18:48:22 +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 pnggJ8crKE1S; Tue, 8 Jul 2008 18:48:21 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E00342C000303; Tue, 8 Jul 2008 18:48:01 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Jul 2008 18:48:01 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACD89@VENUS.office> In-reply-to: <48739643.4090409@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjhGDlfVZ21PI8vRP2aHbjAYlB1NwAATF6Q References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> From: "Saverio Niccolini" To: "Damien Saucez" Cc: p2pi@ietf.org, Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Damien, I see your point but in my opinion it does not make sense to go broader that what ALTO is already right now. I see ALTO problem statement and requirements a good trade-off of trying to be general while trying to address a well scoped problem area. --> that is the real challenge and I think ALTO people is doing a great job on this. As also Bruce pointed out: - a BOF which has too broad a scope is unlikely to lead successfully to a working group. (IETF non-written rule) I would encourage you to help the ALTO work in getting chartered instead of claiming for "the general framework" that is most probably not going to get consensus. Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Damien Saucez > Sent: Tuesday, July 08, 2008 6:31 PM > To: Saverio Niccolini > Cc: Olivier Bonaventure; p2pi@ietf.org; PAPADIMITRIOU Dimitri > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Saverio, > > Saverio Niccolini wrote: > > >Ok, > > > >I now get your point: > >you do not like P2P as being the application ALTO is focusing on. > > > > > > > We are not against P2Ps and we know that P2P is a major > application for the ALTO problem. However, we think that it > is really important to focus ALTO on all the applications and > not on to say "ok, ALTO works also with other applications than P2P". > > Of course, when I read the drafts and the mails, I can see > that you what to be independent, but it seems to be a > secondary requirement and for me the genericity is the key of ALTO. > > >Actually: > >-- P2P is written in the problem statement and in every > motivation of > >ALTO because P2P are the type of applications motivating Application > >Layer Traffic Optmization. --> this is a real-world problem IETf is > >here to address > > > > > > > P2P is not the only real-world problem. We are from the > routing world and we observe that you have the same problems > as us and surprisingly the same solutions (the oracle and > IDIPS have been designed independently and are more or less > the same, the oracle was for P2P and IDIPS comes from NAROS > discussed for the IPv6 multihoming problem), so what the > draft says is to work together to avoid making systems doing > the same things independently (waste or ressources). > > >In your draft you are not providing evidence why the general > framework > >would be needed by other type of applications, thus I do not see why > >the group should be considering this option. > > > >As such I see: P2P are motivating this work and there is not > evidence > >that other type of applications would need what you call > "the general framework" > > > > > > > >Moreover: > >-- if you look at the requirements draft > >(http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) > >there is an explicit sentence where it is written: > >"The goal of ALTO is to provide information which can help peer-to- > >peer (P2P) applications to make better decisions with > respect to peer > >selection. However, ALTO may be useful for non-P2P applications as > >well." > > > >In the requirement draft P2P applications are only used as > examples but > >the requirements are general for every type of application. > > > >This express why I said: "ALTO is not application specific". > > > > > > > >As last thing: > >I think we do not agree on terminology: > >you can not say ALTO is application specific if it considers > a class of > >applications (P2P ones) and it also meant to be useful for > non-P2P ones. > > > >P2P is indeed NOT application-specific, any type of > application can use > >the P2P paradigm. > > > > > > > Sure, we don't say alto is related to application XYZ, but is > limited to the application layer (AL stands for Application > Layer) and people working on the problem mainly come from the > P2P world. Once again, the idea of the discussion is to > insist on the fact that ALTO can be very generic without > sacrifying anything. IDIPS works with LISP, SHIM6, dual stack > machines, P2P, FTP or CDNs so our solutions (P4P, oracle) > should probably also work with many different paradigms and > what we would like is to extend ALTO to that point. > > >Maybe you want to re-phrase your statement? > > > > > > > >Cheers, > >Saverio > > > > > > Thanks for your discussion Saverio. > > Damien Saucez > > > > >============================================================ > >Dr. Saverio Niccolini > >Manager, Real-Time Communications Group > >NEC Laboratories Europe, Network Research Division > >Kurfuerstenanlage 36, D-69115 Heidelberg > >Tel. +49 (0)6221 4342-118 > >Fax: +49 (0)6221 4342-155 > >e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > >============================================================ > >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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 8 09:57: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 B891A3A686C; Tue, 8 Jul 2008 09:57: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 3E9573A686C for ; Tue, 8 Jul 2008 09:57:50 -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 yIpdyGAtteCv for ; Tue, 8 Jul 2008 09:57:48 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 5E34D3A6810 for ; Tue, 8 Jul 2008 09:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:mime-version:to:cc:subject:references: in-reply-to:content-type:content-transfer-encoding; q=dns/txt; s= selucl; bh=1ZkMxAEHtt8961BbSiKo5MdSvT0=; b=BgTLsMvBc3AX4hG6sVXID xQZZkU2yWFF70Pv+y6ERRcrvBlxfIC1VBuAXt8d5Xw6I8bRWgYmyQTVCGIH9yqo/ pz6p1EtXclSvqqdzsTXxIy9B19tWf/CFiFZ8Mw7VMsI588tqxUDQC+GlK+hk4OcP bmIXysasV6Ihho+Uq/MVMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=ur5iK pftqtHt9GgU9hGGbEWCJQIG9EN07ViYyHDFivzaK5RcOXpD96ZIs011DVoDohSCv dxmwCKnp1AlZvXUojWb8ZmG99t11juHKExL+/UbuRCXBKlvqk6lKzvFxmSTDj1V4 TfaSJp4mv0HkIfPAVVQeFtI1Rewx/IKEMnmmMw= Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 8 Jul 2008 18:57:51 +0200 (CEST) Message-ID: <48739C52.90606@uclouvain.be> Date: Tue, 08 Jul 2008 18:56:50 +0200 From: Damien Saucez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saverio Niccolini References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> <547F018265F92642B577B986577D671C1ACD89@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1ACD89@VENUS.office> X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: AB20F1C6DEF.78EBA X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org, Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Saverio, Saverio Niccolini wrote: >Dear Damien, > >I see your point but in my opinion it does not make sense to go >broader that what ALTO is already right now. > >I see ALTO problem statement and requirements a good trade-off of >trying to be general while trying to address a well scoped problem >area. --> that is the real challenge and I think ALTO people is >doing a great job on this. > >As also Bruce pointed out: >- a BOF which has too broad a scope is unlikely to lead >successfully to a working group. (IETF non-written rule) > >I would encourage you to help the ALTO work in getting chartered > > Of course I'll do. >instead of claiming for "the general framework" that is most probably >not going to get consensus. > > But I'll try because for me it is the key point for the future of the Internet. Look at what is happening on the control plane, it's completely out of control with protocol redundancy. Control plane is ugly because most of the protocols have been design without taking care of what is done in other domains (which do the same things but with other low level objectives). Regards, Damien Saucez >Saverio > >============================================================ >Dr. Saverio Niccolini >Manager, Real-Time Communications Group >NEC Laboratories Europe, Network Research Division >Kurfuerstenanlage 36, D-69115 Heidelberg >Tel. +49 (0)6221 4342-118 >Fax: +49 (0)6221 4342-155 >e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >============================================================ >NEC Europe Limited Registered Office: NEC House, 1 Victoria >Road, London W3 6BL Registered in England 2832014 > > > > > >>-----Original Message----- >>From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On >>Behalf Of Damien Saucez >>Sent: Tuesday, July 08, 2008 6:31 PM >>To: Saverio Niccolini >>Cc: Olivier Bonaventure; p2pi@ietf.org; PAPADIMITRIOU Dimitri >>Subject: Re: [p2pi] ALTO BoF - generalize the problem >> >>Saverio, >> >>Saverio Niccolini wrote: >> >> >> >>>Ok, >>> >>>I now get your point: >>>you do not like P2P as being the application ALTO is focusing on. >>> >>> >>> >>> >>> >>We are not against P2Ps and we know that P2P is a major >>application for the ALTO problem. However, we think that it >>is really important to focus ALTO on all the applications and >>not on to say "ok, ALTO works also with other applications than P2P". >> >>Of course, when I read the drafts and the mails, I can see >>that you what to be independent, but it seems to be a >>secondary requirement and for me the genericity is the key of ALTO. >> >> >> >>>Actually: >>>-- P2P is written in the problem statement and in every >>> >>> >>motivation of >> >> >>>ALTO because P2P are the type of applications motivating Application >>>Layer Traffic Optmization. --> this is a real-world problem IETf is >>>here to address >>> >>> >>> >>> >>> >>P2P is not the only real-world problem. We are from the >>routing world and we observe that you have the same problems >>as us and surprisingly the same solutions (the oracle and >>IDIPS have been designed independently and are more or less >>the same, the oracle was for P2P and IDIPS comes from NAROS >>discussed for the IPv6 multihoming problem), so what the >>draft says is to work together to avoid making systems doing >>the same things independently (waste or ressources). >> >> >> >>>In your draft you are not providing evidence why the general >>> >>> >>framework >> >> >>>would be needed by other type of applications, thus I do not see why >>>the group should be considering this option. >>> >>>As such I see: P2P are motivating this work and there is not >>> >>> >>evidence >> >> >>>that other type of applications would need what you call >>> >>> >>"the general framework" >> >> >>> >>> >>>Moreover: >>>-- if you look at the requirements draft >>>(http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) >>>there is an explicit sentence where it is written: >>>"The goal of ALTO is to provide information which can help peer-to- >>>peer (P2P) applications to make better decisions with >>> >>> >>respect to peer >> >> >>>selection. However, ALTO may be useful for non-P2P applications as >>>well." >>> >>>In the requirement draft P2P applications are only used as >>> >>> >>examples but >> >> >>>the requirements are general for every type of application. >>> >>>This express why I said: "ALTO is not application specific". >>> >>> >>> >>>As last thing: >>>I think we do not agree on terminology: >>>you can not say ALTO is application specific if it considers >>> >>> >>a class of >> >> >>>applications (P2P ones) and it also meant to be useful for >>> >>> >>non-P2P ones. >> >> >>>P2P is indeed NOT application-specific, any type of >>> >>> >>application can use >> >> >>>the P2P paradigm. >>> >>> >>> >>> >>> >>Sure, we don't say alto is related to application XYZ, but is >>limited to the application layer (AL stands for Application >>Layer) and people working on the problem mainly come from the >>P2P world. Once again, the idea of the discussion is to >>insist on the fact that ALTO can be very generic without >>sacrifying anything. IDIPS works with LISP, SHIM6, dual stack >>machines, P2P, FTP or CDNs so our solutions (P4P, oracle) >>should probably also work with many different paradigms and >>what we would like is to extend ALTO to that point. >> >> >> >>>Maybe you want to re-phrase your statement? >>> >>> >>> >>>Cheers, >>>Saverio >>> >>> >>> >>> >>Thanks for your discussion Saverio. >> >>Damien Saucez >> >> >> >>>============================================================ >>>Dr. Saverio Niccolini >>>Manager, Real-Time Communications Group >>>NEC Laboratories Europe, Network Research Division >>>Kurfuerstenanlage 36, D-69115 Heidelberg >>>Tel. +49 (0)6221 4342-118 >>>Fax: +49 (0)6221 4342-155 >>>e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >>>============================================================ >>>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 >> >> > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 8 10:08: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 22E9C3A6A17; Tue, 8 Jul 2008 10:08: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 97ECE3A69CE for ; Tue, 8 Jul 2008 10:08: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 Vm0OBa04EKZ9 for ; Tue, 8 Jul 2008 10:08:46 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2E46E3A6A17 for ; Tue, 8 Jul 2008 10:08:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 727782C000358; Tue, 8 Jul 2008 19:08:55 +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 fcoVABF9FgXs; Tue, 8 Jul 2008 19:08:55 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4BE042C000303; Tue, 8 Jul 2008 19:08:35 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Jul 2008 19:08:34 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACD8C@VENUS.office> In-reply-to: <48739C52.90606@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjhG8wfrPEsaAjLTwS6SDuQTZYqVAAAHuhA References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> <547F018265F92642B577B986577D671C1ACD89@VENUS.office> <48739C52.90606@uclouvain.be> From: "Saverio Niccolini" To: "Damien Saucez" Cc: p2pi@ietf.org, Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 would encourage you to help the ALTO work in getting chartered > > > Of course I'll do. Good, this is the most important thing :-) > >instead of claiming for "the general framework" that is most > probably > >not going to get consensus. > > > > > But I'll try because for me it is the key point for the > future of the Internet. Look at what is happening on the > control plane, it's completely out of control with protocol > redundancy. Control plane is ugly because most of the > protocols have been design without taking care of what is > done in other domains (which do the same things but with > other low level objectives). I understand your point and I see you being right in the ideal world (I used to live in that one as well but facts are bringing me back to the reality) at the same time I do not think that ALTO can make order in the "control plane jungle" and come up with THE ONE. IETF charters well-scoped work and tries to listen for consensus, I am sure there is people that thinks like you (and I see you making reasonable statements) but they also realize there is no point to try to sove the problem on such a broad scale. It is better do a small piece of work than do not have the WG at all (that is why people is fine with ALTO scope as it is). Cheers, Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ 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 Jul 8 15:01: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 7DE6E28C25D; Tue, 8 Jul 2008 15:01: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 D184128C25D for ; Tue, 8 Jul 2008 15:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 A1DOE8PmPDvT for ; Tue, 8 Jul 2008 15:01:23 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id B6EC23A694E for ; Tue, 8 Jul 2008 15:01:22 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m68M1Vmg018575; Wed, 9 Jul 2008 00:01:31 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 9 Jul 2008 00:01:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 00:01:12 +0200 Message-ID: <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <547F018265F92642B577B986577D671C1ACD70@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjg9pjZwN9h2RvFTj+8EKJgsRCm5QABmzPgAAEJmeAAAvnmEAACGxKw References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> From: "PAPADIMITRIOU Dimitri" To: "Saverio Niccolini" , "Damien Saucez" , X-OriginalArrivalTime: 08 Jul 2008 22:01:31.0227 (UTC) FILETIME=[2DCA92B0:01C8E146] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: Olivier Bonaventure Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Saverio Niccolini [mailto:Saverio.Niccolini@nw.neclab.eu] > Sent: Tuesday, July 08, 2008 5:38 PM > To: PAPADIMITRIOU Dimitri; Damien Saucez; p2pi@ietf.org > Cc: Olivier Bonaventure > Subject: RE: [p2pi] ALTO BoF - generalize the problem > > Ok, > > I now get your point: > you do not like P2P as being the application ALTO is focusing on. > > Actually: > -- P2P is written in the problem statement and in every > motivation of ALTO > because P2P are the type of applications motivating > Application Layer Traffic > Optmization. --> this is a real-world problem IETf is here to address it is a - clear - example from where problems observed today can be drawn i.e. defines a motivation but not a solution space/scope. > In your draft you are not providing evidence why the general > framework would > be needed by other type of applications, thus I do not see > why the group should be considering this option. the problem is that the Internet has no means to efficiently address the challenges posed by applications operating transparently or even trying to solve networking problems at the applicative level - reason why a cooperation would be beneficial for both parties. the proposal is to work on such kind of solution instead of having to address each application-traffic optimization problem separately > As such I see: P2P are motivating this work and there is not > evidence that other > type of applications would need what you call "the general framework" > > Moreover: > -- if you look at the requirements draft > (http://tools.ietf.org/id/draft-kiesel-alto-reqs-00.txt) > there is an explicit sentence where it is written: > "The goal of ALTO is to provide information which can help peer-to- > peer (P2P) applications to make better decisions with respect to peer > selection. However, ALTO may be useful for non-P2P applications as > well." > > In the requirement draft P2P applications are only used as examples > but the requirements are general for every type of application. > > This express why I said: "ALTO is not application specific". be "application layer independent" is different from being "not P2P application specific" > As last thing: > I think we do not agree on terminology: > you can not say ALTO is application specific if it considers > a class of applications (P2P ones) and it also meant to be > useful for non-P2P ones. > > P2P is indeed NOT application-specific, any type of > application can use the P2P paradigm. > > Maybe you want to re-phrase your statement? you should see the position in the other way around. i have the subtle impression that the real issue is not whether p2p needs a specific solution but whether the internet at large has to deliver a suitable answer to accommodate efficiently various application traffic and we have in the p2p context the most illustrative example. > Cheers, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Manager, Real-Time Communications Group > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > 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 Jul 8 23:58: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 5CC6E3A67C0; Tue, 8 Jul 2008 23:58: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 9690B3A67AA for ; Tue, 8 Jul 2008 23:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 67AC-6C866dz for ; Tue, 8 Jul 2008 23:58:42 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 943523A683B for ; Tue, 8 Jul 2008 23:58:41 -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 <0K3Q001RR8KY1G@szxga02-in.huawei.com> for p2pi@ietf.org; Wed, 09 Jul 2008 14:55:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3Q0088F8KY3S@szxga02-in.huawei.com> for p2pi@ietf.org; Wed, 09 Jul 2008 14:55:46 +0800 (CST) Received: from s64081 ([10.164.9.76]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3Q00A0N8KYCT@szxml04-in.huawei.com> for p2pi@ietf.org; Wed, 09 Jul 2008 14:55:46 +0800 (CST) Date: Wed, 09 Jul 2008 14:55:45 +0800 From: Song Haibin In-reply-to: To: 'Reinaldo Penno' , "'Vijay K. Gurbani'" , 'Stanislav Shalunov' Message-id: <003e01c8e190$d0270ee0$4c09a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acja9pn309eRRsMdk0+SkHXAytwdvAGf6x9g Cc: p2pi@ietf.org Subject: Re: [p2pi] New version of the problem statement 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, >From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >Reinaldo Penno >Sent: Tuesday, July 01, 2008 5:17 AM > >although P2P peer selection geared towards keeping the traffic local (as in >the same AS) is a major driver there are other cases as well that we should >keep in mind so the solution is general. And sometimes the interest of the >client is not necessarily the same as the ISP. > >* There are ISPs that want traffic within its AS because of cross-ISP >transit costs. Here traffic locality and caching would be good solutions. I agree. The problem is that there is much traffic in the ISP back-bone or inter-ISP link. In my mind, there are ways to optimize this kind of traffic, one is through the peer selection (provided by the implicit ISP topology), and the second one is caching, the third one is through the traffic aggregation and distribution in the ISP's network (something like multicast in the ISP's network, especially for hot files). >* There are ISPs where transit cost is not the major problem. The most >pressing problem is upload/download between subscribers within its AS. Peer >locality might not to help much here (actually could be make the problem >worse). Caching or downloading from peers outside your own AS might be a >better fit. Yes. I think here is another problem for the P2P application. The subscriber's upload/download bandwidths are asymmetric. Then the total upload/download bandwidths are also unbalanced. Peer selection from other ISP network can lessen this problem, if that ISP network has plenty of upload capability and resources. Caching, traffic aggregation and distribution in the ISP's network are also choices to solve this problem. >* Then there are ISPs that actually want peers outside its AS to download >from them. This allows them to argue for settlement free peering since now >then send as much traffic as they receive from their upstream provider. This is the ISP's policy. ISPs of course want their policies about traffic to be carried out by all applications. >* The other dimension is that with the exception of caches, the closest peer >from a pure coordinate perspective is not necessarily the best peer. At >least not from the client perspective due to bw limitations. Yes, I agree. >But I'm guessing the results from P2P CDNs like DNA vs. open would be quite >different in this aspect. Could you please give me some materials on that for information? >* Then of course as it was mentioned the needs of streaming P2P vs. file >transfer vs. replication are quite different. So here ISP just provides the information that P2P or other applications can use to optimize their traffic directly or indirectly, but not itself makes decisions for these applications. Best Regards Song Haibin Skype: alexsonghw >Thanks, > > > > >On 6/30/08 1:46 PM, "Vijay K. Gurbani" wrote: > >> Stanislav Shalunov wrote: >>> I'd say both. Right now, it's treated as an afterthought. Given how >>> easy it is to engineer and the immense payoffs that it promises to both >>> the ISP and the P2P app user, it should be given more prominent >>> display. This is the easy stuff that we probably very easily all agree on. >> >> Stanislav: OK. >> >>> Whatever the goal is and however it's phrased, it would help focus to >>> add it in the most concise form in the very beginning of the document. >> >> Agreed; hence getting this document out for early review for >> maybe one more iteration before the submission deadline. >> >>>> In this version we tried to stress that an ALTO solution should be >>>> deployable also by third-parties other than ISPs. >>> >>> It's good if it can be made deployable by entities other than ISPs. Who >>> might be such third parties? >> >> One model is espoused by Ono, from Northwestern University. Ono, as >> I am sure you may be aware of, is an Azureus plug-in that uses >> Akamai's CDN to derive hints on how clients are redirected to >> replica servers and thus bias a peer selection algorithm (their >> paper is in Sigcomm 2008 conference and can be accessed from >> >http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf) >. >> >> We posit that a neutral third party may be someone that uses >> techniques like this that are not ISP-dependent. >> >> Thanks, >> >> - vijay > >_______________________________________________ >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 Jul 9 00:56: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 A173A3A6950; Wed, 9 Jul 2008 00:56: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 D198D3A6950 for ; Wed, 9 Jul 2008 00:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.310, 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 1MCdo+SJOReT for ; Wed, 9 Jul 2008 00:56:46 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 87D8E3A6863 for ; Wed, 9 Jul 2008 00:56:45 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 09:56:53 +0200 Received: from grfhub702rm001.griffon.local ([10.19.3.9]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 09:56:52 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.19.3.41) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 9 Jul 2008 09:56:52 +0200 Message-ID: <48746F2B.8000407@telecomitalia.it> Date: Wed, 9 Jul 2008 09:56:27 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 09 Jul 2008 07:56:52.0543 (UTC) FILETIME=[595AD4F0:01C8E199] Cc: Bonaventure , "p2pi@ietf.org" , Saverio Niccolini , Olivier@core3.amsl.com Subject: Re: [p2pi] ALTO BoF - generalize the problem 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="===============1853476189==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1853476189== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203030805070902040603" --------------ms010203030805070902040603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PAPADIMITRIOU Dimitri wrote: >> In your draft you are not providing evidence why the general >> framework would >> be needed by other type of applications, thus I do not see >> why the group should be considering this option. > > the problem is that the Internet has no means to efficiently address the > challenges posed by applications operating transparently or even trying > to solve networking problems at the applicative level - reason why a > cooperation would be beneficial for both parties. > > the proposal is to work on such kind of solution instead of having to > address each application-traffic optimization problem separately ALTO targets applications dealing with resources available at multiple locations. I agree that the term "P2P applications" is a poor choice Vijay and I are to blame for, but so far it has proved quite effective in helping people capture the problem we are tackling here. Suggestions for a better terminology are of course welcome. >> In the requirement draft P2P applications are only used as examples >> but the requirements are general for every type of application. >> >> This express why I said: "ALTO is not application specific". > > be "application layer independent" is different from being "not P2P > application specific" The concept of layer independence is probably what made people jump from their chairs. Could you explain, possibly with some examples, what you mean by it? I guess you are not disputing the fact that protocols specified in ALTO will be application-level protocols (i.e. built upon transport protocols like TCP, UDP, or DCCP), right? -- Ciao, Enrico --------------ms010203030805070902040603 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDkwNzU2MjdaMCMG CSqGSIb3DQEJBDEWBBTKJtHi6kQVTo6Mg6oEToVB3PBjBTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBACQ0VU+HS4Km Mm1upXzRPYwQXon57HLaut2WictW9EDqoc4u8t7S9iJFnm1PZ8kvr5kzLzYGmrvSrg/EhtUd afvAtgyA28AZbWsEhaJXayOAdNpLTWLDGyEQp8XFPWMeMntdKA1uNyXWMS8/3GPl87BMhVIm zL8AY8yhRnhp1iBShxIu+7rGjlma1zIVyrF6T0PN5K8qH6a17+C6Le4YAOO1eKcqOP/w+F9q 7e/64a2ykSmdXxSD/YLmtHxnCficXE/25liBLuSd8XmwkJxORnCZp0Fve/39ebcUyEB9bjsZ 2bRitr5QPfi3bVDnq5tLqSfweFv8PR4xlDdj2S7xGqEAAAAAAAA= --------------ms010203030805070902040603-- --===============1853476189== 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 --===============1853476189==-- From p2pi-bounces@ietf.org Wed Jul 9 02:24: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 40A3A3A6A05; Wed, 9 Jul 2008 02:24: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 0A0693A6A05 for ; Wed, 9 Jul 2008 02:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 LffUYwJshld5 for ; Wed, 9 Jul 2008 02:24:03 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F38C03A6906 for ; Wed, 9 Jul 2008 02:24:02 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3O000R94HSOL@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 08 Jul 2008 11:32:16 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3O000R44HSVX@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 08 Jul 2008 11:32:16 +0800 (CST) Received: from s64081 ([10.164.9.76]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3O000IC4HSMP@szxml03-in.huawei.com> for p2pi@ietf.org; Tue, 08 Jul 2008 11:32:16 +0800 (CST) Date: Tue, 08 Jul 2008 11:32:16 +0800 From: Song Haibin In-reply-to: <48722D89.3050302@telecomitalia.it> To: 'Enrico Marocco' , p2pi@ietf.org Message-id: <018401c8e0ab$380a2ec0$4c09a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjgQUjd2dutjTrASeKtdSBK28IcIgAaPHdw Subject: Re: [p2pi] Agenda requests for 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 Enrico, Tuesday should be July 29. July 28 is Monday. Could you please clarify the scheduled date for ALTO BoF? Best Regards, Song Haibin Email: melodysong@huawei.com Skype: alexsonghw >-----Original Message----- >From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Enrico >Marocco >Sent: Monday, July 07, 2008 10:52 PM >To: p2pi@ietf.org >Subject: [p2pi] Agenda requests for ALTO > >The ALTO BoF is currently scheduled for Tuesday 28, 9:00-11:30. > >According to draft-narten-successful-bof-03, the agenda is being >assembled focusing on the problem statement rather than on specific >solution proposals. If you want to request a slot on the agenda for a >presentation you think may help people better understand and scope the >problem, please send a private email to Vijay and me. > >-- >Ciao, >Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 02:49: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 AAA843A68B2; Wed, 9 Jul 2008 02:49: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 C03773A6A05 for ; Wed, 9 Jul 2008 02:49: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=[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 Bji0GOP7LpWF for ; Wed, 9 Jul 2008 02:49:43 -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 4F89D3A68B2 for ; Wed, 9 Jul 2008 02:49:43 -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 m699ndP27785; Wed, 9 Jul 2008 11:49:39 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m699nXA09431; Wed, 9 Jul 2008 11:49:33 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 09 Jul 2008 11:49:20 +0200 From: stefano previdi To: Damien Saucez , Saverio Niccolini Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjhqQ8nTXBTOk2cEd2fJQAX8vOM8g== In-Reply-To: <48739643.4090409@uclouvain.be> Mime-version: 1.0 Cc: p2pi@ietf.org, Olivier Bonaventure , PAPADIMITRIOU Dimitri Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Damien, > From: Damien Saucez > > We are not against P2Ps and we know that P2P is a major application for > the ALTO problem. However, we think that it is really important to focus > ALTO on all the applications and not on to say "ok, ALTO works also with > other applications than P2P". > > Of course, when I read the drafts and the mails, I can see that you what > to be independent, but it seems to be a secondary requirement and for me > the genericity is the key of ALTO. As already pointed out, p2p application is going to be the trigger for a WG constitution so it's normal to emphasize this specific case. I believe we're all in sync on this, right ? The fact is that we have to proceed by steps and this one (probably the most delicate) is to form a WG with a precise scope. >> Actually: >> -- P2P is written in the problem statement and in every motivation of ALTO >> because P2P are the type of applications motivating Application Layer Traffic >> Optmization. --> this is a real-world problem IETf is here to address >> > P2P is not the only real-world problem. We are from the routing world me too... > and we observe that you have the same problems as us I'm not fully convinced you can make such a parallel... > and surprisingly > the same solutions (the oracle and IDIPS have been designed > independently and are more or less the same, the oracle was for P2P and > IDIPS comes from NAROS discussed for the IPv6 multihoming problem), so > what the draft says is to work together to avoid making systems doing > the same things independently (waste or ressources). that's why I stated (in my first reply to you) that: So, ALTO being already application agnostic, nothing prevents you to consider ALTO providing a service which can be consumed by any other entity residing in any other layer (even the one where ALTO operates). Also, at this stage, we propose to work on the signaling part between ALTO providers and consumers. There's not (yet) a layering issues here. [...] >> P2P is indeed NOT application-specific, any type of application can use the >> P2P paradigm. >> > Sure, we don't say alto is related to application XYZ, but is limited to > the application layer (AL stands for Application Layer) and people > working on the problem mainly come from the P2P world. Once again, the > idea of the discussion is to insist on the fact that ALTO can be very > generic without sacrifying anything. ALTO services delivered to an application entity do not have the same set of constraints of an ALTO service delivered to a routing entity. Example: in the hop-by-hop routing paradigm, routing decisions MUST be consistent. Interoperability at routing layer is a MUST while application peer/server/whatever selection may be done orthogonally (even if you leverage routing databases). For sure (and I probably anticipate your answer here) using BGP recursion, MPLS/IP encap, and so on, you can also have an orthogonal approach... This is just _one_ example where making ALTO generic to any layer implies a significant differently approach. Disclaimer: I'm not stating we shouldn't do it... I just want to point out that the "whole picture" is significantly different. > IDIPS works with LISP, SHIM6, dual > stack machines, P2P, FTP or CDNs so our solutions (P4P, oracle) should > probably also work with many different paradigms and what we would like > is to extend ALTO to that point. As specified in the requirements draft, and at this stage, we want to focus on the signaling part of the picture (between ALTO providers and consumers). This does not preclude any form of algorithm extensions in order to cope with other cases but not at this stage of the work. Going for a routing approach will forces us to work on the algorithms as well... and by experience (believe me) this would be _very_ long term work. > But I'll try because for me it is the key point for the future of the > Internet. Look at what is happening on the control plane, it's > completely out of control with protocol redundancy. Well, stating the control plane is "out of control" looks to me (a bit) as an overstatement... but I see what you mean (from a routing perspective). > Control plane is > ugly because most of the protocols have been design without taking care > of what is done in other domains (which do the same things but with > other low level objectives). I think I have a slight different vision: protocols have been defined, engineered and deployed with a pragmatical focus in order to address specific problems and issues. Maybe you are right: a better understanding of the whole picture would have helped in defining a better (and maybe less number of) protocols. The problem is the same: who can claim to have the best view and _now_ ? Thanks. s. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 07:40: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 E18C528C17D; Wed, 9 Jul 2008 07:40: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 9B9DD28C16E for ; Wed, 9 Jul 2008 07:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_FR=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 zYjrXzZHqhkc for ; Wed, 9 Jul 2008 07:40:39 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 675A33A68DB for ; Wed, 9 Jul 2008 07:40:39 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m69EenGI011691; Wed, 9 Jul 2008 16:40:49 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 9 Jul 2008 16:40:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 16:40:48 +0200 Message-ID: <00275A5B436CA441900CB10936742A38C8742B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <48746F2B.8000407@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjhmWBdOO7EPFjjSEOV4P6MXnzipgAJcUVQ References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> <48746F2B.8000407@telecomitalia.it> From: "PAPADIMITRIOU Dimitri" To: "Enrico Marocco" X-OriginalArrivalTime: 09 Jul 2008 14:40:49.0631 (UTC) FILETIME=[C7C8F6F0:01C8E1D1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Olivier Bonaventure , p2pi@ietf.org, Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Wednesday, July 09, 2008 9:56 AM > To: PAPADIMITRIOU Dimitri > Cc: Saverio Niccolini; Damien Saucez; p2pi@ietf.org; Olivier > Bonaventure > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > PAPADIMITRIOU Dimitri wrote: > >> In your draft you are not providing evidence why the general > >> framework would > >> be needed by other type of applications, thus I do not see > >> why the group should be considering this option. > > > > the problem is that the Internet has no means to > efficiently address the > > challenges posed by applications operating transparently or > even trying > > to solve networking problems at the applicative level - reason why a > > cooperation would be beneficial for both parties. > > > > the proposal is to work on such kind of solution instead of > having to > > address each application-traffic optimization problem separately > > ALTO targets applications dealing with resources available at multiple > locations. I agree that the term "P2P applications" is a poor choice > Vijay and I are to blame for, but so far it has proved quite effective > in helping people capture the problem we are tackling here. > Suggestions for a better terminology are of course welcome. something like distributed resource application would do it probably (but just a suggestion) > >> In the requirement draft P2P applications are only used as examples > >> but the requirements are general for every type of application. > >> > >> This express why I said: "ALTO is not application specific". > > > > be "application layer independent" is different from being "not P2P > > application specific" > > The concept of layer independence is probably what made > people jump from > their chairs. Could you explain, possibly with some examples, what you > mean by it? what is meant here is that cooperation between the "application" and the "operators" must rely on an abstraction of the different layers information (in part. network) to the higher layer without having to know from where the information comes and its actual distribution. so cooperation from abstration which is a mechanism that can be used for topology hiding purposes (the latter is mentioned in the ps doc.) > I guess you are not disputing the fact that protocols > specified in ALTO will be application-level protocols (i.e. built upon > transport protocols like TCP, UDP, or DCCP), right? right. -d. > -- > Ciao, > Enrico > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 08:05: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 4A39F3A6ADA; Wed, 9 Jul 2008 08:05: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 E509D3A6AC2 for ; Wed, 9 Jul 2008 08:05:30 -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 anLvO+CRiMX0 for ; Wed, 9 Jul 2008 08:05:30 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id A96C63A67CF for ; Wed, 9 Jul 2008 08:05:29 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 17:05:40 +0200 Received: from grfhub703rm001.griffon.local ([10.19.3.10]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 17:05:40 +0200 Received: from [172.16.82.10] (163.162.180.246) by smtp.telecomitalia.it (10.19.3.42) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 9 Jul 2008 17:05:39 +0200 Message-ID: <4874D3AA.30909@telecomitalia.it> Date: Wed, 9 Jul 2008 17:05:14 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> <48746F2B.8000407@telecomitalia.it> <00275A5B436CA441900CB10936742A38C8742B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38C8742B@FRVELSMBS22.ad2.ad.alcatel.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 09 Jul 2008 15:05:40.0244 (UTC) FILETIME=[40427540:01C8E1D5] Cc: Bonaventure , "p2pi@ietf.org" , Saverio Niccolini , Olivier@core3.amsl.com Subject: Re: [p2pi] ALTO BoF - generalize the problem 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="===============0705898945==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0705898945== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020704010607050509070300" --------------ms020704010607050509070300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PAPADIMITRIOU Dimitri wrote: >> The concept of layer independence is probably what made >> people jump from >> their chairs. Could you explain, possibly with some examples, what you >> mean by it? > > what is meant here is that cooperation between the "application" and the > "operators" must rely on an abstraction of the different layers > information (in part. network) to the higher layer without having to > know from where the information comes and its actual distribution. so > cooperation from abstration which is a mechanism that can be used for > topology hiding purposes (the latter is mentioned in the ps doc.) Well, this seems perfectly in line with what ALTO proposes: a request/response protocol for querying sources of topology information and a discovery mechanism for finding such sources. How to provide topology information -- in form of Vivaldi-like coordinates, for example, or as a "sorting oracle" -- is not going to be discussed now, but will be decided by the working group (if we manage to have one approved). The only difference I can see is that we want to design such mechanisms in order to allow also non-operator third-parties to provide the same kind of service, but I think this would not be an issue for you either. -- Ciao, Enrico --------------ms020704010607050509070300 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDkxNTA1MTRaMCMG CSqGSIb3DQEJBDEWBBSLy1xrwaCN/hZrL3umls7pF34ZhTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABBVAB1DOIC5 zivrmRa/LZNt8RyuSQXreB32I/jKtBOtxh9dP2/xYuobnIv9nLtTLeI9ronTgk62pDEbO02A 0UntDIqP/qPUrBn9NsaxsrHvlMn9FYC4+LwE50OQOrVIJHHJLjLE2kHNNLJPW6Fky4B274dt ElP0nOBWEG/j3/jNgDbL+Ilf5g2ei0aZGfHXNQEMIJKrNZtUq7/Azq3o2rstQzPl2AJeYeF8 uwOhjIhMMRiS5un30SvoY0nXIxDIuyAtNRnyBgUKoHnptPgB+OO7jqExLlOiA8A2xdayTjbh 1dUt4M40XBRErIJlhqQBikks3iKZxcXned+T/AKu4+AAAAAAAAA= --------------ms020704010607050509070300-- --===============0705898945== 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 --===============0705898945==-- From p2pi-bounces@ietf.org Wed Jul 9 08:23: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 87D903A6913; Wed, 9 Jul 2008 08:23: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 DCCA13A6AB2 for ; Wed, 9 Jul 2008 08:23:16 -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 FrtDTHSsM6F4 for ; Wed, 9 Jul 2008 08:23:16 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id C50433A6884 for ; Wed, 9 Jul 2008 08:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:mime-version:to:cc:subject:references: in-reply-to:content-type:content-transfer-encoding; q=dns/txt; s= selucl; bh=82If8CGKnclag3VEFKqod4GE9Hw=; b=nEBtx/jbgYp+PZpelNMl9 RGvil5QGXG71GH8Mu58jB6rmtqL+yKYx5a3rEL8P6W/GUWFa7fS9H629d5HCrceG xSJrRtKx5S+WggQL7d/3dS+QweQQ+dHL1Yl0Dluqthrj4XX1VhDbPnRE0sxTqUec kGsP304gTH17MbhzThdjaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=oUeaw lNdn2N2l9jlS1Mu1kqtn9VGuRkuw3mdsU9Wt59fDjLhZ2AT2voocIXpGQH64dACm FssWzVQkWLfJQkxzi6cOCrJmPJ8zzgYVWLhITH7tZdAjso55nK8aKW8Cy2Se9GF+ mS9+V0slg1I4o5cHaLJXBx8EwaYGpoFUwiO1KA= Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Wed, 9 Jul 2008 17:23:17 +0200 (CEST) Message-ID: <4874D7BD.9090401@uclouvain.be> Date: Wed, 09 Jul 2008 17:22:37 +0200 From: Damien Saucez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enrico Marocco References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <00275A5B436CA441900CB10936742A38C3EB69@FRVELSMBS22.ad2.ad.alcatel.com> <48746F2B.8000407@telecomitalia.it> <00275A5B436CA441900CB10936742A38C8742B@FRVELSMBS22.ad2.ad.alcatel.com> <4874D3AA.30909@telecomitalia.it> In-Reply-To: <4874D3AA.30909@telecomitalia.it> X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 259AF1C68A1.6DF8E X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Olivier Bonaventure , "p2pi@ietf.org" , PAPADIMITRIOU Dimitri , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Enrico Marocco wrote: >PAPADIMITRIOU Dimitri wrote: > > >>>The concept of layer independence is probably what made >>>people jump from >>>their chairs. Could you explain, possibly with some examples, what you >>>mean by it? >>> >>> >>what is meant here is that cooperation between the "application" and the >>"operators" must rely on an abstraction of the different layers >>information (in part. network) to the higher layer without having to >>know from where the information comes and its actual distribution. so >>cooperation from abstration which is a mechanism that can be used for >>topology hiding purposes (the latter is mentioned in the ps doc.) >> >> > >Well, this seems perfectly in line with what ALTO proposes: a >request/response protocol for querying sources of topology information >and a discovery mechanism for finding such sources. > good > How to provide >topology information -- in form of Vivaldi-like coordinates, for >example, or as a "sorting oracle" -- is not going to be discussed now, >but will be decided by the working group (if we manage to have one >approved). > > > maybe even with an inclusive or >The only difference I can see is that we want to design such mechanisms >in order to allow also non-operator third-parties to provide the same >kind of service, but I think this would not be an issue for you either. > > > We agree as the origine/destination has no importance, it is non-operator third-parties capable. Thanks, Damien Saucez _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 11:37: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 82BEF3A680D; Wed, 9 Jul 2008 11:37: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 BCE1E3A680D for ; Wed, 9 Jul 2008 11:37: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=[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 HT5p7Mvhrf15 for ; Wed, 9 Jul 2008 11:37:09 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id E2EA53A680C for ; Wed, 9 Jul 2008 11:37:08 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so782050yxg.49 for ; Wed, 09 Jul 2008 11:37:21 -0700 (PDT) Received: by 10.115.73.20 with SMTP id a20mr9759095wal.213.1215628640540; Wed, 09 Jul 2008 11:37:20 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id n37sm12567828wag.43.2008.07.09.11.37.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Jul 2008 11:37:19 -0700 (PDT) Message-Id: <929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> From: Stanislav Shalunov To: Damien Saucez In-Reply-To: <48739643.4090409@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 11:37:16 -0700 References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Jul 8, 2008, at 9:30 AM, Damien Saucez wrote: > However, we think that it is really important to focus ALTO on all > the applications and not on to say "ok, ALTO works also with other > applications than P2P". How can you focus on all? You focus on something specific, or you don't focus at all. A BoF without focus is less likely to be successful. You seem to be objecting to the fact that the problem has a real-world motivator. If it did not, it would not be worth solving for the IETF. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 13:59: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 517D33A6B57; Wed, 9 Jul 2008 13:59: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 6C9AF3A6B6B for ; Wed, 9 Jul 2008 13:59:54 -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 wR-7S-MgiK+X for ; Wed, 9 Jul 2008 13:59:53 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 85B0C3A6B57 for ; Wed, 9 Jul 2008 13:59:53 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (unknown [10.1.3.4]) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Wed, 9 Jul 2008 23:00:02 +0200 (CEST) Received: from 88.197.224.149 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Wed, 9 Jul 2008 23:00:02 +0200 (CEST) Message-ID: In-Reply-To: <929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> <929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> Date: Wed, 9 Jul 2008 23:00:02 +0200 (CEST) From: "Damien Saucez" To: "Stanislav Shalunov" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Squirrel authenticated, X-MailScanner-ID: D5CCCEC1CE.7E8C7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Jul 8, 2008, at 9:30 AM, Damien Saucez wrote: >> However, we think that it is really important to focus ALTO on all >> the applications and not on to say "ok, ALTO works also with other >> applications than P2P". > > > How can you focus on all? You focus on something specific, or you > don't focus at all. > I rephrase: focus on being general. In other word: take care of not solving a subset of the problem that can be solved. > A BoF without focus is less likely to be successful. You seem to be > objecting to the fact that the problem has a real-world motivator. Not at all, I agree that an important problem exists with P2P and that it is a real-world problem. Once again: I agree that there is a problem and what I say is that it could be interesting to solve the problem using techniques able to solve other equivalent problem (even if they not seem to be equivalent). But, for that, it is important to be aware of the other problems (Stefano could be the "bridge" between P2P and routing). > If > it did not, it would not be worth solving for the IETF. > > -- > Stanislav Shalunov > http://shlang.com > > So, to close the thread: let's keep ALTO as it is for the moment, just keep in mind for later that ALTO is also interesting in the routing world and maybe other worlds. Cheers, Damien Saucez _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 9 16:47: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 311DC3A684B; Wed, 9 Jul 2008 16:47: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 6EADD3A684B for ; Wed, 9 Jul 2008 16:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3S1-rE1N+PY for ; Wed, 9 Jul 2008 16:47:12 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 68C283A67FE for ; Wed, 9 Jul 2008 16:47:12 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1521571and.122 for ; Wed, 09 Jul 2008 16:47:23 -0700 (PDT) Received: by 10.100.166.10 with SMTP id o10mr7150751ane.0.1215647243461; Wed, 09 Jul 2008 16:47:23 -0700 (PDT) Received: by 10.100.8.15 with HTTP; Wed, 9 Jul 2008 16:47:23 -0700 (PDT) Message-ID: Date: Wed, 9 Jul 2008 16:47:23 -0700 From: "Stanislav Shalunov" To: "Damien Saucez" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48735DC8.9020709@uclouvain.be> <547F018265F92642B577B986577D671C1ACD3C@VENUS.office> <00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com> <547F018265F92642B577B986577D671C1ACD70@VENUS.office> <48739643.4090409@uclouvain.be> <929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 We're all in agreement, I believe. ALTO should be applicable to things beyond P2P. Another important problem that ALTO is applicable to is the selection of the closest CDN node. Or even finding HTTP proxies, SMTP servers, etc., etc. -- Stas On Wed, Jul 9, 2008 at 2:00 PM, Damien Saucez wrote: > > >> On Jul 8, 2008, at 9:30 AM, Damien Saucez wrote: >>> However, we think that it is really important to focus ALTO on all >>> the applications and not on to say "ok, ALTO works also with other >>> applications than P2P". >> >> >> How can you focus on all? You focus on something specific, or you >> don't focus at all. >> > I rephrase: focus on being general. In other word: take care of not > solving a subset of the problem that can be solved. > >> A BoF without focus is less likely to be successful. You seem to be >> objecting to the fact that the problem has a real-world motivator. > Not at all, I agree that an important problem exists with P2P and that it > is a real-world problem. > > Once again: I agree that there is a problem and what I say is that it > could be interesting to solve the problem using techniques able to solve > other equivalent problem (even if they not seem to be equivalent). But, > for that, it is important to be aware of the other problems (Stefano could > be the "bridge" between P2P and routing). > >> If >> it did not, it would not be worth solving for the IETF. >> >> -- >> Stanislav Shalunov >> http://shlang.com >> >> > > So, to close the thread: let's keep ALTO as it is for the moment, just > keep in mind for later that ALTO is also interesting in the routing world > and maybe other worlds. > > Cheers, > > Damien Saucez > > -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 10 00:22: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 DEBDD3A687C; Thu, 10 Jul 2008 00:22: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 EC57A3A687C for ; Thu, 10 Jul 2008 00:22:21 -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 axHaekX06Aur for ; Thu, 10 Jul 2008 00:22:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BC9E73A682E for ; Thu, 10 Jul 2008 00:22:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5CEB82C0012A0; Thu, 10 Jul 2008 09:22:34 +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 XD2efgHD12t2; Thu, 10 Jul 2008 09:22:34 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id EAEC52C00035A; Thu, 10 Jul 2008 09:22:18 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Jul 2008 09:22:14 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjiBtbQJvsneJ23QvaHEv8Aij/FkAAVkJFA References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> From: "Saverio Niccolini" To: "Damien Saucez" , "Stanislav Shalunov" Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 can you focus on all? You focus on something specific, or you > > don't focus at all. > > > I rephrase: focus on being general. In other word: take care > of not solving a subset of the problem that can be solved. What you propose is not IETF. IETF WGs solve a specific problem, that is what the charter is for. A general charter will never be approved for a WG. Thus I think we should stop discussing this "general is nice" because will not lead anywhere for ALTO (since we are in the IETF, if you want to write a paper and submit to a conference/magazine maybe it is fine) Saverio > > > A BoF without focus is less likely to be successful. You > seem to be > > objecting to the fact that the problem has a real-world motivator. > Not at all, I agree that an important problem exists with P2P > and that it is a real-world problem. > > Once again: I agree that there is a problem and what I say is > that it could be interesting to solve the problem using > techniques able to solve other equivalent problem (even if > they not seem to be equivalent). But, for that, it is > important to be aware of the other problems (Stefano could be > the "bridge" between P2P and routing). > > > If > > it did not, it would not be worth solving for the IETF. > > > > -- > > Stanislav Shalunov > > http://shlang.com > > > > > > So, to close the thread: let's keep ALTO as it is for the > moment, just keep in mind for later that ALTO is also > interesting in the routing world and maybe other worlds. > > Cheers, > > Damien Saucez > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ 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 Thu Jul 10 07:38: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 323FF3A6A4E; Thu, 10 Jul 2008 07:38: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 2BAAA3A6A4B for ; Thu, 10 Jul 2008 07:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=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 DoYHLv9lfuWS for ; Thu, 10 Jul 2008 07:38:53 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 6EE6B3A6A4E for ; Thu, 10 Jul 2008 07:38:51 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m6AEd3AO015989; Thu, 10 Jul 2008 16:39:03 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 10 Jul 2008 16:39:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 16:38:41 +0200 Message-ID: <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjiBtbQJvsneJ23QvaHEv8Aij/FkAAVkJFAAAPInDA= References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> From: "PAPADIMITRIOU Dimitri" To: "Saverio Niccolini" , "Damien Saucez" , "Stanislav Shalunov" X-OriginalArrivalTime: 10 Jul 2008 14:39:03.0009 (UTC) FILETIME=[B2A57D10:01C8E29A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 this thread, i see the following trend: 1. mechanisms for enabling a request/response protocol for querying sources of topology information and mechanism for discovering such sources are within ALTO scope - decision on the actual mechanism will be discussed in the course of the working group. 2. applicative scope is "ALTO targets applications dealing with resources available at multiple locations." - with terminology to be updated (in case). mechanisms/solutions target these apps (without preventing larger applicability). -> if BoF chairs can confirm whether this is case or not, this would greatly help progressing the debate -d. > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Saverio Niccolini > Sent: Thursday, July 10, 2008 9:22 AM > To: Damien Saucez; Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > > > How can you focus on all? You focus on something > specific, or you > > > don't focus at all. > > > > > I rephrase: focus on being general. In other word: take care > > of not solving a subset of the problem that can be solved. > > What you propose is not IETF. > > IETF WGs solve a specific problem, that is what the charter is for. > A general charter will never be approved for a WG. > > Thus I think we should stop discussing this "general is nice" > because will not lead anywhere for ALTO (since we are in the IETF, > if you want to write a paper and submit to a conference/magazine > maybe it is fine) > > Saverio > > > > > > A BoF without focus is less likely to be successful. You > > seem to be > > > objecting to the fact that the problem has a real-world motivator. > > Not at all, I agree that an important problem exists with P2P > > and that it is a real-world problem. > > > > Once again: I agree that there is a problem and what I say is > > that it could be interesting to solve the problem using > > techniques able to solve other equivalent problem (even if > > they not seem to be equivalent). But, for that, it is > > important to be aware of the other problems (Stefano could be > > the "bridge" between P2P and routing). > > > > > If > > > it did not, it would not be worth solving for the IETF. > > > > > > -- > > > Stanislav Shalunov > > > http://shlang.com > > > > > > > > > > So, to close the thread: let's keep ALTO as it is for the > > moment, just keep in mind for later that ALTO is also > > interesting in the routing world and maybe other worlds. > > > > Cheers, > > > > Damien Saucez > > > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > > > > > ============================================================ > Dr. Saverio Niccolini > Manager, Real-Time Communications Group > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > 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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 10 07:56: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 7ABC43A688A; Thu, 10 Jul 2008 07:56: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 B12623A6891 for ; Thu, 10 Jul 2008 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=0.232, 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 szv95w5PhLYl for ; Thu, 10 Jul 2008 07:56:55 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id 652D43A688A for ; Thu, 10 Jul 2008 07:56:52 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 16:57:05 +0200 Received: from GRFHUB704RM001.griffon.local ([10.19.3.67]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 16:57:05 +0200 Received: from [10.229.8.97] (10.229.8.97) by smtp.telecomitalia.it (10.19.3.68) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 10 Jul 2008 16:57:05 +0200 Message-ID: <48762327.1030404@telecomitalia.it> Date: Thu, 10 Jul 2008 16:56:39 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 10 Jul 2008 14:57:05.0671 (UTC) FILETIME=[37F69970:01C8E29D] Cc: "p2pi@ietf.org" , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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="===============0826509653==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0826509653== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030300020900040406070106" --------------ms030300020900040406070106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PAPADIMITRIOU Dimitri wrote: > from this thread, i see the following trend: > > 1. mechanisms for enabling a request/response protocol for querying > sources of topology information and mechanism for discovering such > sources are within ALTO scope - decision on the actual mechanism will be > discussed in the course of the working group. > > 2. applicative scope is "ALTO targets applications dealing with > resources available at multiple locations." - with terminology to be > updated (in case). mechanisms/solutions target these apps (without > preventing larger applicability). > > > -> if BoF chairs can confirm whether this is case or not, this would > greatly help progressing the debate According to me, this reflects pretty well the interest expressed by the group. -- Ciao, Enrico --------------ms030300020900040406070106 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTAxNDU2MzlaMCMG CSqGSIb3DQEJBDEWBBRNlXesCg7TqZO6wN9mPdqPD/JpvjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAJnCcIE/V/ql TY70jhj8/R67xY5k5e1X785zO77vGQAZJpMGdTpeBxahZeRJD5znsVFkphOeNpp6EuJ63I1U qnbsdfOVuB/rQfqOfu5xAfOBDqo4byOj0oN5gNw0RcQCVlg6EZXpsdMTWOvTmSJUW/N+V8M+ ehgReEpyVy7XvPzfrZ9CrrPZVR3WB2yPcGPEne5GVmPk07Q5wpP5fsGWNnU73gNgRDyGTn05 GMtMZoWyv18z2qM4cZvnwyOwpnkc7oeK8WIrsYfjoA37FmguZuCCqQ6U7K/EXSCq0M67VUy3 kuiIBZlNC/PZQe8mL1aEKtSNd9zYDzGkxdE/KARNOJoAAAAAAAA= --------------ms030300020900040406070106-- --===============0826509653== 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 --===============0826509653==-- From p2pi-bounces@ietf.org Thu Jul 10 08:11: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 0592D3A68EA; Thu, 10 Jul 2008 08:11: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 C00CD3A68E5 for ; Thu, 10 Jul 2008 08:11:03 -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 hH54AhRY8-5L for ; Thu, 10 Jul 2008 08:11:02 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 830BD3A685A for ; Thu, 10 Jul 2008 08:10:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jul 2008 08:10:55 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 08:11:05 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 08:11:04 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Jul 2008 11:10:58 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Jul 2008 15:06:21 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 10 Jul 2008 08:06:06 -0700 From: Reinaldo Penno To: Enrico Marocco , PAPADIMITRIOU Dimitri Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjinnoGv02PaQfQGEWudzRrY1HB+g== In-Reply-To: <48762327.1030404@telecomitalia.it> Mime-version: 1.0 X-OriginalArrivalTime: 10 Jul 2008 15:10:58.0687 (UTC) FILETIME=[287AC0F0:01C8E29F] Cc: "p2pi@ietf.org" , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 would like some clarification. I'm not sure I follow the first paragraph as in "querying sources of topology information" and "discovering such sources". My understanding was (using P2P terminology) that ALTO would provide means for a client/peer to query a ALTO 'server' and get list of metrics (whatever they are) related to a list of peers given by the client. The client would make some decision based on such metrics. Or a client might give such a list to the ALTO server and ask such a list to be ordered according to some policy. Of course the same list would be ordered differently if the purpose is streaming media, file sharing, replication or others. Is an ALTO 'server' a 'source of topology information'? Topology information related to peers/clients holding/providing content/resources or something else? Thanks, Reinaldo On 7/10/08 7:56 AM, "Enrico Marocco" wrote: > PAPADIMITRIOU Dimitri wrote: >> from this thread, i see the following trend: >> >> 1. mechanisms for enabling a request/response protocol for querying >> sources of topology information and mechanism for discovering such >> sources are within ALTO scope - decision on the actual mechanism will be >> discussed in the course of the working group. >> >> 2. applicative scope is "ALTO targets applications dealing with >> resources available at multiple locations." - with terminology to be >> updated (in case). mechanisms/solutions target these apps (without >> preventing larger applicability). >> >> >> -> if BoF chairs can confirm whether this is case or not, this would >> greatly help progressing the debate > > According to me, this reflects pretty well the interest expressed by the > group. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 10 08:26: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 56E663A680E; Thu, 10 Jul 2008 08:26: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 BD4BF3A68AB for ; Thu, 10 Jul 2008 08:26:38 -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 YE4t3nfVA40d for ; Thu, 10 Jul 2008 08:26:37 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5BAF73A680E for ; Thu, 10 Jul 2008 08:26:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0F85C2C00C338; Thu, 10 Jul 2008 17:26:52 +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 x8Wa25stJd-1; Thu, 10 Jul 2008 17:26:51 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D2AAC2C00035A; Thu, 10 Jul 2008 17:26:31 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Jul 2008 17:26:30 +0200 Message-ID: <547F018265F92642B577B986577D671C1ACFBB@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjinnoGv02PaQfQGEWudzRrY1HB+gAAVhHQ References: <48762327.1030404@telecomitalia.it> From: "Saverio Niccolini" To: "Reinaldo Penno" , "Enrico Marocco" , "PAPADIMITRIOU Dimitri" Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 ALTO server (or whatever logical function, that in literature is called "topology oracle" as far as I know) can be one of the source of information that enables Application Layer Traffic Optimization. What it is holding/providing and how will be decided once ALTO is chartered and we have a WG that works on that, I do not think this can be decided (nor should be) before or within the BoF. We should not even discuss this here now. Correct me if I am wrong, Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Thursday, July 10, 2008 5:06 PM > To: Enrico Marocco; PAPADIMITRIOU Dimitri > Cc: p2pi@ietf.org; Saverio Niccolini > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > I would like some clarification. > > I'm not sure I follow the first paragraph as in "querying > sources of topology information" and "discovering such sources". > > My understanding was (using P2P terminology) that ALTO would > provide means for a client/peer to query a ALTO 'server' and > get list of metrics (whatever they are) related to a list of > peers given by the client. The client would make some > decision based on such metrics. > > Or a client might give such a list to the ALTO server and ask > such a list to be ordered according to some policy. Of > course the same list would be ordered differently if the > purpose is streaming media, file sharing, replication or others. > > Is an ALTO 'server' a 'source of topology information'? > Topology information related to peers/clients > holding/providing content/resources or something else? > > Thanks, > > Reinaldo > > > On 7/10/08 7:56 AM, "Enrico Marocco" > wrote: > > > PAPADIMITRIOU Dimitri wrote: > >> from this thread, i see the following trend: > >> > >> 1. mechanisms for enabling a request/response protocol for > querying > >> sources of topology information and mechanism for discovering such > >> sources are within ALTO scope - decision on the actual > mechanism will > >> be discussed in the course of the working group. > >> > >> 2. applicative scope is "ALTO targets applications dealing with > >> resources available at multiple locations." - with > terminology to be > >> updated (in case). mechanisms/solutions target these apps (without > >> preventing larger applicability). > >> > >> > >> -> if BoF chairs can confirm whether this is case or not, > this would > >> greatly help progressing the debate > > > > According to me, this reflects pretty well the interest > expressed by > > the group. > > _______________________________________________ > 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 Jul 10 08:29:53 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 BB8EB3A683C; Thu, 10 Jul 2008 08:29:53 -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 446293A683C for ; Thu, 10 Jul 2008 08:29:52 -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 4Yd5O6e4xWhV for ; Thu, 10 Jul 2008 08:29:51 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id CB3D03A680E for ; Thu, 10 Jul 2008 08:29:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 297DBE10AFA; Thu, 10 Jul 2008 11:30: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 ipdgsoea3OEs; Thu, 10 Jul 2008 11:29:55 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id AF3C2E10B0D; Thu, 10 Jul 2008 11:29:55 -0400 (EDT) Date: Thu, 10 Jul 2008 11:29:55 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <365756032.496601215703795684.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 A few comments below. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Enrico Marocco" , "PAPADIMITRIOU Dimitri" Cc: p2pi@ietf.org, "Saverio Niccolini" Sent: Thursday, July 10, 2008 11:06:06 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem I would like some clarification. I'm not sure I follow the first paragraph as in "querying sources of topology information" and "discovering such sources". My understanding was (using P2P terminology) that ALTO would provide means for a client/peer to query a ALTO 'server' and get list of metrics (whatever they are) related to a list of peers given by the client. The client would make some decision based on such metrics. LP: The ALTO query could also come from a 'server' as well as a 'peer' in the p2p network. Also, the list provided by the ALTO client is of what I'd suggest we call network locations, not peers. For example, they could be a list of IP prefixes or ASNs. This is an important distinction, in order to preserve the privacy of the p2p network's users. Or a client might give such a list to the ALTO server and ask such a list to be ordered according to some policy. Of course the same list would be ordered differently if the purpose is streaming media, file sharing, replication or others. Is an ALTO 'server' a 'source of topology information'? Topology information related to peers/clients holding/providing content/resources or something else? LP: I would say that there are two layers of communication that ALTO needs to address. One layer is between the ALTO client (e.g. p2p app, p2p server) and the ALTO server, and the second is between the ALTO server and the source of network topology information (e.g. ISP, third-party). Thanks, Reinaldo On 7/10/08 7:56 AM, "Enrico Marocco" wrote: > PAPADIMITRIOU Dimitri wrote: >> from this thread, i see the following trend: >> >> 1. mechanisms for enabling a request/response protocol for querying >> sources of topology information and mechanism for discovering such >> sources are within ALTO scope - decision on the actual mechanism will be >> discussed in the course of the working group. >> >> 2. applicative scope is "ALTO targets applications dealing with >> resources available at multiple locations." - with terminology to be >> updated (in case). mechanisms/solutions target these apps (without >> preventing larger applicability). >> >> >> -> if BoF chairs can confirm whether this is case or not, this would >> greatly help progressing the debate > > According to me, this reflects pretty well the interest expressed by the > group. _______________________________________________ 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 Jul 10 08:31: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 D9AAD3A683C; Thu, 10 Jul 2008 08:31: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 85D383A6891 for ; Thu, 10 Jul 2008 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 5TlFk1Qtz8vD for ; Thu, 10 Jul 2008 08:31:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 91CEA3A69CA for ; Thu, 10 Jul 2008 08:31:09 -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 m6AFVNnL005961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 10:31:24 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6AFVKjV000609; Thu, 10 Jul 2008 10:31:20 -0500 (CDT) Message-ID: <48762B4B.4040102@alcatel-lucent.com> Date: Thu, 10 Jul 2008 10:31:23 -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: Reinaldo Penno References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Reinaldo Penno wrote: > Is an ALTO 'server' a 'source of topology information'? Topology > information related to peers/clients holding/providing > content/resources or something else? Reinaldo: Insofar as the benefits of having an ALTO server be the source of topology information instead of each peer trying to figure this out, please see the discussion in the ALTO survey paper in Section 3 (http://tools.ietf.org/html/draft-hilt-alto-survey-00#section-3). Now, regarding what type of information the ALTO server will maintain and to what extent will it be cognizant of the specific application protocol of the peer (BitTorrent and its content- hashes, P2PSIP's need to find the nearest relay, etc.) -- I don't know that we have a concrete answer on these yet at this stage of the game. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Thu Jul 10 12:54: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 839CB3A6A83; Thu, 10 Jul 2008 12:54: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 2199F3A6A83 for ; Thu, 10 Jul 2008 12:54:41 -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 XeCPq+w+mwb8 for ; Thu, 10 Jul 2008 12:54:40 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 203EA3A68D8 for ; Thu, 10 Jul 2008 12:54:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jul 2008 12:54:54 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 12:54:12 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 12:54:11 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 15:54:10 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Jul 2008 19:54:06 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 10 Jul 2008 12:53:48 -0700 From: Reinaldo Penno To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjixqr6xku3wqvMIkmalL407XFzzw== In-Reply-To: <48762B4B.4040102@alcatel-lucent.com> Mime-version: 1.0 X-OriginalArrivalTime: 10 Jul 2008 19:54:10.0611 (UTC) FILETIME=[B8749830:01C8E2C6] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Thanks for the answer. I still need to catch up. A few comments inline. On 7/10/08 8:31 AM, "Vijay K. Gurbani" wrote: > Reinaldo Penno wrote: >> Is an ALTO 'server' a 'source of topology information'? Topology >> information related to peers/clients holding/providing >> content/resources or something else? > > Reinaldo: Insofar as the benefits of having an ALTO server be the > source of topology information instead of each peer trying to > figure this out, please see the discussion in the ALTO survey > paper in Section 3 > (http://tools.ietf.org/html/draft-hilt-alto-survey-00#section-3). Thanks for the pointer, I believe I was alluding to something else. I was trying to point out as a problem statement for ALTO that given a set of metrics for peers or network locations provided by the 'server', who should order the list? Will the list be ordered by the ALTO 'server' and the client consumes it as it sees fit. And/Or the ALTO server provides the metrics and the client decides how to use/interpret the metrics? It is worth mentioning that in this example the client is not really doing any measurements, it is a matter of how information is consumed by client and provided by the server. So, even if we assume the server would provide the info, we still reach a decision point of two (or more) possibilities. Thanks, Reinaldo > > Now, regarding what type of information the ALTO server will > maintain and to what extent will it be cognizant of the specific > application protocol of the peer (BitTorrent and its content- > hashes, P2PSIP's need to find the nearest relay, etc.) -- I don't > know that we have a concrete answer on these yet at this stage > of the game. > > Thanks, > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 10 13:02: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 302303A6862; Thu, 10 Jul 2008 13:02: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 309003A692A for ; Thu, 10 Jul 2008 13:02:20 -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 feOfeSrw25MM for ; Thu, 10 Jul 2008 13:02:19 -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 C0BD53A6862 for ; Thu, 10 Jul 2008 13:02:18 -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 m6AK2XM15794; Thu, 10 Jul 2008 22:02:33 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp525.cisco.com [10.61.66.13]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6AK2IA08600; Thu, 10 Jul 2008 22:02:18 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 10 Jul 2008 22:02:02 +0200 From: stefano previdi To: Reinaldo Penno , "Vijay K. Gurbani" Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjixqr6xku3wqvMIkmalL407XFzzwAASZwp In-Reply-To: Mime-version: 1.0 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Reinaldo Penno > > Thanks for the answer. I still need to catch up. > > A few comments inline. > > > On 7/10/08 8:31 AM, "Vijay K. Gurbani" wrote: > >> Reinaldo Penno wrote: >>> Is an ALTO 'server' a 'source of topology information'? Topology >>> information related to peers/clients holding/providing >>> content/resources or something else? >> >> Reinaldo: Insofar as the benefits of having an ALTO server be the >> source of topology information instead of each peer trying to >> figure this out, please see the discussion in the ALTO survey >> paper in Section 3 >> (http://tools.ietf.org/html/draft-hilt-alto-survey-00#section-3). > > > Thanks for the pointer, I believe I was alluding to something else. I was > trying to point out as a problem statement for ALTO that given a set of > metrics for peers or network locations provided by the 'server', who should > order the list? Will the list be ordered by the ALTO 'server' and the client > consumes it as it sees fit. > > And/Or the ALTO server provides the metrics and the client decides how to > use/interpret the metrics? couldn't this be an optional argument of the request ? I know an implementation that gives both types of information: - metric - ranking and then the consumer of the service decides on its own. > It is worth mentioning that in this example the client is not really doing > any measurements, it is a matter of how information is consumed by client > and provided by the server. yes. > So, even if we assume the server would provide the info, we still reach a > decision point of two (or more) possibilities. indeed... we have more possibilities... s. > > Thanks, > > Reinaldo > > >> >> Now, regarding what type of information the ALTO server will >> maintain and to what extent will it be cognizant of the specific >> application protocol of the peer (BitTorrent and its content- >> hashes, P2PSIP's need to find the nearest relay, etc.) -- I don't >> know that we have a concrete answer on these yet at this stage >> of the game. >> >> Thanks, >> >> - vijay > > _______________________________________________ > 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 Jul 11 00:21: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 A35EB3A6947; Fri, 11 Jul 2008 00:21: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 AA7A63A6947 for ; Fri, 11 Jul 2008 00:21:37 -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 cRjf46L84Ndl for ; Fri, 11 Jul 2008 00:21:36 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id B144B3A635F for ; Fri, 11 Jul 2008 00:21:36 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6B7LkfX028649; Fri, 11 Jul 2008 03:21:47 -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 m6B7Lkc9016147; Fri, 11 Jul 2008 03:21:46 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6B7LjVY016144; Fri, 11 Jul 2008 03:21:45 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Fri, 11 Jul 2008 03:21:45 -0400 (EDT) From: Salman Abdul Baset To: Enrico Marocco In-Reply-To: <48762327.1030404@telecomitalia.it> Message-ID: References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> 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" , PAPADIMITRIOU Dimitri , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Thu, 10 Jul 2008, Enrico Marocco wrote: > PAPADIMITRIOU Dimitri wrote: >> from this thread, i see the following trend: >> >> 1. mechanisms for enabling a request/response protocol for querying >> sources of topology information and mechanism for discovering such >> sources are within ALTO scope - decision on the actual mechanism will be >> discussed in the course of the working group. >> >> 2. applicative scope is "ALTO targets applications dealing with >> resources available at multiple locations." - with terminology to be >> updated (in case). mechanisms/solutions target these apps (without >> preventing larger applicability). >> >> >> -> if BoF chairs can confirm whether this is case or not, this would >> greatly help progressing the debate > > According to me, this reflects pretty well the interest expressed by the > group. > For (1), "the request/response protocol can be used to query sources of topology and 'network' information". The 'network' is important because a machine connected to a ethernet switch/hub which in turn is connected to a DSL/cable modem cannot determine the access link speed in a straightforward way. This information is helpful when selecting a relay node for VoIP/video, for example. -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 01:20: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 8F59F3A6ADA; Fri, 11 Jul 2008 01:20: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 814DC3A69ED for ; Fri, 11 Jul 2008 01:20:32 -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 rtzsZrHmmpK9 for ; Fri, 11 Jul 2008 01:20:31 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id D216F3A6B0C for ; Fri, 11 Jul 2008 01:20:30 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 10:20:46 +0200 Received: from GRFHUB703BA020.griffon.local ([10.188.101.113]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 10:20:46 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.116) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 11 Jul 2008 10:20:45 +0200 Message-ID: <487717E2.4090801@telecomitalia.it> Date: Fri, 11 Jul 2008 10:20:50 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "p2pi@ietf.org" X-OriginalArrivalTime: 11 Jul 2008 08:20:46.0019 (UTC) FILETIME=[04996930:01C8E32F] Subject: [p2pi] Charter and problem statement 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="===============0700616420==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0700616420== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070308040105090600030202" --------------ms070308040105090600030202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Vijay and I have put together a first draft of the charter, trying to capture how people on this list think an IETF working group should address the ALTO problem. It is available at the following link: http://alto.tilab.com/docs/charter.txt Please take a look and comment. An updated version of the problem statement is also available: http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-02.txt Changes should reflect comments received in regards to the previous version, including a more accurate description of how caching relates to ALTO. We are aware that terminology may need to be revised (as pointed out by Dimitri). As usual, you can use IETF tools to visualize diffs: http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-marocco-alto-problem-statement-01&url2=http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-02.txt -- Ciao, Enrico --------------ms070308040105090600030202 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTEwODIwNTBaMCMG CSqGSIb3DQEJBDEWBBQyTS5//f6saQ3EigmrdBlmNwnrfjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAFKDvedzK2bc O4G+z2K3Sqd14DnB7RiIiNGl22wjb4PijChVDKPdGth0DGU3MAp5uOFVtrypU8Hfwxo9+Liq ZCb9TPq3eh2CSKjKfjbIw8kJV9SuFyl5n91T5k5bkuhouXbo4EH0DuhdROXrqvKyCPKfG9HU +2yqSuRovd2BOglItzDay2+80ENA6HzMpzblAleb2+BSg9+zttK/xmaEgtXekzuWCsO5oWos Txeoti3DaxoNQ6mrFeVdgtpI+Xjin7/JFELJOCneIx7zWQIS+HrQSljHzDScWGq0RoEn7+hI /m9hcO2wv0CrnLg9LTT1Vtfk+jQJeRMvVjogQxYi4MYAAAAAAAA= --------------ms070308040105090600030202-- --===============0700616420== 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 --===============0700616420==-- From p2pi-bounces@ietf.org Fri Jul 11 01:56: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 010523A6A1C; Fri, 11 Jul 2008 01:56: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 4C29628C147 for ; Fri, 11 Jul 2008 01:56: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 0hOfMmPSlqQL for ; Fri, 11 Jul 2008 01:56:01 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 5C7873A6A1C for ; Fri, 11 Jul 2008 01:56:01 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3893495wfd.31 for ; Fri, 11 Jul 2008 01:56:18 -0700 (PDT) Received: by 10.142.156.2 with SMTP id d2mr2968728wfe.271.1215766578003; Fri, 11 Jul 2008 01:56:18 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 24sm656337wfc.19.2008.07.11.01.56.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Jul 2008 01:56:17 -0700 (PDT) Message-Id: <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> From: Stanislav Shalunov To: p2pi@ietf.org In-Reply-To: <487717E2.4090801@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 01:56:14 -0700 References: <487717E2.4090801@telecomitalia.it> X-Mailer: Apple Mail (2.926) Subject: Re: [p2pi] Charter and problem statement 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 Jul 11, 2008, at 1:20 AM, Enrico Marocco wrote: > Vijay and I have put together a first draft of the charter, trying to > capture how people on this list think an IETF working group should > address the ALTO problem. It is available at the following link: > http://alto.tilab.com/docs/charter.txt Thank you for putting together the charter well enough ahead of the BoF that we have time to discuss it. The general problem of overlay routing and how to best expose information for it is big and hard. The problem of caching, on the other hand, is well-defined, easily scoped, and easy to agree on. Cache tracker location is a pure and simple engineering problem. Routing information exposure has a substantial research component. This charter does not let the possible WG solve the easy problem -- in fact, it does not even contain the word "cache". Instead, it proposes a particular solution (oracle) for the more complicated routing information exposure problem, before the problem has even been scoped. Further, the chartered oracle location service is of exactly the same nature and complexity as the non-chartered cache tracker location service. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 03:15: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 1A15B28C181; Fri, 11 Jul 2008 03:15: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 F19AD28C174 for ; Fri, 11 Jul 2008 03:15:23 -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 VaGVWXFnmW7K for ; Fri, 11 Jul 2008 03:15:22 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6E6AD28C17C for ; Fri, 11 Jul 2008 03:15:22 -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 m6BAFbnQ027792; Fri, 11 Jul 2008 06:15:37 -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 m6BAFbP5006073; Fri, 11 Jul 2008 06:15:37 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6BAFbFJ006070; Fri, 11 Jul 2008 06:15:37 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Fri, 11 Jul 2008 06:15:36 -0400 (EDT) From: Salman Abdul Baset To: Stanislav Shalunov In-Reply-To: <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> Message-ID: References: <487717E2.4090801@telecomitalia.it> <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@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.8 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 In addition to comments by Stanislav, a question to be considered is whether the signaling protocol should support cooperation of oracles in addition to querying of oracle. Is there a need for such cooperation? -s On Fri, 11 Jul 2008, Stanislav Shalunov wrote: > On Jul 11, 2008, at 1:20 AM, Enrico Marocco wrote: >> Vijay and I have put together a first draft of the charter, trying to >> capture how people on this list think an IETF working group should >> address the ALTO problem. It is available at the following link: >> http://alto.tilab.com/docs/charter.txt > > Thank you for putting together the charter well enough ahead of the BoF that > we have time to discuss it. > > > The general problem of overlay routing and how to best expose information for > it is big and hard. > > The problem of caching, on the other hand, is well-defined, easily scoped, > and easy to agree on. Cache tracker location is a pure and simple > engineering problem. Routing information exposure has a substantial research > component. > > This charter does not let the possible WG solve the easy problem -- in fact, > it does not even contain the word "cache". Instead, it proposes a particular > solution (oracle) for the more complicated routing information exposure > problem, before the problem has even been scoped. > > Further, the chartered oracle location service is of exactly the same nature > and complexity as the non-chartered cache tracker location service. > > -- > Stanislav Shalunov > http://shlang.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 Fri Jul 11 07:06: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 35D593A67DD; Fri, 11 Jul 2008 07:06: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 BFF583A6A37 for ; Fri, 11 Jul 2008 07:06:12 -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 Ybm5IH2w+JX7 for ; Fri, 11 Jul 2008 07:06:12 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 260383A695D for ; Fri, 11 Jul 2008 07:06:10 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 16:06:27 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 16:06:26 +0200 Received: from [172.16.79.10] (163.162.173.95) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 11 Jul 2008 16:06:25 +0200 Message-ID: <487768E6.8080804@telecomitalia.it> Date: Fri, 11 Jul 2008 16:06:30 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stanislav Shalunov References: <487717E2.4090801@telecomitalia.it> <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> In-Reply-To: <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> X-OriginalArrivalTime: 11 Jul 2008 14:06:26.0405 (UTC) FILETIME=[4ED52950:01C8E35F] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============0219271409==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0219271409== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070202000908010101030901" --------------ms070202000908010101030901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stanislav Shalunov wrote: > The general problem of overlay routing and how to best expose > information for it is big and hard. > > The problem of caching, on the other hand, is well-defined, easily > scoped, and easy to agree on. Cache tracker location is a pure and > simple engineering problem. Routing information exposure has a > substantial research component. > > This charter does not let the possible WG solve the easy problem -- in > fact, it does not even contain the word "cache". Instead, it proposes > a particular solution (oracle) for the more complicated routing > information exposure problem, before the problem has even been scoped. Ok, I see that the first change must be on the term "oracle". It wasn't of course meant to push any particular solution; in our mind, "oracle" could be any source of topology information, including the IDIPS "sorting oracle" as well as the P4P iTracker or the Ono/Akamai redirect server. That said, I understand caches as "special" peers that can be transparently handled by the peer selection service we are trying to standardize (as suggested in S2.1.1 of the problem statement). Alternatively, we would have to work on some sort of application-dependent cache location mechanism, which, AFAICT, is not what most people here want to pursue and I don't think is what you are proposing. Can you suggest a rewording for the current charter to best address caching issues? Finally, the survey draft references several solutions for addressing the topology information exposure problem, which have proved in the real world to be beneficial to P2P applications in the first place (and some to ISPs as well). I really don't want people to think that we are going to invent a new one; instead, what we are proposing is just to define a standard interface for existing and future peer selection optimization services, in order to ease their adoption by different P2P and non-P2P applications. If you agree, but don't see it reflected in the charter, feel free to propose alternative text. -- Ciao, Enrico --------------ms070202000908010101030901 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTExNDA2MzBaMCMG CSqGSIb3DQEJBDEWBBSEQLswvCLP9G+IQtzQA5caZ7mfNjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAFltJnmgxOJ0 CCmiiNerr+tKCx2ZHB30XvpD7dBOnyrAP6X8YE+XeuWlXJnDUXd46tWinncqAUizfqI7BPFQ m720n3bVe3AqL/hgQ+YQT4GV2Ov6jXBQZpBHYYSmWky6oaXhChjfkpS9OmWTu4952ymibZw+ eLnYnd2Jb6kXhKp9/WUG0uCruMuMhswqYhoj3XYbK47+PzMNpDJwWSbWwyPAvF7uQAvAvUPj TCLhUhIbaRSNk2Qz9DYePKECIDpOsy4UexhWYVDKp/Qqqz+VOVSVfy2l/rruD0wwNDhqbyVT 5+tqiYl9lpF5+5pAHQuTsxP960o+/kwEtUnrXyqhp+UAAAAAAAA= --------------ms070202000908010101030901-- --===============0219271409== 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 --===============0219271409==-- From p2pi-bounces@ietf.org Fri Jul 11 07:13: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 AFE993A69C2; Fri, 11 Jul 2008 07:13: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 623553A69C2 for ; Fri, 11 Jul 2008 07:13:10 -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 aBVeShQGqb9T for ; Fri, 11 Jul 2008 07:13:09 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 4B92A3A63C9 for ; Fri, 11 Jul 2008 07:13:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id A0DC6E10A30; Fri, 11 Jul 2008 10:13:26 -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 nfMSoIhT8GBD; Fri, 11 Jul 2008 10:13:22 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 4B1F9E109DE; Fri, 11 Jul 2008 10:13:22 -0400 (EDT) Date: Fri, 11 Jul 2008 10:13:22 -0400 (EDT) From: Laird Popkin To: Enrico Marocco Message-ID: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> In-Reply-To: <487768E6.8080804@telecomitalia.it> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 IMO caches are a (rather valuable) special case of the general problem of finding optimal sources of data (for data that has multiple available sources). To elaborate on this, once the ISP has an "oracle" that communicates network policies to applications, that seems like an ideal channel for communicating information about caches. Doing so explicitly and under the direction of the ISP and the support of the p2p networks seems much better than the techniques that those guys use now (e.g. multiple proprietary cache discovery protocols, or deep packet inspection and protocol hacking). As a p2p developer, I have to say that it's far more likely that we'd support a single standard cache location mechanism (especially if it gave all of the other benefits of an "oracle") than for us to test multiple proprietary cache discovery mechanisms on every download. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Enrico Marocco" To: "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Friday, July 11, 2008 10:06:30 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Charter and problem statement Stanislav Shalunov wrote: > The general problem of overlay routing and how to best expose > information for it is big and hard. > > The problem of caching, on the other hand, is well-defined, easily > scoped, and easy to agree on. Cache tracker location is a pure and > simple engineering problem. Routing information exposure has a > substantial research component. > > This charter does not let the possible WG solve the easy problem -- in > fact, it does not even contain the word "cache". Instead, it proposes > a particular solution (oracle) for the more complicated routing > information exposure problem, before the problem has even been scoped. Ok, I see that the first change must be on the term "oracle". It wasn't of course meant to push any particular solution; in our mind, "oracle" could be any source of topology information, including the IDIPS "sorting oracle" as well as the P4P iTracker or the Ono/Akamai redirect server. That said, I understand caches as "special" peers that can be transparently handled by the peer selection service we are trying to standardize (as suggested in S2.1.1 of the problem statement). Alternatively, we would have to work on some sort of application-dependent cache location mechanism, which, AFAICT, is not what most people here want to pursue and I don't think is what you are proposing. Can you suggest a rewording for the current charter to best address caching issues? Finally, the survey draft references several solutions for addressing the topology information exposure problem, which have proved in the real world to be beneficial to P2P applications in the first place (and some to ISPs as well). I really don't want people to think that we are going to invent a new one; instead, what we are proposing is just to define a standard interface for existing and future peer selection optimization services, in order to ease their adoption by different P2P and non-P2P applications. If you agree, but don't see it reflected in the charter, feel free to propose alternative text. -- 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 Jul 11 07:52: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 6D26728C181; Fri, 11 Jul 2008 07:52: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 49D9028C181 for ; Fri, 11 Jul 2008 07:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 sfFssHl0sWhP for ; Fri, 11 Jul 2008 07:52:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E781128C16F for ; Fri, 11 Jul 2008 07:52:02 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6BEpws3010527; Fri, 11 Jul 2008 17:52:08 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 17:51:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 17:51:50 +0300 Received: from net-107.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 17:51:49 +0300 Message-Id: From: Lars Eggert To: ext Salman Abdul Baset In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 17:51:43 +0300 References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 11 Jul 2008 14:51:50.0412 (UTC) FILETIME=[A677A4C0:01C8E365] X-Nokia-AV: Clean Cc: PAPADIMITRIOU Dimitri , "p2pi@ietf.org" , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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-7-11, at 10:21, ext Salman Abdul Baset wrote: > The 'network' is important because a machine connected to a ethernet > switch/hub which in turn is connected to a DSL/cable modem cannot > determine the access link speed in a straightforward way. This > information is helpful when selecting a relay node for VoIP/video, > for example. well, "helpful" is a concept I can't strongly argue with, but please note that the nominal capacity of a node's access link does not tell you anything about the currently available bandwidth, loss rates, delay, or jitter of the end-to-end path. It's not even clear that the access link is always the bottleneck for a given path. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 07:54:09 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 66F3A3A6A37; Fri, 11 Jul 2008 07:54:09 -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 ACCFC3A6A37 for ; Fri, 11 Jul 2008 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 49dGPhqokQjV for ; Fri, 11 Jul 2008 07:54:06 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id AA84B3A68A0 for ; Fri, 11 Jul 2008 07:54:06 -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 m6BErwUd001488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 09:54:02 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6BErqKW024594; Fri, 11 Jul 2008 09:53:53 -0500 (CDT) Message-ID: <48777404.4080208@alcatel-lucent.com> Date: Fri, 11 Jul 2008 09:53: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: Laird Popkin , Stanislav Shalunov References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> In-Reply-To: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 Laird Popkin wrote: > IMO caches are a (rather valuable) special case of the general > problem of finding optimal sources of data (for data that has > multiple available sources). > > To elaborate on this, once the ISP has an "oracle" that communicates > network policies to applications, that seems like an ideal channel > for communicating information about caches. Doing so explicitly and > under the direction of the ISP and the support of the p2p networks > seems much better than the techniques that those guys use now (e.g. > multiple proprietary cache discovery protocols, or deep packet > inspection and protocol hacking). As a p2p developer, I have to say > that it's far more likely that we'd support a single standard cache > location mechanism (especially if it gave all of the other benefits > of an "oracle") than for us to test multiple proprietary cache > discovery mechanisms on every download. Laird, Stanislav: I think both of you are proposing that cache- discovery be a part of ALTO. I am trying to make a distinction between /cache/ and /content/ in the context of our work. In a P2P application-based overlay, the "best" peer (however the network defines "best") is where the querying peer should be sent to get the resource in question from. If we stretch this analogy a bit further, it does not matter that the resource is mirrored (cached) at the "best" peer or it appears as the only instance of resource on the "best peer" (i.e., it is not cached.) So in cases like this, I believe that sending a querying peer to the "best" peer is immaterial of whether or not the "best" peer is a caching-only server versus a server providing original content. The content is immutable. In other applications like HTTP-based caching, it matters whether or not a cache is hit or the origin server is hit. If caching is deemed to be a part of the charter, how do we define it for ALTO? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 11 08:05: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 391563A6B33; Fri, 11 Jul 2008 08:05: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 B79403A6B2F for ; Fri, 11 Jul 2008 08:05:56 -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 raGqiU-9qH23 for ; Fri, 11 Jul 2008 08:05:55 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id B84CD28C0DC for ; Fri, 11 Jul 2008 08:05:40 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jul 2008 08:04:23 PDT Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 08:05:46 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 11:05:45 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Jul 2008 15:05:38 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 11 Jul 2008 08:05:12 -0700 From: Reinaldo Penno To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjjZ4RAZNE60uthBUKj/bsVinIKiA== In-Reply-To: <365756032.496601215703795684.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 11 Jul 2008 15:05:45.0166 (UTC) FILETIME=[9804FEE0:01C8E367] Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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, The latter does not seem to be part of the charter at this point. It certainly needs to be part of any working solution but I'm not sure if it can be easily standardized. Thanks, Reinaldo On 7/10/08 8:29 AM, "Laird Popkin" wrote: > LP: I would say that there are two layers of communication that ALTO needs to > address. One layer is between the ALTO client (e.g. p2p app, p2p server) and > the ALTO server, and the second is between the ALTO server and the source of > network topology information (e.g. ISP, third-party). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 08:10: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 84B0228C19A; Fri, 11 Jul 2008 08:10: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 8634D28C19A for ; Fri, 11 Jul 2008 08:10: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 4kAYNVIyOcs2 for ; Fri, 11 Jul 2008 08:10:39 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 4C57B28C18D for ; Fri, 11 Jul 2008 08:10:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 6BA2DE10A30; Fri, 11 Jul 2008 11:10:50 -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 rlfdmmwHLMQG; Fri, 11 Jul 2008 11:10:41 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 2149FE109DE; Fri, 11 Jul 2008 11:10:41 -0400 (EDT) Date: Fri, 11 Jul 2008 11:10:41 -0400 (EDT) From: Laird Popkin To: "Vijay K. Gurbani" Message-ID: <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> In-Reply-To: <48777404.4080208@alcatel-lucent.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] Charter and problem statement 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 For this level of discussion, I agree that caches should simply be viewed as a peer in ALTO. I would point out some differences that we'll want to discuss at some point, as I think that they'll require some mild extensions to ALTO as we've discussed it so far: - The cache servers are never part of the ALTO client request (since the p2p network doesn't know about them) but the ALTO server needs to give out exact addresses of caches in its response, since they're peers that are unknown to the p2p network. This is different from the more abstract network locations (e.g. IP prefix, ASN) that ALTO otherwise uses (IMO, anyway) in order to protect user privacy. There isn't a privacy concern with revealing the location of an ISP-run cache server to the ISP. :-) - Cache servers are protocol, application and perhaps even content specific, so that information needs to be (optionally) communicated in the ALTO request. For example, an ISP might operate BitTorrent and Pando caches, but not eDonkey caches, or it might operate different caches for different protocols on different hardware at different locations, or it might decide to cache some content (e.g. commercial content) but not other content (e.g. consumer generated content) that is transported using the same protocol and application. - There might be some additional policy information that the ISP may wish to communicate. For example, an ISP that invests heavily in caching to relieve uplink congestion might want p2p apps to use the cache servers to the exclusion of peers within the network, etc. Of course, the implementation of this is up to the p2p application, but at the least the ISP should be able to communicate preferences. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Laird Popkin" , "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Friday, July 11, 2008 10:53:56 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Charter and problem statement Laird Popkin wrote: > IMO caches are a (rather valuable) special case of the general > problem of finding optimal sources of data (for data that has > multiple available sources). > > To elaborate on this, once the ISP has an "oracle" that communicates > network policies to applications, that seems like an ideal channel > for communicating information about caches. Doing so explicitly and > under the direction of the ISP and the support of the p2p networks > seems much better than the techniques that those guys use now (e.g. > multiple proprietary cache discovery protocols, or deep packet > inspection and protocol hacking). As a p2p developer, I have to say > that it's far more likely that we'd support a single standard cache > location mechanism (especially if it gave all of the other benefits > of an "oracle") than for us to test multiple proprietary cache > discovery mechanisms on every download. Laird, Stanislav: I think both of you are proposing that cache- discovery be a part of ALTO. I am trying to make a distinction between /cache/ and /content/ in the context of our work. In a P2P application-based overlay, the "best" peer (however the network defines "best") is where the querying peer should be sent to get the resource in question from. If we stretch this analogy a bit further, it does not matter that the resource is mirrored (cached) at the "best" peer or it appears as the only instance of resource on the "best peer" (i.e., it is not cached.) So in cases like this, I believe that sending a querying peer to the "best" peer is immaterial of whether or not the "best" peer is a caching-only server versus a server providing original content. The content is immutable. In other applications like HTTP-based caching, it matters whether or not a cache is hit or the origin server is hit. If caching is deemed to be a part of the charter, how do we define it for ALTO? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 11 08:17: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 C3F1428C1B4; Fri, 11 Jul 2008 08:17: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 411B63A67E3 for ; Fri, 11 Jul 2008 08:17:55 -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 4ulQ2f9QoY5j for ; Fri, 11 Jul 2008 08:17:54 -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 BC86B28C1CE for ; Fri, 11 Jul 2008 08:17:53 -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 m6BFI3420608; Fri, 11 Jul 2008 17:18:03 +0200 (CEST) Received: from [192.168.0.100] (dhcp-10-61-97-53.cisco.com [10.61.97.53]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6BFI2A21693; Fri, 11 Jul 2008 17:18:02 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 11 Jul 2008 17:17:45 +0200 From: stefano previdi To: Reinaldo Penno , Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjjZ4RAZNE60uthBUKj/bsVinIKiAAAcDQi In-Reply-To: Mime-version: 1.0 Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Reinaldo Penno > > Hello, > > The latter does not seem to be part of the charter at this point. It > certainly needs to be part of any working solution but I'm not sure if it > can be easily standardized. I tend to agree. We could also note that, among the different mechanisms through which an ALTO server acquires topology information, we have some that are already standardized for a long time now. s. > > Thanks, > > Reinaldo > > On 7/10/08 8:29 AM, "Laird Popkin" wrote: > >> LP: I would say that there are two layers of communication that ALTO needs to >> address. One layer is between the ALTO client (e.g. p2p app, p2p server) and >> the ALTO server, and the second is between the ALTO server and the source of >> network topology information (e.g. ISP, third-party). > > _______________________________________________ > 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 Jul 11 08:21: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 C16603A68C7; Fri, 11 Jul 2008 08:21: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 6D34728C1B4 for ; Fri, 11 Jul 2008 08:21: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 bVhB9gG8QveQ for ; Fri, 11 Jul 2008 08:21:37 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id AEE5228C1C4 for ; Fri, 11 Jul 2008 08:20:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 4DBDBE10A71; Fri, 11 Jul 2008 11:21:11 -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 51JgaTtG5WbJ; Fri, 11 Jul 2008 11:21:10 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id B7698E10A5F; Fri, 11 Jul 2008 11:21:10 -0400 (EDT) Date: Fri, 11 Jul 2008 11:21:10 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <2115964082.501721215789670719.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Whether ALTO covers one or both depends on the contents of the ALTO messages, which is intentionally quite abstract at the moment. This is intentional, so that ALTO can be used to express a wide range of possible p2p optimization strategies. To express what P4P does in ALTO, for example, I could imagine that the P4P iTracker is an ALTO client to the ISP's ALTO server, and is an ALTO server to the P2P network's ALTO client, with different levels of information flowing through each ALTO client/server communication. That is, I believe, within the scope of what we expressed in the ALTO requirments. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Saverio Niccolini" , "Enrico Marocco" , "PAPADIMITRIOU Dimitri" Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem Hello, The latter does not seem to be part of the charter at this point. It certainly needs to be part of any working solution but I'm not sure if it can be easily standardized. Thanks, Reinaldo On 7/10/08 8:29 AM, "Laird Popkin" wrote: > LP: I would say that there are two layers of communication that ALTO needs to > address. One layer is between the ALTO client (e.g. p2p app, p2p server) and > the ALTO server, and the second is between the ALTO server and the source of > network topology information (e.g. ISP, third-party). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 08:31: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 89D783A6B50; Fri, 11 Jul 2008 08:31: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 9072A3A6B50 for ; Fri, 11 Jul 2008 08:31:14 -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 jCwgdrOR3j6W for ; Fri, 11 Jul 2008 08:31:13 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 2B8483A6876 for ; Fri, 11 Jul 2008 08:31:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jul 2008 08:30:57 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 08:31:06 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 08:31:05 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 11:31:04 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Jul 2008 15:30:34 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 11 Jul 2008 08:30:14 -0700 From: Reinaldo Penno To: Laird Popkin , "Vijay K. Gurbani" Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjjawODBAZJcCAt20ezgTeJrJTszg== In-Reply-To: <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 11 Jul 2008 15:31:04.0015 (UTC) FILETIME=[2152F5F0:01C8E36B] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] Charter and problem statement 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 Some comments inline... On 7/11/08 8:10 AM, "Laird Popkin" wrote: > For this level of discussion, I agree that caches should simply be viewed as a > peer in ALTO. > > I would point out some differences that we'll want to discuss at some point, > as I think that they'll require some mild extensions to ALTO as we've > discussed it so far: > - The cache servers are never part of the ALTO client request (since the p2p > network doesn't know about them) After a client knows about the IP address of the cache (which in its interpretation might be just a very good peer), it can communicate such 'peer' to others peers in the network. As I'm sure you know both Bittorrent and emule have source exchange between peers, so after the cat is out of the box, how to prevent such information from being disseminated? Or do we want to prevent it? If the idea is for peers to use caches, such information should be disseminated, no? but the ALTO server needs to give out exact > addresses of caches in its response, since they're peers that are unknown to > the p2p network. This is different from the more abstract network locations > (e.g. IP prefix, ASN) that ALTO otherwise uses (IMO, anyway) in order to > protect user privacy. There isn't a privacy concern with revealing the > location of an ISP-run cache server to the ISP. :-) > - Cache servers are protocol, application and perhaps even content specific, > so that information needs to be (optionally) communicated in the ALTO request. > For example, an ISP might operate BitTorrent and Pando caches, but not eDonkey > caches, or it might operate different caches for different protocols on > different hardware at different locations, or it might decide to cache some > content (e.g. commercial content) but not other content (e.g. consumer > generated content) that is transported using the same protocol and > application. I believe the front end of the cache might be protocol specific. So, emule and Bittorrent, use different protocols divide the file, hash and serve content, but the content is the same. Of course there might be policies involved in commercial vs. user generated content as you point out. > - There might be some additional policy information that the ISP may wish to > communicate. For example, an ISP that invests heavily in caching to relieve > uplink congestion might want p2p apps to use the cache servers to the > exclusion of peers within the network, etc. Of course, the implementation of > this is up to the p2p application, but at the least the ISP should be able to > communicate preferences. Agreed, but does not seem to within the scope of ALTO. It would probably be within proprietary extensions. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Vijay K. Gurbani" > To: "Laird Popkin" , "Stanislav Shalunov" > > Cc: p2pi@ietf.org > Sent: Friday, July 11, 2008 10:53:56 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] Charter and problem statement > > Laird Popkin wrote: >> IMO caches are a (rather valuable) special case of the general >> problem of finding optimal sources of data (for data that has >> multiple available sources). >> >> To elaborate on this, once the ISP has an "oracle" that communicates >> network policies to applications, that seems like an ideal channel >> for communicating information about caches. Doing so explicitly and >> under the direction of the ISP and the support of the p2p networks >> seems much better than the techniques that those guys use now (e.g. >> multiple proprietary cache discovery protocols, or deep packet >> inspection and protocol hacking). As a p2p developer, I have to say >> that it's far more likely that we'd support a single standard cache >> location mechanism (especially if it gave all of the other benefits >> of an "oracle") than for us to test multiple proprietary cache >> discovery mechanisms on every download. > > Laird, Stanislav: I think both of you are proposing that cache- > discovery be a part of ALTO. I am trying to make a distinction > between /cache/ and /content/ in the context of our work. > > In a P2P application-based overlay, the "best" peer (however > the network defines "best") is where the querying peer should > be sent to get the resource in question from. If we stretch > this analogy a bit further, it does not matter that the resource > is mirrored (cached) at the "best" peer or it appears as > the only instance of resource on the "best peer" (i.e., it is > not cached.) So in cases like this, I believe that sending > a querying peer to the "best" peer is immaterial of whether > or not the "best" peer is a caching-only server versus a > server providing original content. The content is immutable. > > In other applications like HTTP-based caching, it matters whether > or not a cache is hit or the origin server is hit. > > If caching is deemed to be a part of the charter, how do we define > it for ALTO? > > Thanks, > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 08:31: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 AD2A528C194; Fri, 11 Jul 2008 08:31: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 DFC0028C19F for ; Fri, 11 Jul 2008 08:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_111=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 DkzshkRUcG6h for ; Fri, 11 Jul 2008 08:31:54 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 1BDAC3A6876 for ; Fri, 11 Jul 2008 08:31:49 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=QY135/Nd7hj3G1JGqQi5iNkt7xY1vuLH9PR9EhStg0/B8LBv1MIXnXIt JjZZkIRJas1UEycN9n0qL7ifbJ9EBg==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 179947829:10.224.36.65:11 Jul 2008 15:32:07 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208";a="179947829" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 11 Jul 2008 15:32:07 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Fri, 11 Jul 2008 11:32:07 -0400 To: Laird Popkin Message-ID: Date: Fri, 11 Jul 2008 11:32:07 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <2115964082.501721215789670719.JavaMail.root@dkny.pando.com> References: <2115964082.501721215789670719.JavaMail.root@dkny.pando.com> Content-Disposition: inline Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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, all: Can I propose to change the name of the BoF/WG as "ALTE" where E=Engineering? The term "optimization" indicates a given one specific thing and does not keep the room for doing something at a broader level. For example, we are doing QOS and performance engineering at the application level and developing protocols that my or may not provide anything "absolute" optimization other than some best estimates for certain circumstances. Best regards, Radhika ----- Original Message ----- From: Laird Popkin Date: Friday, July 11, 2008 11:23 Subject: Re: [p2pi] ALTO BoF - generalize the problem To: Reinaldo Penno Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini > Whether ALTO covers one or both depends on the contents of the > ALTO messages, which is intentionally quite abstract at the > moment. This is intentional, so that ALTO can be used to express a > wide range of possible p2p optimization strategies. > > To express what P4P does in ALTO, for example, I could imagine > that the P4P iTracker is an ALTO client to the ISP's ALTO server, > and is an ALTO server to the P2P network's ALTO client, with > different levels of information flowing through each ALTO > client/server communication. That is, I believe, within the scope > of what we expressed in the ALTO requirments. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Saverio Niccolini" > , "Enrico Marocco" > , "PAPADIMITRIOU Dimitri" > > Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Hello, > > The latter does not seem to be part of the charter at this point. It > certainly needs to be part of any working solution but I'm not > sure if it > can be easily standardized. > > Thanks, > > Reinaldo > > On 7/10/08 8:29 AM, "Laird Popkin" wrote: > > > LP: I would say that there are two layers of communication that > ALTO needs to > > address. One layer is between the ALTO client (e.g. p2p app, p2p > server) and > > the ALTO server, and the second is between the ALTO server and > the source of > > network topology information (e.g. ISP, third-party). > > > _______________________________________________ > 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 Jul 11 08:42: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 C521E28C1DD; Fri, 11 Jul 2008 08:42: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 B071228C1D7 for ; Fri, 11 Jul 2008 08:42:34 -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 CM-gYIlNtXBh for ; Fri, 11 Jul 2008 08:42:33 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 4F48D28C1D8 for ; Fri, 11 Jul 2008 08:42:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id F3EACE10A5F; Fri, 11 Jul 2008 11:42:50 -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 CRQ1nJobnOjA; Fri, 11 Jul 2008 11:42:50 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 4CBC6E10AEE; Fri, 11 Jul 2008 11:42:50 -0400 (EDT) Date: Fri, 11 Jul 2008 11:42:50 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <2133119686.501751215790970278.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] Charter and problem statement 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 Comments below. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" , "Vijay K. Gurbani" Cc: p2pi@ietf.org, "Stanislav Shalunov" Sent: Friday, July 11, 2008 11:30:14 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Charter and problem statement Some comments inline... On 7/11/08 8:10 AM, "Laird Popkin" wrote: > For this level of discussion, I agree that caches should simply be viewed as a > peer in ALTO. > > I would point out some differences that we'll want to discuss at some point, > as I think that they'll require some mild extensions to ALTO as we've > discussed it so far: > - The cache servers are never part of the ALTO client request (since the p2p > network doesn't know about them) After a client knows about the IP address of the cache (which in its interpretation might be just a very good peer), it can communicate such 'peer' to others peers in the network. As I'm sure you know both Bittorrent and emule have source exchange between peers, so after the cat is out of the box, how to prevent such information from being disseminated? Or do we want to prevent it? If the idea is for peers to use caches, such information should be disseminated, no? LP: Yes, Pando implements peer-exchange as well. And it's probably better for cache server addresses not to be passed around. For example, if a peer in ISP A finds out about a cache server in ISP A's infrastructure, and tells a peer in ISP B about that peer, you'll have ISP B's customers using the cache server at ISP A (or at least trying to). It'd probably be better for the client to know that it's been informed of a peer operated by their ISP so that they know not to send it around to other peers, because that'll just lead to lots of failed connections (or a cache server serving off-net). but the ALTO server needs to give out exact > addresses of caches in its response, since they're peers that are unknown to > the p2p network. This is different from the more abstract network locations > (e.g. IP prefix, ASN) that ALTO otherwise uses (IMO, anyway) in order to > protect user privacy. There isn't a privacy concern with revealing the > location of an ISP-run cache server to the ISP. :-) > - Cache servers are protocol, application and perhaps even content specific, > so that information needs to be (optionally) communicated in the ALTO request. > For example, an ISP might operate BitTorrent and Pando caches, but not eDonkey > caches, or it might operate different caches for different protocols on > different hardware at different locations, or it might decide to cache some > content (e.g. commercial content) but not other content (e.g. consumer > generated content) that is transported using the same protocol and > application. I believe the front end of the cache might be protocol specific. So, emule and Bittorrent, use different protocols divide the file, hash and serve content, but the content is the same. LP: Yes, some cache servers support multiple protocols over one set of content, while others are protocol specific (e.g. HTTP caches are different from eDonkey caches), or support multiple protocols, each with their own set of content. Given that we don't know how this will all play out over time, I'd suggest giving the ISP (and ALTO server) maximum flexibility to decide what to do by having a few fields that can be used to communicate information such as application, protocol, etc., and let the ALTO server implementors figure out what to do with them based on ISP requirements. :-) Of course there might be policies involved in commercial vs. user generated content as you point out. > - There might be some additional policy information that the ISP may wish to > communicate. For example, an ISP that invests heavily in caching to relieve > uplink congestion might want p2p apps to use the cache servers to the > exclusion of peers within the network, etc. Of course, the implementation of > this is up to the p2p application, but at the least the ISP should be able to > communicate preferences. Agreed, but does not seem to within the scope of ALTO. It would probably be within proprietary extensions. LP: As long as it's extensible (which ALTO will be) that's fine. Though hopefully really basic concepts like this can be negotiated as "open" rather than "proprietary" extensions. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Vijay K. Gurbani" > To: "Laird Popkin" , "Stanislav Shalunov" > > Cc: p2pi@ietf.org > Sent: Friday, July 11, 2008 10:53:56 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] Charter and problem statement > > Laird Popkin wrote: >> IMO caches are a (rather valuable) special case of the general >> problem of finding optimal sources of data (for data that has >> multiple available sources). >> >> To elaborate on this, once the ISP has an "oracle" that communicates >> network policies to applications, that seems like an ideal channel >> for communicating information about caches. Doing so explicitly and >> under the direction of the ISP and the support of the p2p networks >> seems much better than the techniques that those guys use now (e.g. >> multiple proprietary cache discovery protocols, or deep packet >> inspection and protocol hacking). As a p2p developer, I have to say >> that it's far more likely that we'd support a single standard cache >> location mechanism (especially if it gave all of the other benefits >> of an "oracle") than for us to test multiple proprietary cache >> discovery mechanisms on every download. > > Laird, Stanislav: I think both of you are proposing that cache- > discovery be a part of ALTO. I am trying to make a distinction > between /cache/ and /content/ in the context of our work. > > In a P2P application-based overlay, the "best" peer (however > the network defines "best") is where the querying peer should > be sent to get the resource in question from. If we stretch > this analogy a bit further, it does not matter that the resource > is mirrored (cached) at the "best" peer or it appears as > the only instance of resource on the "best peer" (i.e., it is > not cached.) So in cases like this, I believe that sending > a querying peer to the "best" peer is immaterial of whether > or not the "best" peer is a caching-only server versus a > server providing original content. The content is immutable. > > In other applications like HTTP-based caching, it matters whether > or not a cache is hit or the origin server is hit. > > If caching is deemed to be a part of the charter, how do we define > it for ALTO? > > Thanks, > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 12:14: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 06F3D28C2D8; Fri, 11 Jul 2008 12:14: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 E87C828C2D8 for ; Fri, 11 Jul 2008 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_111=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 3wZaUoq+3eRx for ; Fri, 11 Jul 2008 12:14:54 -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 CE7E728C2D6 for ; Fri, 11 Jul 2008 12:14:52 -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 m6BJEsh08773; Fri, 11 Jul 2008 21:14:54 +0200 (CEST) Received: from [192.168.0.100] (dhcp-10-61-96-227.cisco.com [10.61.96.227]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6BJElA16272; Fri, 11 Jul 2008 21:14:48 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 11 Jul 2008 21:14:30 +0200 From: stefano previdi To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: Acjjilfpllu9/k99Ed2fJQAX8vOM8g== In-Reply-To: Mime-version: 1.0 Cc: PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, p2pi@ietf.org, Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: "Roy, Radhika R Dr CTR USA USAMC" > > Hi, all: > > Can I propose to change the name of the BoF/WG as "ALTE" where E=Engineering? "Traffic Engineering" is a terms that has been highly/heavily used (and abused) in the routing layer and using it in this context will resurrect a lot of interpretations of the "TE" words that I warmly recommend to avoid. Also, there are substantial differences between techniques that: - engineer the traffic by controlling the path such traffic is going to take - use topology information in order to determine the best selection of a given resource. Thanks. s. > The term "optimization" indicates a given one specific thing and does not keep > the room for doing something at a broader level. For example, we are doing QOS > and performance engineering at the application level and developing protocols > that my or may not provide anything "absolute" optimization other than some > best estimates for certain circumstances. > > Best regards, > Radhika > > ----- Original Message ----- > From: Laird Popkin > Date: Friday, July 11, 2008 11:23 > Subject: Re: [p2pi] ALTO BoF - generalize the problem > To: Reinaldo Penno > Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini > >> Whether ALTO covers one or both depends on the contents of the >> ALTO messages, which is intentionally quite abstract at the >> moment. This is intentional, so that ALTO can be used to express a >> wide range of possible p2p optimization strategies. >> >> To express what P4P does in ALTO, for example, I could imagine >> that the P4P iTracker is an ALTO client to the ISP's ALTO server, >> and is an ALTO server to the P2P network's ALTO client, with >> different levels of information flowing through each ALTO >> client/server communication. That is, I believe, within the scope >> of what we expressed in the ALTO requirments. >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Laird Popkin" >> Cc: p2pi@ietf.org, "Saverio Niccolini" >> , "Enrico Marocco" >> , "PAPADIMITRIOU Dimitri" >> >> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO BoF - generalize the problem >> >> Hello, >> >> The latter does not seem to be part of the charter at this point. It >> certainly needs to be part of any working solution but I'm not >> sure if it >> can be easily standardized. >> >> Thanks, >> >> Reinaldo >> >> On 7/10/08 8:29 AM, "Laird Popkin" wrote: >> >>> LP: I would say that there are two layers of communication that >> ALTO needs to >>> address. One layer is between the ALTO client (e.g. p2p app, p2p >> server) and >>> the ALTO server, and the second is between the ALTO server and >> the source of >>> network topology information (e.g. ISP, third-party). >> >> >> _______________________________________________ >> 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 Jul 11 12:25: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 3FDE528C2E9; Fri, 11 Jul 2008 12:25: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 1FA3D28C2E8 for ; Fri, 11 Jul 2008 12:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 IlF9T+al6541 for ; Fri, 11 Jul 2008 12:25:03 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id D756428C2E3 for ; Fri, 11 Jul 2008 12:25:02 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=hamfTaT29rT8mSymrqFMfQGABd3qKNMl3WVGv9zGjZTWRNsYEd5bVd4f zxyLxZ/Xa47f57cBRt3aIJiDW8261g==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 176682545:10.224.36.65:11 Jul 2008 19:25:20 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.30,347,1212364800"; d="scan'208";a="176682545" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 11 Jul 2008 19:25:20 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Fri, 11 Jul 2008 15:25:20 -0400 To: stefano previdi Message-ID: Date: Fri, 11 Jul 2008 15:25:20 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: References: Content-Disposition: inline Cc: PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, p2pi@ietf.org, Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 bottom line is this: We are NOT standardizing the "optimization" algorithms per se. We are developing "protocol" schemes that have the ability for some kind of better topology/routing scheme at the application layer. So, "O" or "TE" is not the right one, we have to find something else that resonates the actual "goals" of the BoF/WG. How about ALTOP where P=protocol or something along this line? RRR ----- Original Message ----- From: stefano previdi Date: Friday, July 11, 2008 15:15 Subject: Re: [p2pi] ALTO BoF - generalize the problem To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, Niccolini > > From: "Roy, Radhika R Dr CTR USA USAMC" > > > > Hi, all: > > > > Can I propose to change the name of the BoF/WG as "ALTE" where > E=Engineering? > "Traffic Engineering" is a terms that has been highly/heavily used > (andabused) in the routing layer and using it in this context will > resurrect a > lot of interpretations of the "TE" words that I warmly recommend > to avoid. > > Also, there are substantial differences between techniques that: > - engineer the traffic by controlling the path such traffic is > going to take > - use topology information in order to determine the best > selection of a > given resource. > > Thanks. > > s. > > > The term "optimization" indicates a given one specific thing and > does not keep > > the room for doing something at a broader level. For example, we > are doing QOS > > and performance engineering at the application level and > developing protocols > > that my or may not provide anything "absolute" optimization > other than some > > best estimates for certain circumstances. > > > > Best regards, > > Radhika > > > > ----- Original Message ----- > > From: Laird Popkin > > Date: Friday, July 11, 2008 11:23 > > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > To: Reinaldo Penno > > Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini > > > >> Whether ALTO covers one or both depends on the contents of the > >> ALTO messages, which is intentionally quite abstract at the > >> moment. This is intentional, so that ALTO can be used to > express a > >> wide range of possible p2p optimization strategies. > >> > >> To express what P4P does in ALTO, for example, I could imagine > >> that the P4P iTracker is an ALTO client to the ISP's ALTO server, > >> and is an ALTO server to the P2P network's ALTO client, with > >> different levels of information flowing through each ALTO > >> client/server communication. That is, I believe, within the scope > >> of what we expressed in the ALTO requirments. > >> > >> - Laird Popkin, CTO, Pando Networks > >> mobile: 646/465-0570 > >> > >> ----- Original Message ----- > >> From: "Reinaldo Penno" > >> To: "Laird Popkin" > >> Cc: p2pi@ietf.org, "Saverio Niccolini" > >> , "Enrico Marocco" > >> , "PAPADIMITRIOU Dimitri" > >> > >> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York > >> Subject: Re: [p2pi] ALTO BoF - generalize the problem > >> > >> Hello, > >> > >> The latter does not seem to be part of the charter at this > point. It > >> certainly needs to be part of any working solution but I'm not > >> sure if it > >> can be easily standardized. > >> > >> Thanks, > >> > >> Reinaldo > >> > >> On 7/10/08 8:29 AM, "Laird Popkin" wrote: > >> > >>> LP: I would say that there are two layers of communication that > >> ALTO needs to > >>> address. One layer is between the ALTO client (e.g. p2p app, p2p > >> server) and > >>> the ALTO server, and the second is between the ALTO server and > >> the source of > >>> network topology information (e.g. ISP, third-party). > >> > >> > >> _______________________________________________ > >> 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 Jul 11 13:12: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 DAD7A3A6895; Fri, 11 Jul 2008 13:12: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 9C5323A67DA for ; Fri, 11 Jul 2008 13:12: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=[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 Id-EbWTwbqi2 for ; Fri, 11 Jul 2008 13:12:50 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id 6E4903A6895 for ; Fri, 11 Jul 2008 13:12:50 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so2196602pyg.24 for ; Fri, 11 Jul 2008 13:13:08 -0700 (PDT) Received: by 10.114.151.13 with SMTP id y13mr11151842wad.148.1215807188527; Fri, 11 Jul 2008 13:13:08 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id l38sm1473812waf.1.2008.07.11.13.13.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Jul 2008 13:13:08 -0700 (PDT) Message-Id: <51FFF441-33B8-4D9D-83EF-F333801E443B@shlang.com> From: Stanislav Shalunov To: Enrico Marocco In-Reply-To: <487768E6.8080804@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 13:13:06 -0700 References: <487717E2.4090801@telecomitalia.it> <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> <487768E6.8080804@telecomitalia.it> X-Mailer: Apple Mail (2.926) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 OK, I misunderstood the use of oracle -- suspect it might be confusing to others in this context? Thank you for clarifying. I'll send proposed textual changes to the charter later. My main concern that the solution to the easy location problem is not dependent on the solution for the hard information conveying problem. Since the easy location problem needs to be solved anyway -- or else one can't find a routing information provider/oracle/whatever we want to call it -- we need a mechanism for it regardless. I'll think about how to package and phrase this best and send it in another message. Thanks, -- Stas On Jul 11, 2008, at 7:06 AM, Enrico Marocco wrote: > Stanislav Shalunov wrote: >> The general problem of overlay routing and how to best expose >> information for it is big and hard. >> >> The problem of caching, on the other hand, is well-defined, easily >> scoped, and easy to agree on. Cache tracker location is a pure and >> simple engineering problem. Routing information exposure has a >> substantial research component. >> >> This charter does not let the possible WG solve the easy problem -- >> in >> fact, it does not even contain the word "cache". Instead, it >> proposes >> a particular solution (oracle) for the more complicated routing >> information exposure problem, before the problem has even been >> scoped. > > Ok, I see that the first change must be on the term "oracle". It > wasn't > of course meant to push any particular solution; in our mind, "oracle" > could be any source of topology information, including the IDIPS > "sorting oracle" as well as the P4P iTracker or the Ono/Akamai > redirect > server. > > That said, I understand caches as "special" peers that can be > transparently handled by the peer selection service we are trying to > standardize (as suggested in S2.1.1 of the problem statement). > Alternatively, we would have to work on some sort of > application-dependent cache location mechanism, which, AFAICT, is not > what most people here want to pursue and I don't think is what you are > proposing. Can you suggest a rewording for the current charter to best > address caching issues? > > Finally, the survey draft references several solutions for addressing > the topology information exposure problem, which have proved in the > real > world to be beneficial to P2P applications in the first place (and > some > to ISPs as well). I really don't want people to think that we are > going > to invent a new one; instead, what we are proposing is just to > define a > standard interface for existing and future peer selection optimization > services, in order to ease their adoption by different P2P and non-P2P > applications. > > If you agree, but don't see it reflected in the charter, feel free to > propose alternative text. > > -- > Ciao, > Enrico -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 11 14:05: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 5D87128C116; Fri, 11 Jul 2008 14:05: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 301C63A6778 for ; Fri, 11 Jul 2008 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 dwiGdqIGqHVB for ; Fri, 11 Jul 2008 14:05:35 -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 0F2713A67AC for ; Fri, 11 Jul 2008 14:05:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,347,1212364800"; d="scan'208";a="52056631" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2008 21:05:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6BL5p7w004298; Fri, 11 Jul 2008 14:05:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6BL5pbd025424; Fri, 11 Jul 2008 21:05:51 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, 11 Jul 2008 14:05:50 -0700 Received: from [10.32.241.76] ([10.32.241.76]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 14:05:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <3F041C84-43B8-44D2-BD3D-86441DE5554C@cisco.com> From: Bruce Davie Date: Fri, 11 Jul 2008 17:05:46 -0400 To: "Roy, Radhika R Dr CTR USA USAMC" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 11 Jul 2008 21:05:50.0356 (UTC) FILETIME=[E5B75D40:01C8E399] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4698; t=1215810351; x=1216674351; 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]=20ALTO=20BoF=20-=20generalize=20 the=20problem |Sender:=20; bh=OmB/1i3+AJ9sK5Ey7nsRn35qz55Jq51ptEq7viVQU94=; b=NBSPXgSayAvJP0yeHalp/nU71xgT7spp65rpEoUt4P6kggwvxQv/bK4VUq EXbpOjcN2zpv1daDp8suUAQ9E5maZ3iCeXnutNERg8kAmytLP4n5z9PR02bH VLMIosO8+e; Authentication-Results: sj-dkim-4; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: p2pi@ietf.org, Saverio@core3.amsl.com, PAPADIMITRIOU Dimitri , Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 How about we focus on the charter and worry about the name of the WG when and if the WG goes ahead. Sometimes we have to accept that the name of the WG alone will not tell you everything you need to know about the WG's activities. It is often necessary to read the WG documents as well. Bruce On Jul 11, 2008, at 3:25 PM, Roy, Radhika R Dr CTR USA USAMC wrote: > The bottom line is this: We are NOT standardizing the > "optimization" algorithms per se. We are developing "protocol" > schemes that have the ability for some kind of better topology/ > routing scheme at the application layer. > > So, "O" or "TE" is not the right one, we have to find something > else that resonates the actual "goals" of the BoF/WG. > > How about ALTOP where P=protocol or something along this line? > > RRR > > ----- Original Message ----- > From: stefano previdi > Date: Friday, July 11, 2008 15:15 > Subject: Re: [p2pi] ALTO BoF - generalize the problem > To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin > Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, > Niccolini > >>> From: "Roy, Radhika R Dr CTR USA USAMC" >>> >>> Hi, all: >>> >>> Can I propose to change the name of the BoF/WG as "ALTE" where >> E=Engineering? >> "Traffic Engineering" is a terms that has been highly/heavily used >> (andabused) in the routing layer and using it in this context will >> resurrect a >> lot of interpretations of the "TE" words that I warmly recommend >> to avoid. >> >> Also, there are substantial differences between techniques that: >> - engineer the traffic by controlling the path such traffic is >> going to take >> - use topology information in order to determine the best >> selection of a >> given resource. >> >> Thanks. >> >> s. >> >>> The term "optimization" indicates a given one specific thing and >> does not keep >>> the room for doing something at a broader level. For example, we >> are doing QOS >>> and performance engineering at the application level and >> developing protocols >>> that my or may not provide anything "absolute" optimization >> other than some >>> best estimates for certain circumstances. >>> >>> Best regards, >>> Radhika >>> >>> ----- Original Message ----- >>> From: Laird Popkin >>> Date: Friday, July 11, 2008 11:23 >>> Subject: Re: [p2pi] ALTO BoF - generalize the problem >>> To: Reinaldo Penno >>> Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini >>> >>>> Whether ALTO covers one or both depends on the contents of the >>>> ALTO messages, which is intentionally quite abstract at the >>>> moment. This is intentional, so that ALTO can be used to >> express a >>>> wide range of possible p2p optimization strategies. >>>> >>>> To express what P4P does in ALTO, for example, I could imagine >>>> that the P4P iTracker is an ALTO client to the ISP's ALTO server, >>>> and is an ALTO server to the P2P network's ALTO client, with >>>> different levels of information flowing through each ALTO >>>> client/server communication. That is, I believe, within the scope >>>> of what we expressed in the ALTO requirments. >>>> >>>> - Laird Popkin, CTO, Pando Networks >>>> mobile: 646/465-0570 >>>> >>>> ----- Original Message ----- >>>> From: "Reinaldo Penno" >>>> To: "Laird Popkin" >>>> Cc: p2pi@ietf.org, "Saverio Niccolini" >>>> , "Enrico Marocco" >>>> , "PAPADIMITRIOU Dimitri" >>>> >>>> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York >>>> Subject: Re: [p2pi] ALTO BoF - generalize the problem >>>> >>>> Hello, >>>> >>>> The latter does not seem to be part of the charter at this >> point. It >>>> certainly needs to be part of any working solution but I'm not >>>> sure if it >>>> can be easily standardized. >>>> >>>> Thanks, >>>> >>>> Reinaldo >>>> >>>> On 7/10/08 8:29 AM, "Laird Popkin" wrote: >>>> >>>>> LP: I would say that there are two layers of communication that >>>> ALTO needs to >>>>> address. One layer is between the ALTO client (e.g. p2p app, p2p >>>> server) and >>>>> the ALTO server, and the second is between the ALTO server and >>>> the source of >>>>> network topology information (e.g. ISP, third-party). >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Jul 11 16:47: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 98C1D3A6881; Fri, 11 Jul 2008 16:47: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 41B1B3A6881 for ; Fri, 11 Jul 2008 16:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 8WbJPYqQ5xmf for ; Fri, 11 Jul 2008 16:47:31 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 011CE3A686C for ; Fri, 11 Jul 2008 16:47:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so4105203wfd.31 for ; Fri, 11 Jul 2008 16:47:50 -0700 (PDT) Received: by 10.142.166.1 with SMTP id o1mr3378579wfe.345.1215820069804; Fri, 11 Jul 2008 16:47:49 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 22sm1959965wfg.13.2008.07.11.16.47.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Jul 2008 16:47:49 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: p2pi@ietf.org In-Reply-To: <3F041C84-43B8-44D2-BD3D-86441DE5554C@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 16:47:46 -0700 References: <3F041C84-43B8-44D2-BD3D-86441DE5554C@cisco.com> X-Mailer: Apple Mail (2.926) Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Or we might even not worry about the name of the possible WG at all and just worry about the charter and the quality of the documents the WG produces. After all, when the WG completes, the name is gone, but the documents remain. On Jul 11, 2008, at 2:05 PM, Bruce Davie wrote: > How about we focus on the charter and worry about the name of the WG > when and if the WG goes ahead. > > Sometimes we have to accept that the name of the WG alone will not > tell you everything you need to know about the WG's activities. It > is often necessary to read the WG documents as well. > > Bruce > > On Jul 11, 2008, at 3:25 PM, Roy, Radhika R Dr CTR USA USAMC wrote: > >> The bottom line is this: We are NOT standardizing the >> "optimization" algorithms per se. We are developing "protocol" >> schemes that have the ability for some kind of better topology/ >> routing scheme at the application layer. >> >> So, "O" or "TE" is not the right one, we have to find something >> else that resonates the actual "goals" of the BoF/WG. >> >> How about ALTOP where P=protocol or something along this line? >> >> RRR >> >> ----- Original Message ----- >> From: stefano previdi >> Date: Friday, July 11, 2008 15:15 >> Subject: Re: [p2pi] ALTO BoF - generalize the problem >> To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin >> Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, >> Niccolini >> >>>> From: "Roy, Radhika R Dr CTR USA USAMC" >>>> >>>> Hi, all: >>>> >>>> Can I propose to change the name of the BoF/WG as "ALTE" where >>> E=Engineering? >>> "Traffic Engineering" is a terms that has been highly/heavily used >>> (andabused) in the routing layer and using it in this context will >>> resurrect a >>> lot of interpretations of the "TE" words that I warmly recommend >>> to avoid. >>> >>> Also, there are substantial differences between techniques that: >>> - engineer the traffic by controlling the path such traffic is >>> going to take >>> - use topology information in order to determine the best >>> selection of a >>> given resource. >>> >>> Thanks. >>> >>> s. >>> >>>> The term "optimization" indicates a given one specific thing and >>> does not keep >>>> the room for doing something at a broader level. For example, we >>> are doing QOS >>>> and performance engineering at the application level and >>> developing protocols >>>> that my or may not provide anything "absolute" optimization >>> other than some >>>> best estimates for certain circumstances. >>>> >>>> Best regards, >>>> Radhika >>>> >>>> ----- Original Message ----- >>>> From: Laird Popkin >>>> Date: Friday, July 11, 2008 11:23 >>>> Subject: Re: [p2pi] ALTO BoF - generalize the problem >>>> To: Reinaldo Penno >>>> Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini >>>> >>>>> Whether ALTO covers one or both depends on the contents of the >>>>> ALTO messages, which is intentionally quite abstract at the >>>>> moment. This is intentional, so that ALTO can be used to >>> express a >>>>> wide range of possible p2p optimization strategies. >>>>> >>>>> To express what P4P does in ALTO, for example, I could imagine >>>>> that the P4P iTracker is an ALTO client to the ISP's ALTO server, >>>>> and is an ALTO server to the P2P network's ALTO client, with >>>>> different levels of information flowing through each ALTO >>>>> client/server communication. That is, I believe, within the scope >>>>> of what we expressed in the ALTO requirments. >>>>> >>>>> - Laird Popkin, CTO, Pando Networks >>>>> mobile: 646/465-0570 >>>>> >>>>> ----- Original Message ----- >>>>> From: "Reinaldo Penno" >>>>> To: "Laird Popkin" >>>>> Cc: p2pi@ietf.org, "Saverio Niccolini" >>>>> , "Enrico Marocco" >>>>> , "PAPADIMITRIOU Dimitri" >>>>> >>>>> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/ >>>>> New_York >>>>> Subject: Re: [p2pi] ALTO BoF - generalize the problem >>>>> >>>>> Hello, >>>>> >>>>> The latter does not seem to be part of the charter at this >>> point. It >>>>> certainly needs to be part of any working solution but I'm not >>>>> sure if it >>>>> can be easily standardized. >>>>> >>>>> Thanks, >>>>> >>>>> Reinaldo >>>>> >>>>> On 7/10/08 8:29 AM, "Laird Popkin" wrote: >>>>> >>>>>> LP: I would say that there are two layers of communication that >>>>> ALTO needs to >>>>>> address. One layer is between the ALTO client (e.g. p2p app, p2p >>>>> server) and >>>>>> the ALTO server, and the second is between the ALTO server and >>>>> the source of >>>>>> network topology information (e.g. ISP, third-party). >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jul 12 04:34: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 CD2E128C169; Sat, 12 Jul 2008 04:34: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 4236428C169 for ; Sat, 12 Jul 2008 04:34:57 -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 WuMpN1+3eZtB for ; Sat, 12 Jul 2008 04:34:56 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6907628C167 for ; Sat, 12 Jul 2008 04:34:56 -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 m6CBZ8VI024416; Sat, 12 Jul 2008 07:35:08 -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 m6CBZ8Ik023571; Sat, 12 Jul 2008 07:35:08 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6CBZ7dY023566; Sat, 12 Jul 2008 07:35:07 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Sat, 12 Jul 2008 07:35:07 -0400 (EDT) From: Salman Abdul Baset To: Lars Eggert In-Reply-To: Message-ID: References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> 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.8 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Fri, 11 Jul 2008, Lars Eggert wrote: > Hi, > > On 2008-7-11, at 10:21, ext Salman Abdul Baset wrote: >> The 'network' is important because a machine connected to a ethernet >> switch/hub which in turn is connected to a DSL/cable modem cannot determine >> the access link speed in a straightforward way. This information is helpful >> when selecting a relay node for VoIP/video, for example. > > well, "helpful" is a concept I can't strongly argue with, but please note > that the nominal capacity of a node's access link does not tell you anything > about the currently available bandwidth, loss rates, delay, or jitter of the > end-to-end path. It's not even clear that the access link is always the > bottleneck for a given path. > I agree with what you said. As you noted, if access link is not the bottleneck, it is useless to determine the capacity of the access link. I am thinking of scenarios where access maybe the bottleneck. In a P2PSIP network, machines with a dialup or low bit-rate DSL will like to know their connection type and perhaps access speed so that they never advertise themselves as candidates for VoIP or video relays in the overlay. -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jul 12 10:09: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 110E53A6811; Sat, 12 Jul 2008 10:09: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 37B513A6782 for ; Sat, 12 Jul 2008 10:09:26 -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=[AWL=0.000, 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 6xkUru+en0v9 for ; Sat, 12 Jul 2008 10:09:25 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id B0CC83A6811 for ; Sat, 12 Jul 2008 10:09:24 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (unknown [10.1.3.8]) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Sat, 12 Jul 2008 19:09:41 +0200 (CEST) Received: from 90.4.44.178 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Sat, 12 Jul 2008 19:09:43 +0200 (CEST) Message-ID: <99a8a41c55ebb4a12baf7b5c44cd22de.squirrel@mmp.sipr-dc.ucl.ac.be> In-Reply-To: References: <487717E2.4090801@telecomitalia.it> <9D15BB27-B5D6-4766-A6F8-1E522A2AD196@shlang.com> Date: Sat, 12 Jul 2008 19:09:43 +0200 (CEST) From: "Damien Saucez" To: "Salman Abdul Baset" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Squirrel authenticated, X-MailScanner-ID: E2C71EC0E2.ABB50 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Salman, > In addition to comments by Stanislav, a question to be considered is > whether the signaling protocol should support cooperation of oracles in > addition to querying of oracle. Is there a need for such cooperation? > I think that the cooperation is important and probably that the difficulties in the design are a matter of politic instead of technique (business relationship). Damien Saucez > -s > > On Fri, 11 Jul 2008, Stanislav Shalunov wrote: > >> On Jul 11, 2008, at 1:20 AM, Enrico Marocco wrote: >>> Vijay and I have put together a first draft of the charter, trying to >>> capture how people on this list think an IETF working group should >>> address the ALTO problem. It is available at the following link: >>> http://alto.tilab.com/docs/charter.txt >> >> Thank you for putting together the charter well enough ahead of the BoF >> that >> we have time to discuss it. >> >> >> The general problem of overlay routing and how to best expose >> information for >> it is big and hard. >> >> The problem of caching, on the other hand, is well-defined, easily >> scoped, >> and easy to agree on. Cache tracker location is a pure and simple >> engineering problem. Routing information exposure has a substantial >> research >> component. >> >> This charter does not let the possible WG solve the easy problem -- in >> fact, >> it does not even contain the word "cache". Instead, it proposes a >> particular >> solution (oracle) for the more complicated routing information exposure >> problem, before the problem has even been scoped. >> >> Further, the chartered oracle location service is of exactly the same >> nature >> and complexity as the non-chartered cache tracker location service. >> >> -- >> Stanislav Shalunov >> http://shlang.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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jul 13 01:37: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 78DDF3A6963; Sun, 13 Jul 2008 01:37: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 B979D3A6963 for ; Sun, 13 Jul 2008 01:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 nqy94TTBH9gS for ; Sun, 13 Jul 2008 01:36:59 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A134F3A68DA for ; Sun, 13 Jul 2008 01:36:58 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6D8b6p9009579; Sun, 13 Jul 2008 11:37:07 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jul 2008 11:37:06 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jul 2008 11:37:05 +0300 Received: from [192.168.255.2] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jul 2008 11:37:04 +0300 Message-Id: From: Lars Eggert To: ext Salman Abdul Baset In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 13 Jul 2008 11:37:00 +0300 References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 13 Jul 2008 08:37:05.0484 (UTC) FILETIME=[A13B68C0:01C8E4C3] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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-7-12, at 14:35, ext Salman Abdul Baset wrote: > On Fri, 11 Jul 2008, Lars Eggert wrote: >> On 2008-7-11, at 10:21, ext Salman Abdul Baset wrote: >>> The 'network' is important because a machine connected to a >>> ethernet switch/hub which in turn is connected to a DSL/cable >>> modem cannot determine the access link speed in a straightforward >>> way. This information is helpful when selecting a relay node for >>> VoIP/video, for example. >> >> well, "helpful" is a concept I can't strongly argue with, but >> please note that the nominal capacity of a node's access link does >> not tell you anything about the currently available bandwidth, loss >> rates, delay, or jitter of the end-to-end path. It's not even clear >> that the access link is always the bottleneck for a given path. > > I agree with what you said. As you noted, if access link is not the > bottleneck, it is useless to determine the capacity of the access > link. OK, glad we're in agreement. > I am thinking of scenarios where access maybe the bottleneck. In a > P2PSIP network, machines with a dialup or low bit-rate DSL will like > to know their connection type and perhaps access speed so that they > never advertise themselves as candidates for VoIP or video relays in > the overlay. Now I'm confused. Above you agreed that it's useless to determine this information, but here you want to use it to determine whether a node is a relay. An app knows what type of performance it gets over a path when it uses it. Why isn't that sufficient to figure out if there is enough capacity to act as a relay? Or to turn this around: Even when the access link happens to be the path bottleneck and its type indicates to the app that it should have enough capacity so it can relay, depending on who else you share that link with and what they are doing at the time may well mean there isn't sufficient transient capacity available. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 14 00:13: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 C911B3A6A9F; Mon, 14 Jul 2008 00:13: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 28CBF28C0EA for ; Mon, 14 Jul 2008 00:13:25 -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 TWQcbgJDYj8V for ; Mon, 14 Jul 2008 00:13:24 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 4CDEF3A6A94 for ; Mon, 14 Jul 2008 00:13:21 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6E7DhuC006381; Mon, 14 Jul 2008 03:13:43 -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 m6E7DgmP017683; Mon, 14 Jul 2008 03:13:42 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6E7DgdX017680; Mon, 14 Jul 2008 03:13:42 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 14 Jul 2008 03:13:42 -0400 (EDT) From: Salman Abdul Baset To: Lars Eggert In-Reply-To: Message-ID: References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> 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" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Sun, 13 Jul 2008, Lars Eggert wrote: >> I am thinking of scenarios where access maybe the bottleneck. In a P2PSIP >> network, machines with a dialup or low bit-rate DSL will like to know their >> connection type and perhaps access speed so that they never advertise >> themselves as candidates for VoIP or video relays in the overlay. > > Now I'm confused. Above you agreed that it's useless to determine this > information, but here you want to use it to determine whether a node is a > relay. > > An app knows what type of performance it gets over a path when it uses it. > Why isn't that sufficient to figure out if there is enough capacity to act as > a relay? Or to turn this around: Even when the access link happens to be the > path bottleneck and its type indicates to the app that it should have enough > capacity so it can relay, Obviously, measuring the path capacity or using the path is required when the connection type indicates to the app that it should have enough capacity. When the connection type indicates to the app that it does not have enough capacity say for relaying a VoIP or video call, the application does not need to measure anything. It knows that it cannot do the requested work and will never advertise its relay service thereby avoiding the measurement of transient available capacity. depending on who else you share that link with and > what they are doing at the time may well mean there isn't sufficient > transient capacity available. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 14 00:22: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 1C0B13A68A8; Mon, 14 Jul 2008 00:22: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 7AB643A68A8 for ; Mon, 14 Jul 2008 00:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 u8be0FtW4x06 for ; Mon, 14 Jul 2008 00:22:46 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6A5373A6886 for ; Mon, 14 Jul 2008 00:22:46 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6E7MsOl004352; Mon, 14 Jul 2008 10:23:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 10:22:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 10:22:51 +0300 Received: from [192.89.6.49] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 10:22:50 +0300 Message-Id: <9EC2DCB1-BDEC-415F-B45C-2582838EACE7@nokia.com> From: Lars Eggert To: ext Salman Abdul Baset In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 14 Jul 2008 10:22:46 +0300 References: <48735DC8.9020709@uclouvain.be><547F018265F92642B577B986577D671C1ACD3C@VENUS.office><00275A5B436CA441900CB10936742A38C3EA5A@FRVELSMBS22.ad2.ad.alcatel.com><547F018265F92642B577B986577D671C1ACD70@VENUS.office><48739643.4090409@uclouvain.be><929E4C98-7AC0-423C-86D9-2318305BB537@shlang.com> <547F018265F92642B577B986577D671C1ACEC7@VENUS.office> <00275A5B436CA441900CB10936742A38C87947@FRVELSMBS22.ad2.ad.alcatel.com> <48762327.1030404@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 14 Jul 2008 07:22:51.0407 (UTC) FILETIME=[6CCEF1F0:01C8E582] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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-7-14, at 10:13, ext Salman Abdul Baset wrote: > Obviously, measuring the path capacity or using the path is required > when the connection type indicates to the app that it should have > enough capacity. > > When the connection type indicates to the app that it does not have > enough capacity say for relaying a VoIP or video call, the > application does not need to measure anything. It knows that it > cannot do the requested work and will never advertise its relay > service thereby avoiding the measurement of transient available > capacity. OK, so be conservative and default to off, i.e., only offer to relay after your network usage has left you convinced that you have capacity to be a relay. This should even have some benefits to the peers, because only nodes that have been around for a bit will become relays. Getting this information from an oracle doesn't save you any work, because even if your nominal uplink capacity could let you be a relay, you still need to figure out if the current load on it actually lets you. Plus, there are obviously uplink types with no stable capacity (3G, WiMax, etc.) where this won't work anyway. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 14 05:48: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 0C43528C206; Mon, 14 Jul 2008 05:48: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 1160E28C23B for ; Mon, 14 Jul 2008 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=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 NV6816DR8IAC for ; Mon, 14 Jul 2008 05:48:00 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id BD61328C135 for ; Mon, 14 Jul 2008 05:47:56 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=Re7JScOoPCgZSfQkPvdfd5yRIsLhnaV445wlVuq88W5TmxzyXzMpaZfh mZFuOkYyPHuJM7kpvaLaq+0dliMEag==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 173069763:10.224.36.65:14 Jul 2008 12:48:20 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.30,359,1212364800"; d="scan'208";a="173069763" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 14 Jul 2008 12:48:11 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 14 Jul 2008 08:48:11 -0400 To: Bruce Davie Message-ID: Date: Mon, 14 Jul 2008 08:48:11 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <3F041C84-43B8-44D2-BD3D-86441DE5554C@cisco.com> References: <3F041C84-43B8-44D2-BD3D-86441DE5554C@cisco.com> Content-Disposition: inline Cc: p2pi@ietf.org, Saverio@core3.amsl.com, PAPADIMITRIOU Dimitri , Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 for working on charter. In BoF, the name itself is a big test all by itself. I want that BoF to succeed without being mis-understood by the first attendees. BR/Radhika ----- Original Message ----- From: Bruce Davie Date: Friday, July 11, 2008 17:06 Subject: Re: [p2pi] ALTO BoF - generalize the problem To: "Roy, Radhika R Dr CTR USA USAMC" Cc: stefano previdi , PAPADIMITRIOU Dimitri , Saverio@core3.amsl.com, p2pi@ietf.org, Niccolini > How about we focus on the charter and worry about the name of the > WG > when and if the WG goes ahead. > > Sometimes we have to accept that the name of the WG alone will not > > tell you everything you need to know about the WG's activities. It > is > often necessary to read the WG documents as well. > > Bruce > > On Jul 11, 2008, at 3:25 PM, Roy, Radhika R Dr CTR USA USAMC wrote: > > > The bottom line is this: We are NOT standardizing the > > "optimization" algorithms per se. We are developing "protocol" > > schemes that have the ability for some kind of better topology/ > > routing scheme at the application layer. > > > > So, "O" or "TE" is not the right one, we have to find something > > else that resonates the actual "goals" of the BoF/WG. > > > > How about ALTOP where P=protocol or something along this line? > > > > RRR > > > > ----- Original Message ----- > > From: stefano previdi > > Date: Friday, July 11, 2008 15:15 > > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > To: "Roy, Radhika R Dr CTR USA USAMC" , Laird Popkin > > Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , > Saverio@core3.amsl.com, > > Niccolini > > > >>> From: "Roy, Radhika R Dr CTR USA USAMC" > >>> > >>> Hi, all: > >>> > >>> Can I propose to change the name of the BoF/WG as "ALTE" where > >> E=Engineering? > >> "Traffic Engineering" is a terms that has been highly/heavily used > >> (andabused) in the routing layer and using it in this context will > >> resurrect a > >> lot of interpretations of the "TE" words that I warmly recommend > >> to avoid. > >> > >> Also, there are substantial differences between techniques that: > >> - engineer the traffic by controlling the path such traffic is > >> going to take > >> - use topology information in order to determine the best > >> selection of a > >> given resource. > >> > >> Thanks. > >> > >> s. > >> > >>> The term "optimization" indicates a given one specific thing and > >> does not keep > >>> the room for doing something at a broader level. For example, we > >> are doing QOS > >>> and performance engineering at the application level and > >> developing protocols > >>> that my or may not provide anything "absolute" optimization > >> other than some > >>> best estimates for certain circumstances. > >>> > >>> Best regards, > >>> Radhika > >>> > >>> ----- Original Message ----- > >>> From: Laird Popkin > >>> Date: Friday, July 11, 2008 11:23 > >>> Subject: Re: [p2pi] ALTO BoF - generalize the problem > >>> To: Reinaldo Penno > >>> Cc: PAPADIMITRIOU Dimitri , p2pi@ietf.org, Saverio Niccolini > >>> > >>>> Whether ALTO covers one or both depends on the contents of the > >>>> ALTO messages, which is intentionally quite abstract at the > >>>> moment. This is intentional, so that ALTO can be used to > >> express a > >>>> wide range of possible p2p optimization strategies. > >>>> > >>>> To express what P4P does in ALTO, for example, I could imagine > >>>> that the P4P iTracker is an ALTO client to the ISP's ALTO server, > >>>> and is an ALTO server to the P2P network's ALTO client, with > >>>> different levels of information flowing through each ALTO > >>>> client/server communication. That is, I believe, within the scope > >>>> of what we expressed in the ALTO requirments. > >>>> > >>>> - Laird Popkin, CTO, Pando Networks > >>>> mobile: 646/465-0570 > >>>> > >>>> ----- Original Message ----- > >>>> From: "Reinaldo Penno" > >>>> To: "Laird Popkin" > >>>> Cc: p2pi@ietf.org, "Saverio Niccolini" > >>>> , "Enrico Marocco" > >>>> , "PAPADIMITRIOU Dimitri" > >>>> > >>>> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) > America/New_York>>>> Subject: Re: [p2pi] ALTO BoF - generalize the > problem>>>> > >>>> Hello, > >>>> > >>>> The latter does not seem to be part of the charter at this > >> point. It > >>>> certainly needs to be part of any working solution but I'm not > >>>> sure if it > >>>> can be easily standardized. > >>>> > >>>> Thanks, > >>>> > >>>> Reinaldo > >>>> > >>>> On 7/10/08 8:29 AM, "Laird Popkin" wrote: > >>>> > >>>>> LP: I would say that there are two layers of communication that > >>>> ALTO needs to > >>>>> address. One layer is between the ALTO client (e.g. p2p app, p2p > >>>> server) and > >>>>> the ALTO server, and the second is between the ALTO server and > >>>> the source of > >>>>> network topology information (e.g. ISP, third-party). > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 Mon Jul 14 08:41: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 C22813A69A4; Mon, 14 Jul 2008 08:41: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 1296C3A6A0F for ; Mon, 14 Jul 2008 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=2.410, 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 r8sybDi2RnUk for ; Mon, 14 Jul 2008 08:41:02 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D0AF53A6941 for ; Mon, 14 Jul 2008 08:41:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 681372C00035B; Mon, 14 Jul 2008 17:41:27 +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 gkRlCwP88wO5; Mon, 14 Jul 2008 17:41:27 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 470B52C000303; Mon, 14 Jul 2008 17:41:17 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.208]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 17:41:16 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Mon, 14 Jul 2008 17:41:16 +0200 Date: Mon, 14 Jul 2008 17:41:16 +0200 From: Sebastian Kiesel To: Laird Popkin Message-ID: <20080714154115.GE5618@foo.nw.neclab.eu> References: <48777404.4080208@alcatel-lucent.com> <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-OriginalArrivalTime: 14 Jul 2008 15:41:16.0660 (UTC) FILETIME=[0DBA6B40:01C8E5C8] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: > For this level of discussion, I agree that caches should simply be > viewed as a peer in ALTO. What happens if we consider caches and rare content, i.e., content where the likelyhood is high, that there is a cache miss when we ask for it and that the cache will never deliver a second copy of it? It might not be wise to select a cache which is in the "opposite direction" of the original content, even if connectivity to the cache is "better" (according to whatever criteria). If the cache tries to fetch the content the request may pass by the client and go through the same "bad" link plus twice through the "good" one. Cache ====Link1(good)==== Client -----------Link2(bad)----------- Server This becomes even more important if we want to generalize ALTO and use it, e.g., to select media relays for VoIP NAT traversal: UserA UserB | | NAT NAT | | Relay1 ====L1(medium)====+---------L2(bad)---------+==L3(good)== Relay2 | NAT | UserC UserA should tell the ALTO service not only that it needs "a VoIP relay" but also that he wants to talk to UserB. Thanks, Sebastian -- Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 14 12:49: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 8521F3A6BD6; Mon, 14 Jul 2008 12:49: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 2247B3A6BDA for ; Mon, 14 Jul 2008 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_14=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 XVIq25jDazRG for ; Mon, 14 Jul 2008 12:49:31 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id ADE0D3A6BD6 for ; Mon, 14 Jul 2008 12:49:30 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48054300; Mon, 14 Jul 2008 15:49:44 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 15:49:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 15:49:43 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CBE49@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <2115964082.501721215789670719.JavaMail.root@dkny.pando.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjjaiFTuITiIUeFSnGSGX520OimFACgHwlg References: <2115964082.501721215789670719.JavaMail.root@dkny.pando.com> From: "Livingood, Jason" To: "Laird Popkin" , "Reinaldo Penno" X-OriginalArrivalTime: 14 Jul 2008 19:49:43.0597 (UTC) FILETIME=[C2F47DD0:01C8E5EA] Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 - It may be helpful to post what you think the precise mapping of P4P concepts into the ALTO terms will be. That should help guide some of the P4Pers and folks doing P4P tests right now. Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Laird Popkin > Sent: Friday, July 11, 2008 11:21 AM > To: Reinaldo Penno > Cc: PAPADIMITRIOU Dimitri; p2pi@ietf.org; Saverio Niccolini > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Whether ALTO covers one or both depends on the contents of > the ALTO messages, which is intentionally quite abstract at > the moment. This is intentional, so that ALTO can be used to > express a wide range of possible p2p optimization strategies. > > To express what P4P does in ALTO, for example, I could > imagine that the P4P iTracker is an ALTO client to the ISP's > ALTO server, and is an ALTO server to the P2P network's ALTO > client, with different levels of information flowing through > each ALTO client/server communication. That is, I believe, > within the scope of what we expressed in the ALTO requirments. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Saverio Niccolini" > , "Enrico Marocco" > , "PAPADIMITRIOU Dimitri" > > Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Hello, > > The latter does not seem to be part of the charter at this > point. It certainly needs to be part of any working solution > but I'm not sure if it can be easily standardized. > > Thanks, > > Reinaldo > > On 7/10/08 8:29 AM, "Laird Popkin" wrote: > > > LP: I would say that there are two layers of communication > that ALTO > > needs to address. One layer is between the ALTO client > (e.g. p2p app, > > p2p server) and the ALTO server, and the second is between the ALTO > > server and the source of network topology information (e.g. > ISP, third-party). > > > _______________________________________________ > 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 Jul 14 13:03: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 B06DD3A6B5A; Mon, 14 Jul 2008 13:03: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 096DE3A67B7 for ; Mon, 14 Jul 2008 13:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, 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 4AEvBnN9bPUA for ; Mon, 14 Jul 2008 13:03:26 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BFC973A6BDD for ; Mon, 14 Jul 2008 13:02:59 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8089310; Mon, 14 Jul 2008 16:03:04 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 16:03:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:03:03 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CBE4A@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20080714154115.GE5618@foo.nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjlyCCPGNA5/dA5R8WmEjZ9s6kYPAAI/9wg References: <48777404.4080208@alcatel-lucent.com><1207275551.501631215789041098.JavaMail.root@dkny.pando.com> <20080714154115.GE5618@foo.nw.neclab.eu> From: "Livingood, Jason" To: "Sebastian Kiesel" , "Laird Popkin" X-OriginalArrivalTime: 14 Jul 2008 20:03:04.0706 (UTC) FILETIME=[A0740620:01C8E5EC] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 So are you suggesting that you may want a response to the client to include multiple responses (cache and content) so that a client can try them in sequence or in parallel? I think I understand the problem of rare content, but perhaps in the p2p area the speed of finding the optimal resource for the content has been a lower priority than finding a high-speed resource (since a file transfer could take several minutes to hours). This is quite different from a real-time application in that way I suppose. Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Sebastian Kiesel > Sent: Monday, July 14, 2008 11:41 AM > To: Laird Popkin > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: > > For this level of discussion, I agree that caches should simply be > > viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., > content where the likelyhood is high, that there is a cache > miss when we ask for it and that the cache will never deliver > a second copy of it? It might not be wise to select a cache > which is in the "opposite direction" of the original content, > even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch > the content the request may pass by the client and go through > the same "bad" > link plus twice through the "good" one. > > Cache ====Link1(good)==== Client > -----------Link2(bad)----------- Server > > > This becomes even more important if we want to generalize > ALTO and use it, e.g., to select media relays for VoIP NAT traversal: > > UserA UserB > | | > NAT NAT > | | > Relay1 > ====L1(medium)====+---------L2(bad)---------+==L3(good)== Relay2 > | > NAT > | > UserC > > UserA should tell the ALTO service not only that it needs "a > VoIP relay" > but also that he wants to talk to UserB. > > > > Thanks, > Sebastian > > > -- > Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu > Network Research Division tel:+49-6221-4342-232 > fax:+49-6221-4342-155 > NEC Laboratories Europe Kurfuerstenanlage 36, 69115 > Heidelberg, Germany > -- > NEC Europe Limited Registered in England 2832014 > Registered Office NEC House, 1 Victoria Road, London W3 6BL > _______________________________________________ > 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 Jul 14 13:35: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 EB20B28C32A; Mon, 14 Jul 2008 13:35: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 AA0F528C271 for ; Mon, 14 Jul 2008 13:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 g3Uy2Y5iwB4v for ; Mon, 14 Jul 2008 13:35:32 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 9B4B128C379 for ; Mon, 14 Jul 2008 13:33:52 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2221096ywj.49 for ; Mon, 14 Jul 2008 13:33:59 -0700 (PDT) Received: by 10.114.112.1 with SMTP id k1mr18177120wac.10.1216067639156; Mon, 14 Jul 2008 13:33:59 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id l36sm8141623waf.45.2008.07.14.13.33.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 13:33:58 -0700 (PDT) Message-Id: <95115A54-9622-40C3-B4E0-34A525276923@shlang.com> From: Stanislav Shalunov To: Sebastian Kiesel In-Reply-To: <20080714154115.GE5618@foo.nw.neclab.eu> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 14 Jul 2008 13:33:56 -0700 References: <48777404.4080208@alcatel-lucent.com> <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> <20080714154115.GE5618@foo.nw.neclab.eu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Even when content is going to be downloaded by an AS exactly once, there can be benefits to using a cache. Consider a network like cable where uplink capacity is scarce and shared. Running through a cache can enable one to use less of it. The fact that the content will pass twice through a link between the datacenter and the ISP's backbone is no big deal -- it's a fast fiber connection and can handle far more traffic than the cable uplink. In general, however, caching strategies is a rich field ("all computer science" and all that). The good news that the strategy can be left up to the applications and the caches. There's no interoperability need to make it standard. -- Stas On Jul 14, 2008, at 8:41 AM, Sebastian Kiesel wrote: > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >> For this level of discussion, I agree that caches should simply be >> viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., content > where > the likelyhood is high, that there is a cache miss when we ask for it > and that the cache will never deliver a second copy of it? It might > not > be wise to select a cache which is in the "opposite direction" of the > original content, even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch the > content the request may pass by the client and go through the same > "bad" > link plus twice through the "good" one. > > Cache ====Link1(good)==== Client -----------Link2(bad)----------- > Server > > > This becomes even more important if we want to generalize ALTO and use > it, e.g., to select media relays for VoIP NAT traversal: > > UserA UserB > | | > NAT NAT > | | > Relay1 ====L1(medium)====+---------L2(bad)---------+==L3(good)== > Relay2 > | > NAT > | > UserC > > UserA should tell the ALTO service not only that it needs "a VoIP > relay" > but also that he wants to talk to UserB. > > > > Thanks, > Sebastian > > > -- > Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu > Network Research Division tel:+49-6221-4342-232 fax: > +49-6221-4342-155 > NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, > Germany > -- > NEC Europe Limited Registered in England 2832014 > Registered Office NEC House, 1 Victoria Road, London W3 6BL > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 14 13:57: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 31A413A680A; Mon, 14 Jul 2008 13:57: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 6F5413A659B for ; Mon, 14 Jul 2008 13:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=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 BYaxgAev5DgL for ; Mon, 14 Jul 2008 13:57:55 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C4B6F3A680A for ; Mon, 14 Jul 2008 13:57:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D089AE10C49; Mon, 14 Jul 2008 16:58:19 -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 XjM+y1jmMopA; Mon, 14 Jul 2008 16:58:05 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 770CCE10C70; Mon, 14 Jul 2008 16:58:05 -0400 (EDT) Date: Mon, 14 Jul 2008 16:58:05 -0400 (EDT) From: Laird Popkin To: Jason Livingood Message-ID: <1641736664.5891216069085442.JavaMail.root@dkny.pando.com> In-Reply-To: <575143769.5871216068410941.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri , Saverio Niccolini Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Good idea. Here's a quick explanation of P4P. There's more info at http://www.openp4p.net/. The components in P4P are: - p2p client - p2p server (coordinates p2p network, optional). - P4P optimizer engine (iTracker that creates unified view from multiple ISP iTrackers) - iTracker server (run by ISP or third party) - ISP The data flow is: - ISP generates network map and policies, loads them into their iTracker. This map is expressed as locations (called PIDs), each with lists of IP prefixes of addresses, and ASNs, with 'costs' provided for interconnections between each PID-PID or PID-ASN pair. - The ISP iTracker exposes an 'abstract weight matrix' of all PID-PID and PID-ASN pairs for the ISP. - The P2P server gets the PID definitions (lists of IP prefixes for each location) from each ISP iTracker. This is a one-time retrieval (or daily, etc.). - The "optimization engine" iTracker retrieves the weight matrixes from each ISP iTracker, and generates a unified weight matrix. - P2P server sends a list of peer locations to the optimizer engine, and gets a weight matrix for all PID-PID and PID-ASN connections for all ISPs. This is done for each swarm, and updates periodically, as the weights vary over time depending on the peer distribution and changing network conditions (e.g. a link outage, time of day, etc.). This is an expensive communication, as it has to be handled for each (popular) swarm, every few minutes. - Alternatively the guidance ignores peer distribution, so the P2P server retrieves a full weight matrix. This is a much cheaper implementation (e.g. one message, or daily, etc.). OK, so how does this map into ALTO? Where I think that ALTO could apply: - The protocol between the p2p server and the iTrackers could be ALTO. The contents of the message would be lists of network locations (e.g. IP prefixes, PIDs) and weights (e.g. floating point numbers between 0 and 1). - The protocol between the iTrackers (e.g. the "optimization engine" and the ISP iTrackers) could be ALTO. This is pretty much the same kind of communication as above, though a different path. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Jason Livingood" To: "Laird Popkin" , "Reinaldo Penno" Cc: "PAPADIMITRIOU Dimitri" , p2pi@ietf.org, "Saverio Niccolini" Sent: Monday, July 14, 2008 3:49:43 PM (GMT-0500) America/New_York Subject: RE: [p2pi] ALTO BoF - generalize the problem Laird - It may be helpful to post what you think the precise mapping of P4P concepts into the ALTO terms will be. That should help guide some of the P4Pers and folks doing P4P tests right now. Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Laird Popkin > Sent: Friday, July 11, 2008 11:21 AM > To: Reinaldo Penno > Cc: PAPADIMITRIOU Dimitri; p2pi@ietf.org; Saverio Niccolini > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Whether ALTO covers one or both depends on the contents of > the ALTO messages, which is intentionally quite abstract at > the moment. This is intentional, so that ALTO can be used to > express a wide range of possible p2p optimization strategies. > > To express what P4P does in ALTO, for example, I could > imagine that the P4P iTracker is an ALTO client to the ISP's > ALTO server, and is an ALTO server to the P2P network's ALTO > client, with different levels of information flowing through > each ALTO client/server communication. That is, I believe, > within the scope of what we expressed in the ALTO requirments. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Saverio Niccolini" > , "Enrico Marocco" > , "PAPADIMITRIOU Dimitri" > > Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > Hello, > > The latter does not seem to be part of the charter at this > point. It certainly needs to be part of any working solution > but I'm not sure if it can be easily standardized. > > Thanks, > > Reinaldo > > On 7/10/08 8:29 AM, "Laird Popkin" wrote: > > > LP: I would say that there are two layers of communication > that ALTO > > needs to address. One layer is between the ALTO client > (e.g. p2p app, > > p2p server) and the ALTO server, and the second is between the ALTO > > server and the source of network topology information (e.g. > ISP, third-party). > > > _______________________________________________ > 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 Jul 14 14:14: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 4F7233A6ADF; Mon, 14 Jul 2008 14:14: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 30AEA28C1A8 for ; Mon, 14 Jul 2008 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.043, 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 b2BB4xbAoRTX for ; Mon, 14 Jul 2008 14:14:36 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2916C3A6842 for ; Mon, 14 Jul 2008 14:14:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 95607E10C82; Mon, 14 Jul 2008 17:15: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 NuWNeoQMnGK8; Mon, 14 Jul 2008 17:14:51 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 44299E10C80; Mon, 14 Jul 2008 17:14:51 -0400 (EDT) Date: Mon, 14 Jul 2008 17:14:51 -0400 (EDT) From: Laird Popkin To: Lars Eggert Message-ID: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> In-Reply-To: <791289239.5961216069745743.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 P2P applications have the problem that they're told about the network's performance only on a per-stream basis, but they have to make decisions on a global basis, not just a stream basis. If the p2p app knows the user's link capacity, or preferably the link status (e.g. is it saturated?) then the app can make better choices. For example, should I try to establish more peer connections to speed data transfers, or have I saturated the user's internet access link? If the latter, may want to throttle myself in order to decongest the user's internet connection (or DSLAM, etc.) which is better for everyone. Yes, there are scenarios where it's not clear whether there is a relevant link capacity, etc., but I'm fine getting no guidance in those situations. Even an 80% accurate knowledge of what the user's network capacity is would be a big improvement over the current situation. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Lars Eggert" To: "ext Salman Abdul Baset" Cc: p2pi@ietf.org Sent: Monday, July 14, 2008 3:22:46 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem On 2008-7-14, at 10:13, ext Salman Abdul Baset wrote: > Obviously, measuring the path capacity or using the path is required > when the connection type indicates to the app that it should have > enough capacity. > > When the connection type indicates to the app that it does not have > enough capacity say for relaying a VoIP or video call, the > application does not need to measure anything. It knows that it > cannot do the requested work and will never advertise its relay > service thereby avoiding the measurement of transient available > capacity. OK, so be conservative and default to off, i.e., only offer to relay after your network usage has left you convinced that you have capacity to be a relay. This should even have some benefits to the peers, because only nodes that have been around for a bit will become relays. Getting this information from an oracle doesn't save you any work, because even if your nominal uplink capacity could let you be a relay, you still need to figure out if the current load on it actually lets you. Plus, there are obviously uplink types with no stable capacity (3G, WiMax, etc.) where this won't work anyway. 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 Tue Jul 15 01:03: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 A42203A6839; Tue, 15 Jul 2008 01:03: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 3176A3A6839 for ; Tue, 15 Jul 2008 01:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 pTV5ZztjxmD3 for ; Tue, 15 Jul 2008 01:03:48 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3FBE73A6803 for ; Tue, 15 Jul 2008 01:03:48 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6F83nmk015016; Tue, 15 Jul 2008 03:04:07 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 11:04:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 11:03:55 +0300 Received: from net-56.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 11:03:54 +0300 Message-Id: From: Lars Eggert To: ext Laird Popkin In-Reply-To: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 11:03:49 +0300 References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 15 Jul 2008 08:03:55.0302 (UTC) FILETIME=[53D13C60:01C8E651] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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-7-15, at 0:14, ext Laird Popkin wrote: > P2P applications have the problem that they're told about the > network's performance only on a per-stream basis, but they have to > make decisions on a global basis, not just a stream basis. Sure, but if you're willing to assume that the access link is always the bottleneck, surely you can assume that all your streams go through that access link? That lets you infer path characteristics based on aggregate stream characteristics. > If the p2p app knows the user's link capacity, or preferably the > link status (e.g. is it saturated?) then the app can make better > choices. For example, should I try to establish more peer > connections to speed data transfers, or have I saturated the user's > internet access link? If the latter, may want to throttle myself in > order to decongest the user's internet connection (or DSLAM, etc.) > which is better for everyone. If the access is the bottleneck, and there was some way to get this information accurately, reliably and in a very timely fashion - maybe. But you're redefining the basics of Internet congestion control here, turning it from an approach where the ends probe the path and adapt to one where network-provided information drives the congestion control loop. That's way beyond what I'd consider appropriate for ALTO to tackle at this stage. Note that I'm not saying that we should never think about this. There are related proposals that attempt to give the network a more active role in end-to-end resource control (Briscoe's re-feedback, some ideas by Matt Mathis, etc.) But if we do something along those lines, we need to think hard how this interacts with the rest of the architecture. > Yes, there are scenarios where it's not clear whether there is a > relevant link capacity, etc., but I'm fine getting no guidance in > those situations. Even an 80% accurate knowledge of what the user's > network capacity is would be a big improvement over the current > situation. Not without additional information. If I run five P2P apps on different machines in my home and they all know my access link capacity through some mechanism, they'll still self-interfere before they have ramped up to that capacity. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 04:44: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 8943C3A6997; Tue, 15 Jul 2008 04:44: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 E16E73A67D9 for ; Tue, 15 Jul 2008 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.038, 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 INF2NDE+Ljjk for ; Tue, 15 Jul 2008 04:44:33 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 7D6843A68B5 for ; Tue, 15 Jul 2008 04:44:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 98175E10B17; Tue, 15 Jul 2008 07:44: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 lQAmelLFvMxf; Tue, 15 Jul 2008 07:44:36 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 3DF0EE10B08; Tue, 15 Jul 2008 07:44:36 -0400 (EDT) Date: Tue, 15 Jul 2008 07:44:36 -0400 (EDT) From: Laird Popkin To: Lars Eggert Message-ID: <1322598529.6411216122276212.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 there are ways to try to derive link capacity, and to try to guess whether the link is saturated, but they're all (in real life) wildly inaccurate. I agree that link capacity is of limited value, due to multiple applications interacting (and multiple computers, etc.). Link congestion status is a lot more valuable, IMO. None of this eliminates the need to do stream-level congestion management, of course. :-) Yes, I've been tracking Re-ECN. It looks very interesting, and I hope to learn more at the IETF meeting. If it's available "in the wild" that would be great. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Lars Eggert" To: "ext Laird Popkin" Cc: p2pi@ietf.org, "ext Salman Abdul Baset" Sent: Tuesday, July 15, 2008 4:03:49 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem Hi, On 2008-7-15, at 0:14, ext Laird Popkin wrote: > P2P applications have the problem that they're told about the > network's performance only on a per-stream basis, but they have to > make decisions on a global basis, not just a stream basis. Sure, but if you're willing to assume that the access link is always the bottleneck, surely you can assume that all your streams go through that access link? That lets you infer path characteristics based on aggregate stream characteristics. > If the p2p app knows the user's link capacity, or preferably the > link status (e.g. is it saturated?) then the app can make better > choices. For example, should I try to establish more peer > connections to speed data transfers, or have I saturated the user's > internet access link? If the latter, may want to throttle myself in > order to decongest the user's internet connection (or DSLAM, etc.) > which is better for everyone. If the access is the bottleneck, and there was some way to get this information accurately, reliably and in a very timely fashion - maybe. But you're redefining the basics of Internet congestion control here, turning it from an approach where the ends probe the path and adapt to one where network-provided information drives the congestion control loop. That's way beyond what I'd consider appropriate for ALTO to tackle at this stage. Note that I'm not saying that we should never think about this. There are related proposals that attempt to give the network a more active role in end-to-end resource control (Briscoe's re-feedback, some ideas by Matt Mathis, etc.) But if we do something along those lines, we need to think hard how this interacts with the rest of the architecture. > Yes, there are scenarios where it's not clear whether there is a > relevant link capacity, etc., but I'm fine getting no guidance in > those situations. Even an 80% accurate knowledge of what the user's > network capacity is would be a big improvement over the current > situation. Not without additional information. If I run five P2P apps on different machines in my home and they all know my access link capacity through some mechanism, they'll still self-interfere before they have ramped up to that capacity. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 04:58: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 F1F603A68EB; Tue, 15 Jul 2008 04:58:09 -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 71B963A68E3 for ; Tue, 15 Jul 2008 04:58:09 -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 DSnha1jaVplp for ; Tue, 15 Jul 2008 04:58:08 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 96BB23A6833 for ; Tue, 15 Jul 2008 04:58:08 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6FBwXlA008148; Tue, 15 Jul 2008 07:58:33 -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 m6FBwXvI007283; Tue, 15 Jul 2008 07:58:33 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6FBwXeo007280; Tue, 15 Jul 2008 07:58:33 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 15 Jul 2008 07:58:33 -0400 (EDT) From: Salman Abdul Baset To: Lars Eggert In-Reply-To: Message-ID: References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.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 Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Tue, 15 Jul 2008, Lars Eggert wrote: >> Yes, there are scenarios where it's not clear whether there is a relevant >> link capacity, etc., but I'm fine getting no guidance in those situations. >> Even an 80% accurate knowledge of what the user's network capacity is would >> be a big improvement over the current situation. > > Not without additional information. If I run five P2P apps on different > machines in my home and they all know my access link capacity through some > mechanism, they'll still self-interfere before they have ramped up to that > capacity. > It seems that this is a scenario where cable/DSL modem should pass information of self-interference to other machines behind the same modem. For example, if mom/dad is using the Internet connection for work and are not getting the expected speed, they will like to know which child/device is hogging the connection. -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 05:25: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 1BE743A68E3; Tue, 15 Jul 2008 05:25: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 91DE13A684A for ; Tue, 15 Jul 2008 05:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.533 X-Spam-Level: X-Spam-Status: No, score=-0.533 tagged_above=-999 required=5 tests=[AWL=0.186, 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 Lro1PMlrELVO for ; Tue, 15 Jul 2008 05:25:07 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 592B33A68E3 for ; Tue, 15 Jul 2008 05:25:04 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 14:25:31 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 14:25:31 +0200 Received: from [10.229.8.73] (10.229.8.73) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 15 Jul 2008 14:25:30 +0200 Message-ID: <487C9722.20602@telecomitalia.it> Date: Tue, 15 Jul 2008 14:25:06 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Salman Abdul Baset References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 15 Jul 2008 12:25:31.0240 (UTC) FILETIME=[DF534E80:01C8E675] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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="===============2134812818==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2134812818== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030508030106000607090800" --------------ms030508030106000607090800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Salman Abdul Baset wrote: >>> Yes, there are scenarios where it's not clear whether there is a relevant >>> link capacity, etc., but I'm fine getting no guidance in those situations. >>> Even an 80% accurate knowledge of what the user's network capacity is would >>> be a big improvement over the current situation. >> Not without additional information. If I run five P2P apps on different >> machines in my home and they all know my access link capacity through some >> mechanism, they'll still self-interfere before they have ramped up to that >> capacity. > > It seems that this is a scenario where cable/DSL modem should pass > information of self-interference to other machines behind the same modem. > For example, if mom/dad is using the Internet connection for work and are > not getting the expected speed, they will like to know which child/device is > hogging the connection. This discussion is certainly interesting, but it is not about ALTO any more, is it? I mean, in this context we are trying to charter a working group for developing some mechanism for optimizing peer selection. At best, "network" information will be used for selecting between a peer with FTTH access and a DSL ones, when no additional information is available. The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly covers transport issues like congestion notification and sharing of network resources; its problem statement is available at: http://tools.ietf.org/id/draft-shalunov-tana-problem-statement -- Ciao, Enrico --------------ms030508030106000607090800 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTUxMjI1MDZaMCMG CSqGSIb3DQEJBDEWBBRuoag21zc9rQ7BXPyijK1Y01VbQzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBACs7IQiL03Xp XNLtX4mKqNHbnI5Lha/WXtx6czqNKekm3ePsO8YXgJRoChgm+Luo18f0U+M8u3pf+kcLCLbn mEvFzqDbhicHFDTTCzP0ow9hNXnUBx4oDYURAkWaQnNsrSV6zw3XOIe8Cynw9msJ5ed8bvmV M8EHFp9VyPxDPp/bsiLiAw4fycEmIdt1bNKO7m+x3Ka0IEcjKHa89G4IfleM3OjxEgfhfY6C Kv1P13UH0xqXK+Vhs4Et9y4HGpG+jPcc3h5fmKzGOGWALHmUSddU63IDQmp+FrajHU8u0Hpe 4nk+wXn7wgM7Eh2OI1+lEI5PbO6qyy+RVvFKKN7NChUAAAAAAAA= --------------ms030508030106000607090800-- --===============2134812818== 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 --===============2134812818==-- From p2pi-bounces@ietf.org Tue Jul 15 06:15: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 887CA28C0FB; Tue, 15 Jul 2008 06:15: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 6DD2A28C0FB for ; Tue, 15 Jul 2008 06:15:58 -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 ulfNkZjtxsTN for ; Tue, 15 Jul 2008 06:15:57 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 1EF9628C0E1 for ; Tue, 15 Jul 2008 06:15:57 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6FDGHhN021637; Tue, 15 Jul 2008 09:16:18 -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 m6FDGHuW002542; Tue, 15 Jul 2008 09:16:17 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6FDGH1p002535; Tue, 15 Jul 2008 09:16:17 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 15 Jul 2008 09:16:17 -0400 (EDT) From: Salman Abdul Baset To: Enrico Marocco In-Reply-To: <487C9722.20602@telecomitalia.it> Message-ID: References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> <487C9722.20602@telecomitalia.it> 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" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Tue, 15 Jul 2008, Enrico Marocco wrote: > Salman Abdul Baset wrote: >>>> Yes, there are scenarios where it's not clear whether there is a relevant >>>> link capacity, etc., but I'm fine getting no guidance in those situations. >>>> Even an 80% accurate knowledge of what the user's network capacity is would >>>> be a big improvement over the current situation. >>> Not without additional information. If I run five P2P apps on different >>> machines in my home and they all know my access link capacity through some >>> mechanism, they'll still self-interfere before they have ramped up to that >>> capacity. >> >> It seems that this is a scenario where cable/DSL modem should pass >> information of self-interference to other machines behind the same modem. >> For example, if mom/dad is using the Internet connection for work and are >> not getting the expected speed, they will like to know which child/device is >> hogging the connection. > > This discussion is certainly interesting, but it is not about ALTO any > more, is it? I mean, in this context we are trying to charter a working > group for developing some mechanism for optimizing peer selection. At > best, "network" information will be used for selecting between a peer > with FTTH access and a DSL ones, when no additional information is > available. Information about self-interference can guide peer selection. For example, with this information, a P2PSIP application running on one of several machines behind the cable/DSL modem can more accurately determine the presence or absence of self-interference. In the absence of self-interference and after network usage has left the P2PSIP application convinced that it has enough capacity, it can advertise itself as a relay in the overlay. > The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly > covers transport issues like congestion notification and sharing of > network resources; its problem statement is available at: > http://tools.ietf.org/id/draft-shalunov-tana-problem-statement It is not clear to me whether it will/should be in the scope of ALTO or TANA to address the self-interference issue. Note that self-interference can be categorized as (1) interference with applications running on the *same* machine (2) interference with applications running on *different* machines that are behind the same cable/DSL modem. -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 06:32: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 13EC13A686A; Tue, 15 Jul 2008 06:32: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 719C93A6961 for ; Tue, 15 Jul 2008 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=0.155, 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 BAi70N+-zxuF for ; Tue, 15 Jul 2008 06:32:16 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 0F1033A6899 for ; Tue, 15 Jul 2008 06:32:15 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 15:32:43 +0200 Received: from GRFHUB703BA020.griffon.local ([10.188.101.113]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 15:32:42 +0200 Received: from [10.229.8.73] (10.229.8.73) by smtp.telecomitalia.it (10.188.101.116) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 15 Jul 2008 15:32:42 +0200 Message-ID: <487CA6E2.5010702@telecomitalia.it> Date: Tue, 15 Jul 2008 15:32:18 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Sebastian Kiesel References: <48777404.4080208@alcatel-lucent.com> <1207275551.501631215789041098.JavaMail.root@dkny.pando.com> <20080714154115.GE5618@foo.nw.neclab.eu> In-Reply-To: <20080714154115.GE5618@foo.nw.neclab.eu> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 15 Jul 2008 13:32:42.0954 (UTC) FILETIME=[426A0AA0:01C8E67F] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============0522132477==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0522132477== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060501050907050209060506" --------------ms060501050907050209060506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sebastian Kiesel wrote: > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >> For this level of discussion, I agree that caches should simply be >> viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., content where > the likelyhood is high, that there is a cache miss when we ask for it > and that the cache will never deliver a second copy of it? It might not > be wise to select a cache which is in the "opposite direction" of the > original content, even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch the > content the request may pass by the client and go through the same "bad" > link plus twice through the "good" one. As long as caches are viewed as regular peers, they will be included in ALTO requests/responses only if they actually have the resource the querying peer wants to access. -- Ciao, Enrico --------------ms060501050907050209060506 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTUxMzMyMThaMCMG CSqGSIb3DQEJBDEWBBRbdr3Z9dbudY+zkBIjYGwi+DjhvzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAGvtux3bWG8X eK22aDCH0CGrGUvpj5pZSTEhopoqdZGQZbsUKvkJ0OjWs03OdVUQyIIH3p9hvWbQygyBr7tP a2sOkfeFSNx0BaVNUXxzcnQt0t5zSXOGAWpA+aNkCstR9zjSxrxBVgBwan2srpTA+ijLh5Vr ojn3ghw3e4NX6DMt26EEYiNA6diqDt+AiFv4bEU72eRdsWFsThLfL+Pi0BEpdPQCvKLUHdYt B5qEbPEjeQpf2+GKRN3Zr2ppFFKVc7FcmgzkKE4WBRG3RDhbpoupaa7Sj9YLJoSWO+f/MKMJ cR2jXC04htQP5rf1JEDXXX8El16aPCQvwK+mKyM5UE8AAAAAAAA= --------------ms060501050907050209060506-- --===============0522132477== 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 --===============0522132477==-- From p2pi-bounces@ietf.org Tue Jul 15 06:37: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 36B4A3A68ED; Tue, 15 Jul 2008 06:37: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 80CB43A686A for ; Tue, 15 Jul 2008 06:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.033, 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 1WU4zLBIdYw9 for ; Tue, 15 Jul 2008 06:37:48 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id A78653A6780 for ; Tue, 15 Jul 2008 06:37:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 1176EE10B18; Tue, 15 Jul 2008 09:38:16 -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 Zfvs2n+0od9c; Tue, 15 Jul 2008 09:38:15 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 7E75AE10B17; Tue, 15 Jul 2008 09:38:15 -0400 (EDT) Date: Tue, 15 Jul 2008 09:38:15 -0400 (EDT) From: Laird Popkin To: Enrico Marocco Message-ID: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> In-Reply-To: <487CA6E2.5010702@telecomitalia.it> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Actually, caches will probably want to be included in all ALTO responses so that they are contacted by peers, so that they can determine whether they want to cache the content (and have a data source for the cache if so). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Enrico Marocco" To: "Sebastian Kiesel" Cc: "Laird Popkin" , p2pi@ietf.org Sent: Tuesday, July 15, 2008 9:32:18 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Charter and problem statement Sebastian Kiesel wrote: > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >> For this level of discussion, I agree that caches should simply be >> viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., content where > the likelyhood is high, that there is a cache miss when we ask for it > and that the cache will never deliver a second copy of it? It might not > be wise to select a cache which is in the "opposite direction" of the > original content, even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch the > content the request may pass by the client and go through the same "bad" > link plus twice through the "good" one. As long as caches are viewed as regular peers, they will be included in ALTO requests/responses only if they actually have the resource the querying peer wants to access. -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 06:41: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 447E03A68ED; Tue, 15 Jul 2008 06:41: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 667AC3A686A for ; Tue, 15 Jul 2008 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.030, 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 G3hBNX5poL+t for ; Tue, 15 Jul 2008 06:41:06 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 1B1793A69D3 for ; Tue, 15 Jul 2008 06:41:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id CBD32E10B1E; Tue, 15 Jul 2008 09:41:33 -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 s7UBlWtRlLiX; Tue, 15 Jul 2008 09:41:26 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 5FF8DE10AC3; Tue, 15 Jul 2008 09:41:26 -0400 (EDT) Date: Tue, 15 Jul 2008 09:41:26 -0400 (EDT) From: Laird Popkin To: Salman Abdul Baset Message-ID: <28034971.6741216129286370.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 In terms of whether this issue is more appropriate in TANA or ALTO, I gather that we'll need to work that out at the BOFs. But I hope that it fits within one of them. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Salman Abdul Baset" To: "Enrico Marocco" Cc: p2pi@ietf.org Sent: Tuesday, July 15, 2008 9:16:17 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem On Tue, 15 Jul 2008, Enrico Marocco wrote: > Salman Abdul Baset wrote: >>>> Yes, there are scenarios where it's not clear whether there is a relevant >>>> link capacity, etc., but I'm fine getting no guidance in those situations. >>>> Even an 80% accurate knowledge of what the user's network capacity is would >>>> be a big improvement over the current situation. >>> Not without additional information. If I run five P2P apps on different >>> machines in my home and they all know my access link capacity through some >>> mechanism, they'll still self-interfere before they have ramped up to that >>> capacity. >> >> It seems that this is a scenario where cable/DSL modem should pass >> information of self-interference to other machines behind the same modem. >> For example, if mom/dad is using the Internet connection for work and are >> not getting the expected speed, they will like to know which child/device is >> hogging the connection. > > This discussion is certainly interesting, but it is not about ALTO any > more, is it? I mean, in this context we are trying to charter a working > group for developing some mechanism for optimizing peer selection. At > best, "network" information will be used for selecting between a peer > with FTTH access and a DSL ones, when no additional information is > available. Information about self-interference can guide peer selection. For example, with this information, a P2PSIP application running on one of several machines behind the cable/DSL modem can more accurately determine the presence or absence of self-interference. In the absence of self-interference and after network usage has left the P2PSIP application convinced that it has enough capacity, it can advertise itself as a relay in the overlay. > The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly > covers transport issues like congestion notification and sharing of > network resources; its problem statement is available at: > http://tools.ietf.org/id/draft-shalunov-tana-problem-statement It is not clear to me whether it will/should be in the scope of ALTO or TANA to address the self-interference issue. Note that self-interference can be categorized as (1) interference with applications running on the *same* machine (2) interference with applications running on *different* machines that are behind the same cable/DSL modem. -s _______________________________________________ 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 Jul 15 06:41: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 7323D28C0F3; Tue, 15 Jul 2008 06:41: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 E775128C0DC for ; Tue, 15 Jul 2008 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5VvWQstpVrQL for ; Tue, 15 Jul 2008 06:41: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 AEC0A28C0E1 for ; Tue, 15 Jul 2008 06:41:12 -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 m6FDfTp20766; Tue, 15 Jul 2008 15:41:29 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6FDfSA12618; Tue, 15 Jul 2008 15:41:28 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 15 Jul 2008 15:41:04 +0200 From: stefano previdi To: Laird Popkin , Enrico Marocco Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjmgG0Pq4R1ulJzEd2IrgAX8vOM8g== In-Reply-To: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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, do you suggest to make the cache entity explicit in the ALTO protocol semantic ? Or is it just part of the opaque protocol data the algorithm (not under standardization at this point) will work with ? I'd vote for the latter... thanks. s. > From: Laird Popkin > Date: Tue, 15 Jul 2008 09:38:15 -0400 (EDT) > To: Enrico Marocco > Cc: > Subject: Re: [p2pi] Charter and problem statement > > Actually, caches will probably want to be included in all ALTO responses so > that they are contacted by peers, so that they can determine whether they want > to cache the content (and have a data source for the cache if so). > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Enrico Marocco" > To: "Sebastian Kiesel" > Cc: "Laird Popkin" , p2pi@ietf.org > Sent: Tuesday, July 15, 2008 9:32:18 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] Charter and problem statement > > Sebastian Kiesel wrote: >> On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >>> For this level of discussion, I agree that caches should simply be >>> viewed as a peer in ALTO. >> >> What happens if we consider caches and rare content, i.e., content where >> the likelyhood is high, that there is a cache miss when we ask for it >> and that the cache will never deliver a second copy of it? It might not >> be wise to select a cache which is in the "opposite direction" of the >> original content, even if connectivity to the cache is "better" >> (according to whatever criteria). If the cache tries to fetch the >> content the request may pass by the client and go through the same "bad" >> link plus twice through the "good" one. > > As long as caches are viewed as regular peers, they will be included in > ALTO requests/responses only if they actually have the resource the > querying peer wants to access. > > -- > 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 Jul 15 06:45: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 DE8C53A6AEF; Tue, 15 Jul 2008 06:45: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 93AD23A6AEB for ; Tue, 15 Jul 2008 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 LqMbgycVHvNK for ; Tue, 15 Jul 2008 06:45:06 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 68A713A6AEA for ; Tue, 15 Jul 2008 06:45:05 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6FDj6JH020348; Tue, 15 Jul 2008 16:45:19 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 16:45:06 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 16:45:04 +0300 Received: from net-56.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 16:45:03 +0300 Message-Id: <7D4D83FE-294E-4FD3-94F6-91D99D0C9D43@nokia.com> From: Lars Eggert To: ext Salman Abdul Baset In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 16:44:58 +0300 References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> <487C9722.20602@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 15 Jul 2008 13:45:04.0087 (UTC) FILETIME=[FC29F670:01C8E680] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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-7-15, at 16:16, ext Salman Abdul Baset wrote: > On Tue, 15 Jul 2008, Enrico Marocco wrote: >> This discussion is certainly interesting, but it is not about ALTO >> any >> more, is it? I mean, in this context we are trying to charter a >> working >> group for developing some mechanism for optimizing peer selection. At >> best, "network" information will be used for selecting between a peer >> with FTTH access and a DSL ones, when no additional information is >> available. Agree with Enrico. > Information about self-interference can guide peer selection. For > example, with this information, a P2PSIP application running on one > of several machines behind the cable/DSL modem can more accurately > determine the presence or absence of self-interference. In the > absence of self-interference and after network usage has left the > P2PSIP application convinced that it has enough capacity, it can > advertise itself as a relay in the overlay. Sure, we can dream up all kinds of information that would be useful to an app or protocol: accurate and timely topology graph information, accurate and timely congestion information, accurate and timely latency information, etc. App wants to know this stuff? Talk to the oracle - done! This misses a bunch of key issues, though: * Is it even possible for the oracle to gather all this information? It's difficult for an app, sure - but why do we think it will be easier for an oracle? * How accurate would this information be, how timely would it be and what is the cost to gather and keep it up-to date? * How much interdepence does this create between layers that were so far more loosely coupled? Are we giving up evolvability? * How much "better" (for some definition of better) will this information let the app become? Is it worth the architectural complexity? To make this concrete, lets go back to the self-interference example: How would an access router figure out that a bunch of flows are interfering? On what timescales would this detection mechanism operate, and how sensitive would it be? Will the router need to assume that all flows adhere to some specific congestion control mechanism? How much will performance be improved? Without at least a credible attempt to answer these sorts of questions, I don't think we have a basis to begin thinking about standardization. (And I agree that the more baked proposals in the ALTO space do have answers here.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 07:58: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 817133A68CC; Tue, 15 Jul 2008 07:58: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 730613A6A79 for ; Tue, 15 Jul 2008 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.205, 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 adCJMLCUIZ0G for ; Tue, 15 Jul 2008 07:58:54 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 68D8D3A68CC for ; Tue, 15 Jul 2008 07:58:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D21AC2C00035A; Tue, 15 Jul 2008 16:59:21 +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 h6xPG0fpvxsG; Tue, 15 Jul 2008 16:59:21 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id AD8752C000350; Tue, 15 Jul 2008 16:59:06 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.208]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 16:59:05 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Tue, 15 Jul 2008 16:59:05 +0200 Date: Tue, 15 Jul 2008 16:59:05 +0200 From: Sebastian Kiesel To: "Livingood, Jason" Message-ID: <20080715145905.GA7134@foo.nw.neclab.eu> References: <20080714154115.GE5618@foo.nw.neclab.eu> <45AEC6EF95942140888406588E1A6602045CBE4A@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602045CBE4A@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-OriginalArrivalTime: 15 Jul 2008 14:59:05.0815 (UTC) FILETIME=[53A3DE70:01C8E68B] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Mon, Jul 14, 2008 at 04:03:03PM -0400, Livingood, Jason wrote: > So are you suggesting that you may want a response to the client to > include multiple responses (cache and content) so that a client can try > them in sequence or in parallel? I am not sure what the conclusion is, I just wanted to raise the issue: The goal of ALTO is to provide information that cannot be acquired easily by the peers using measurements between each other. > I think I understand the problem of > rare content, but perhaps in the p2p area the speed of finding the > optimal resource for the content has been a lower priority than finding > a high-speed resource (since a file transfer could take several minutes > to hours). If it might happen that candidate caches do not already have the rare content, any recommendation should not only consider the link between client and cache but also the link from the cache to the "upstream source", from which the content is retrieved by the cache. thanks, Sebastian -- Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 08:10: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 031AD3A6AEF; Tue, 15 Jul 2008 08:10: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 7CB203A6AEF for ; Tue, 15 Jul 2008 08:10:32 -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 cJbutIeWd3XK for ; Tue, 15 Jul 2008 08:10:31 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 881233A67EC for ; Tue, 15 Jul 2008 08:10:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Jul 2008 08:10:05 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 08:10:02 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 08:10:01 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2008 11:10:00 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 15:09:57 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 15 Jul 2008 08:09:32 -0700 From: Reinaldo Penno To: stefano previdi , Laird Popkin , Enrico Marocco Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjmgG0Pq4R1ulJzEd2IrgAX8vOM8gADFvQT In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 15:10:00.0898 (UTC) FILETIME=[DA199A20:01C8E68C] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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, Well, this brings a question if we are here to standardize a client-server protocol or the data it carries as well. As we standardize the protocol we need to go through what kind of information it queries. Are these peers, network masks, weights, etc? How they are represented? What is mandatory and what is optional? These can be opaque to the protocol in the wire but certainly not to the application. Since we are talking about applications and we need to interoperate we need to define those. At least that was my assumption. If we are here to just standardize a client-server protocol, there many, many choices already available, including good ol' HTTP. So, if caches are just peers, they would be identified as peers or a special type of peer. Thanks, Reinaldo On 7/15/08 6:41 AM, "stefano previdi" wrote: > Laird, > > do you suggest to make the cache entity explicit in the ALTO protocol > semantic ? > > Or is it just part of the opaque protocol data the algorithm (not under > standardization at this point) will work with ? > > I'd vote for the latter... > > thanks. > > s. > >> From: Laird Popkin >> Date: Tue, 15 Jul 2008 09:38:15 -0400 (EDT) >> To: Enrico Marocco >> Cc: >> Subject: Re: [p2pi] Charter and problem statement >> >> Actually, caches will probably want to be included in all ALTO responses so >> that they are contacted by peers, so that they can determine whether they >> want >> to cache the content (and have a data source for the cache if so). >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Enrico Marocco" >> To: "Sebastian Kiesel" >> Cc: "Laird Popkin" , p2pi@ietf.org >> Sent: Tuesday, July 15, 2008 9:32:18 AM (GMT-0500) America/New_York >> Subject: Re: [p2pi] Charter and problem statement >> >> Sebastian Kiesel wrote: >>> On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >>>> For this level of discussion, I agree that caches should simply be >>>> viewed as a peer in ALTO. >>> >>> What happens if we consider caches and rare content, i.e., content where >>> the likelyhood is high, that there is a cache miss when we ask for it >>> and that the cache will never deliver a second copy of it? It might not >>> be wise to select a cache which is in the "opposite direction" of the >>> original content, even if connectivity to the cache is "better" >>> (according to whatever criteria). If the cache tries to fetch the >>> content the request may pass by the client and go through the same "bad" >>> link plus twice through the "good" one. >> >> As long as caches are viewed as regular peers, they will be included in >> ALTO requests/responses only if they actually have the resource the >> querying peer wants to access. >> >> -- >> 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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 08:12: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 E08FF3A6942; Tue, 15 Jul 2008 08:12: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 BE3203A6B34 for ; Tue, 15 Jul 2008 08:12: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 QSDXq6UHhjrj for ; Tue, 15 Jul 2008 08:12:12 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 987093A63D3 for ; Tue, 15 Jul 2008 08:11:56 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4100M5DZKOE4@usaga01-in.huawei.com> for p2pi@ietf.org; Tue, 15 Jul 2008 08:12:24 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4100H2ZZKM4R@usaga01-in.huawei.com> for p2pi@ietf.org; Tue, 15 Jul 2008 08:12:24 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [117.88.121.77]) by szxmc03-in.huawei.com (mshttpd); Tue, 15 Jul 2008 23:12:10 +0800 Date: Tue, 15 Jul 2008 23:12:10 +0800 From: songhaibin 64081 In-reply-to: <20080715145905.GA7134@foo.nw.neclab.eu> To: Sebastian Kiesel Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <20080714154115.GE5618@foo.nw.neclab.eu> <45AEC6EF95942140888406588E1A6602045CBE4A@PACDCEXCMB04.cable.comcast.com> <20080715145905.GA7134@foo.nw.neclab.eu> Cc: p2pi@ietf.org, "Livingood, Jason" Subject: Re: [p2pi] Charter and problem statement 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: Sebastian Kiesel Date: Tuesday, July 15, 2008 10:59 pm Subject: Re: [p2pi] Charter and problem statement > If it might happen that candidate caches do not already have the rare > content, any recommendation should not only consider the link between > client and cache but also the link from the cache to the "upstream > source", from which the content is retrieved by the cache. > I agree with you at this point: ) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 08:34: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 74B933A6A9D; Tue, 15 Jul 2008 08:34: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 5C0E73A6A91 for ; Tue, 15 Jul 2008 08:34:36 -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 mwP4mbULwZLR for ; Tue, 15 Jul 2008 08:34:32 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 57D413A67EC for ; Tue, 15 Jul 2008 08:34:32 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6FFYuAb005737; Tue, 15 Jul 2008 11:34:56 -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 m6FFYu3N016563; Tue, 15 Jul 2008 11:34:56 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m6FFYtHk016558; Tue, 15 Jul 2008 11:34:55 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 15 Jul 2008 11:34:55 -0400 (EDT) From: Salman Abdul Baset To: Lars Eggert In-Reply-To: <7D4D83FE-294E-4FD3-94F6-91D99D0C9D43@nokia.com> Message-ID: References: <1694335158.5981216070091253.JavaMail.root@dkny.pando.com> <487C9722.20602@telecomitalia.it> <7D4D83FE-294E-4FD3-94F6-91D99D0C9D43@nokia.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.5 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Tue, 15 Jul 2008, Lars Eggert wrote: > On 2008-7-15, at 16:16, ext Salman Abdul Baset wrote: >> On Tue, 15 Jul 2008, Enrico Marocco wrote: >>> This discussion is certainly interesting, but it is not about ALTO any >>> more, is it? I mean, in this context we are trying to charter a working >>> group for developing some mechanism for optimizing peer selection. At >>> best, "network" information will be used for selecting between a peer >>> with FTTH access and a DSL ones, when no additional information is >>> available. > > Agree with Enrico. > >> Information about self-interference can guide peer selection. For example, >> with this information, a P2PSIP application running on one of several >> machines behind the cable/DSL modem can more accurately determine the >> presence or absence of self-interference. In the absence of >> self-interference and after network usage has left the P2PSIP application >> convinced that it has enough capacity, it can advertise itself as a relay >> in the overlay. > > Sure, we can dream up all kinds of information that would be useful to an app > or protocol: accurate and timely topology graph information, accurate and > timely congestion information, accurate and timely latency information, etc. > App wants to know this stuff? Talk to the oracle - done! I certainly did not mean the extrapolation mentioned above :). I was refering to Enrico's point whether determining self-interference can guide peer selection. The concept of self-interference needs to be properly defined, though. Oracles are not a panacea for every problem and certainly not a solution for determining timely and accurate congestion or latency information. In addition, where to place oracles or their equivalent is an open question. The self-interference example and any ALTO solution must address the questions you raised. I will attempt to address your questions for the self-interference example later. -s > This misses a bunch of key issues, though: > > * Is it even possible for the oracle to gather all this > information? It's difficult for an app, sure - but why > do we think it will be easier for an oracle? > > * How accurate would this information be, how timely would > it be and what is the cost to gather and keep it up-to date? > > * How much interdepence does this create between layers that > were so far more loosely coupled? Are we giving up evolvability? > > * How much "better" (for some definition of better) will this > information let the app become? Is it worth the architectural > complexity? > > To make this concrete, lets go back to the self-interference example: How > would an access router figure out that a bunch of flows are interfering? On > what timescales would this detection mechanism operate, and how sensitive > would it be? Will the router need to assume that all flows adhere to some > specific congestion control mechanism? How much will performance be improved? > > > Without at least a credible attempt to answer these sorts of questions, I > don't think we have a basis to begin thinking about standardization. > > (And I agree that the more baked proposals in the ALTO space do have answers > here.) > > Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 11:17: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 34FF43A6A37; Tue, 15 Jul 2008 11:17: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 4F8F43A6995 for ; Tue, 15 Jul 2008 11:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.027, 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 4SxWaVIAjaUL for ; Tue, 15 Jul 2008 11:17:38 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2E4863A68E8 for ; Tue, 15 Jul 2008 11:17:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 7D185E10B6C; Tue, 15 Jul 2008 14:17:53 -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 LlciLfoBe6Ws; Tue, 15 Jul 2008 14:17:40 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 3B347E10B35; Tue, 15 Jul 2008 14:17:40 -0400 (EDT) Date: Tue, 15 Jul 2008 14:17:40 -0400 (EDT) From: Laird Popkin To: Salman Abdul Baset Message-ID: <381314145.9731216145860209.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 address Lars' point below, I think that the "oracle" is probably not the best place to ask about link level congestion, as that's a real-time stat, so the the best place to answer that question is probably the ISP's router nearest the edge (or DSLAM, etc>) but it might be the right place to ask for the location of the device to ask. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Salman Abdul Baset" To: "Lars Eggert" Cc: p2pi@ietf.org Sent: Tuesday, July 15, 2008 11:34:55 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem On Tue, 15 Jul 2008, Lars Eggert wrote: > On 2008-7-15, at 16:16, ext Salman Abdul Baset wrote: >> On Tue, 15 Jul 2008, Enrico Marocco wrote: >>> This discussion is certainly interesting, but it is not about ALTO any >>> more, is it? I mean, in this context we are trying to charter a working >>> group for developing some mechanism for optimizing peer selection. At >>> best, "network" information will be used for selecting between a peer >>> with FTTH access and a DSL ones, when no additional information is >>> available. > > Agree with Enrico. > >> Information about self-interference can guide peer selection. For example, >> with this information, a P2PSIP application running on one of several >> machines behind the cable/DSL modem can more accurately determine the >> presence or absence of self-interference. In the absence of >> self-interference and after network usage has left the P2PSIP application >> convinced that it has enough capacity, it can advertise itself as a relay >> in the overlay. > > Sure, we can dream up all kinds of information that would be useful to an app > or protocol: accurate and timely topology graph information, accurate and > timely congestion information, accurate and timely latency information, etc. > App wants to know this stuff? Talk to the oracle - done! I certainly did not mean the extrapolation mentioned above :). I was refering to Enrico's point whether determining self-interference can guide peer selection. The concept of self-interference needs to be properly defined, though. Oracles are not a panacea for every problem and certainly not a solution for determining timely and accurate congestion or latency information. In addition, where to place oracles or their equivalent is an open question. The self-interference example and any ALTO solution must address the questions you raised. I will attempt to address your questions for the self-interference example later. -s > This misses a bunch of key issues, though: > > * Is it even possible for the oracle to gather all this > information? It's difficult for an app, sure - but why > do we think it will be easier for an oracle? > > * How accurate would this information be, how timely would > it be and what is the cost to gather and keep it up-to date? > > * How much interdepence does this create between layers that > were so far more loosely coupled? Are we giving up evolvability? > > * How much "better" (for some definition of better) will this > information let the app become? Is it worth the architectural > complexity? > > To make this concrete, lets go back to the self-interference example: How > would an access router figure out that a bunch of flows are interfering? On > what timescales would this detection mechanism operate, and how sensitive > would it be? Will the router need to assume that all flows adhere to some > specific congestion control mechanism? How much will performance be improved? > > > Without at least a credible attempt to answer these sorts of questions, I > don't think we have a basis to begin thinking about standardization. > > (And I agree that the more baked proposals in the ALTO space do have answers > here.) > > 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 Tue Jul 15 11:21: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 AD63E3A6A5F; Tue, 15 Jul 2008 11:21: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 5B3B53A6A5F for ; Tue, 15 Jul 2008 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.24 X-Spam-Level: X-Spam-Status: No, score=-10.24 tagged_above=-999 required=5 tests=[AWL=0.025, 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 9tDzaLLbP036 for ; Tue, 15 Jul 2008 11:21:53 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 9087F3A6995 for ; Tue, 15 Jul 2008 11:21:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id A5DDAE10B6C; Tue, 15 Jul 2008 14:22:21 -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 aRCfYJac6oN1; Tue, 15 Jul 2008 14:22:21 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 24F63E10B35; Tue, 15 Jul 2008 14:22:21 -0400 (EDT) Date: Tue, 15 Jul 2008 14:22:21 -0400 (EDT) From: Laird Popkin To: Salman Abdul Baset Message-ID: <26845340.9771216146141126.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Yep. :-) This could apply not only to people in a home sharing a broadband connection, but also to homes using a shared broadband (e.g. DOCSIS). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Salman Abdul Baset" To: "Lars Eggert" Cc: "ext Laird Popkin" , p2pi@ietf.org Sent: Tuesday, July 15, 2008 7:58:33 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem On Tue, 15 Jul 2008, Lars Eggert wrote: >> Yes, there are scenarios where it's not clear whether there is a relevant >> link capacity, etc., but I'm fine getting no guidance in those situations. >> Even an 80% accurate knowledge of what the user's network capacity is would >> be a big improvement over the current situation. > > Not without additional information. If I run five P2P apps on different > machines in my home and they all know my access link capacity through some > mechanism, they'll still self-interfere before they have ramped up to that > capacity. > It seems that this is a scenario where cable/DSL modem should pass information of self-interference to other machines behind the same modem. For example, if mom/dad is using the Internet connection for work and are not getting the expected speed, they will like to know which child/device is hogging the connection. -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 11:28: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 8AE5B3A6B41; Tue, 15 Jul 2008 11:28: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 674883A6B3A for ; Tue, 15 Jul 2008 11:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Cuqd3uDQjKCB for ; Tue, 15 Jul 2008 11:28:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 741A93A6AF6 for ; Tue, 15 Jul 2008 11:28:52 -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 m6FITKOZ018939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Jul 2008 13:29:20 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6FITFVM022712 for ; Tue, 15 Jul 2008 13:29:15 -0500 (CDT) Message-ID: <487CEC7F.7050806@alcatel-lucent.com> Date: Tue, 15 Jul 2008 13:29:19 -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] Draft agenda posted 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: We have posted a (draft) agenda for ALTO. It can be accessed at http://www.ietf.org/proceedings/08jul/agenda/alto.html. Please let me and Enrico know of any comments and/or changes. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 15 12:23: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 B7B693A6823; Tue, 15 Jul 2008 12:23: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 C1D483A6823 for ; Tue, 15 Jul 2008 12:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 o-OfnS04hpFj for ; Tue, 15 Jul 2008 12:23:16 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 7DDB63A67F5 for ; Tue, 15 Jul 2008 12:23:16 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so5137734wfd.31 for ; Tue, 15 Jul 2008 12:23:44 -0700 (PDT) Received: by 10.142.72.4 with SMTP id u4mr4800481wfa.269.1216149824253; Tue, 15 Jul 2008 12:23:44 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm6291297wfd.1.2008.07.15.12.23.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 12:23:43 -0700 (PDT) Message-Id: <7FF88A9D-1C47-41F7-A451-CBF6736A94C0@shlang.com> From: Stanislav Shalunov To: Laird Popkin In-Reply-To: <381314145.9731216145860209.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 12:23:40 -0700 References: <381314145.9731216145860209.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 The router's in the path. It would seem the most obvious way to ask it is to just send a packet, and the router would fiddle with something in the header. Explicit congestion control is hard to deploy and is a pie-in-the-sky of transport-level solutions. Often, it can be approximated end-to- end more easily. End-to-end is just so much easier. It is also desirable to move forward in the explicit direction. Problem is at this point we don't know what the right thing to communicate is -- it remains a research rather than an engineering question. It's also not something that is easy to experiment with -- imagine the total cost of the RED and ECN experiments. And they're some of the most lightweight forms of explicit congestion control. -- Stas On Jul 15, 2008, at 11:17 AM, Laird Popkin wrote: > To address Lars' point below, I think that the "oracle" is probably > not the best place to ask about link level congestion, as that's a > real-time stat, so the the best place to answer that question is > probably the ISP's router nearest the edge (or DSLAM, etc>) but it > might be the right place to ask for the location of the device to > ask. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Salman Abdul Baset" > To: "Lars Eggert" > Cc: p2pi@ietf.org > Sent: Tuesday, July 15, 2008 11:34:55 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > On Tue, 15 Jul 2008, Lars Eggert wrote: > >> On 2008-7-15, at 16:16, ext Salman Abdul Baset wrote: >>> On Tue, 15 Jul 2008, Enrico Marocco wrote: >>>> This discussion is certainly interesting, but it is not about >>>> ALTO any >>>> more, is it? I mean, in this context we are trying to charter a >>>> working >>>> group for developing some mechanism for optimizing peer >>>> selection. At >>>> best, "network" information will be used for selecting between a >>>> peer >>>> with FTTH access and a DSL ones, when no additional information is >>>> available. >> >> Agree with Enrico. >> >>> Information about self-interference can guide peer selection. For >>> example, >>> with this information, a P2PSIP application running on one of >>> several >>> machines behind the cable/DSL modem can more accurately determine >>> the >>> presence or absence of self-interference. In the absence of >>> self-interference and after network usage has left the P2PSIP >>> application >>> convinced that it has enough capacity, it can advertise itself as >>> a relay >>> in the overlay. >> >> Sure, we can dream up all kinds of information that would be useful >> to an app >> or protocol: accurate and timely topology graph information, >> accurate and >> timely congestion information, accurate and timely latency >> information, etc. >> App wants to know this stuff? Talk to the oracle - done! > > I certainly did not mean the extrapolation mentioned above :). I was > refering to Enrico's point whether determining self-interference can > guide > peer selection. The concept of self-interference needs to be properly > defined, though. Oracles are not a panacea for every problem and > certainly > not a solution for determining timely and accurate congestion or > latency > information. In addition, where to place oracles or their equivalent > is an > open question. > > The self-interference example and any ALTO solution must address the > questions you raised. I will attempt to address your questions for the > self-interference example later. > > -s > >> This misses a bunch of key issues, though: >> >> * Is it even possible for the oracle to gather all this >> information? It's difficult for an app, sure - but why >> do we think it will be easier for an oracle? >> >> * How accurate would this information be, how timely would >> it be and what is the cost to gather and keep it up-to date? >> >> * How much interdepence does this create between layers that >> were so far more loosely coupled? Are we giving up evolvability? >> >> * How much "better" (for some definition of better) will this >> information let the app become? Is it worth the architectural >> complexity? >> >> To make this concrete, lets go back to the self-interference >> example: How >> would an access router figure out that a bunch of flows are >> interfering? On >> what timescales would this detection mechanism operate, and how >> sensitive >> would it be? Will the router need to assume that all flows adhere >> to some >> specific congestion control mechanism? How much will performance be >> improved? >> >> >> Without at least a credible attempt to answer these sorts of >> questions, I >> don't think we have a basis to begin thinking about standardization. >> >> (And I agree that the more baked proposals in the ALTO space do >> have answers >> here.) >> >> 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 -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 12:25: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 2D5243A6823; Tue, 15 Jul 2008 12:25: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 02CE83A67F5 for ; Tue, 15 Jul 2008 12:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.242 X-Spam-Level: X-Spam-Status: No, score=-10.242 tagged_above=-999 required=5 tests=[AWL=0.023, 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 nDQVTU4Redhz for ; Tue, 15 Jul 2008 12:25:40 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 6F68E3A6877 for ; Tue, 15 Jul 2008 12:25:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 29EDFE10B79; Tue, 15 Jul 2008 15:26: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 K5DmMoZGkKWL; Tue, 15 Jul 2008 15:25:49 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id B45BCE10C31; Tue, 15 Jul 2008 15:25:49 -0400 (EDT) Date: Tue, 15 Jul 2008 15:25:49 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <508737035.11231216149949702.JavaMail.root@dkny.pando.com> In-Reply-To: <7FF88A9D-1C47-41F7-A451-CBF6736A94C0@shlang.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 That seems like a reasonable approach. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: "Laird Popkin" Cc: p2pi@ietf.org Sent: Tuesday, July 15, 2008 3:23:40 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem The router's in the path. It would seem the most obvious way to ask it is to just send a packet, and the router would fiddle with something in the header. Explicit congestion control is hard to deploy and is a pie-in-the-sky of transport-level solutions. Often, it can be approximated end-to- end more easily. End-to-end is just so much easier. It is also desirable to move forward in the explicit direction. Problem is at this point we don't know what the right thing to communicate is -- it remains a research rather than an engineering question. It's also not something that is easy to experiment with -- imagine the total cost of the RED and ECN experiments. And they're some of the most lightweight forms of explicit congestion control. -- Stas On Jul 15, 2008, at 11:17 AM, Laird Popkin wrote: > To address Lars' point below, I think that the "oracle" is probably > not the best place to ask about link level congestion, as that's a > real-time stat, so the the best place to answer that question is > probably the ISP's router nearest the edge (or DSLAM, etc>) but it > might be the right place to ask for the location of the device to > ask. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Salman Abdul Baset" > To: "Lars Eggert" > Cc: p2pi@ietf.org > Sent: Tuesday, July 15, 2008 11:34:55 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO BoF - generalize the problem > > On Tue, 15 Jul 2008, Lars Eggert wrote: > >> On 2008-7-15, at 16:16, ext Salman Abdul Baset wrote: >>> On Tue, 15 Jul 2008, Enrico Marocco wrote: >>>> This discussion is certainly interesting, but it is not about >>>> ALTO any >>>> more, is it? I mean, in this context we are trying to charter a >>>> working >>>> group for developing some mechanism for optimizing peer >>>> selection. At >>>> best, "network" information will be used for selecting between a >>>> peer >>>> with FTTH access and a DSL ones, when no additional information is >>>> available. >> >> Agree with Enrico. >> >>> Information about self-interference can guide peer selection. For >>> example, >>> with this information, a P2PSIP application running on one of >>> several >>> machines behind the cable/DSL modem can more accurately determine >>> the >>> presence or absence of self-interference. In the absence of >>> self-interference and after network usage has left the P2PSIP >>> application >>> convinced that it has enough capacity, it can advertise itself as >>> a relay >>> in the overlay. >> >> Sure, we can dream up all kinds of information that would be useful >> to an app >> or protocol: accurate and timely topology graph information, >> accurate and >> timely congestion information, accurate and timely latency >> information, etc. >> App wants to know this stuff? Talk to the oracle - done! > > I certainly did not mean the extrapolation mentioned above :). I was > refering to Enrico's point whether determining self-interference can > guide > peer selection. The concept of self-interference needs to be properly > defined, though. Oracles are not a panacea for every problem and > certainly > not a solution for determining timely and accurate congestion or > latency > information. In addition, where to place oracles or their equivalent > is an > open question. > > The self-interference example and any ALTO solution must address the > questions you raised. I will attempt to address your questions for the > self-interference example later. > > -s > >> This misses a bunch of key issues, though: >> >> * Is it even possible for the oracle to gather all this >> information? It's difficult for an app, sure - but why >> do we think it will be easier for an oracle? >> >> * How accurate would this information be, how timely would >> it be and what is the cost to gather and keep it up-to date? >> >> * How much interdepence does this create between layers that >> were so far more loosely coupled? Are we giving up evolvability? >> >> * How much "better" (for some definition of better) will this >> information let the app become? Is it worth the architectural >> complexity? >> >> To make this concrete, lets go back to the self-interference >> example: How >> would an access router figure out that a bunch of flows are >> interfering? On >> what timescales would this detection mechanism operate, and how >> sensitive >> would it be? Will the router need to assume that all flows adhere >> to some >> specific congestion control mechanism? How much will performance be >> improved? >> >> >> Without at least a credible attempt to answer these sorts of >> questions, I >> don't think we have a basis to begin thinking about standardization. >> >> (And I agree that the more baked proposals in the ALTO space do >> have answers >> here.) >> >> 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 -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 12:48: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 E44033A6A5F; Tue, 15 Jul 2008 12:48: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 392A63A687F for ; Tue, 15 Jul 2008 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 jJTLODqR4GXV for ; Tue, 15 Jul 2008 12:48:05 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 859523A6A5F for ; Tue, 15 Jul 2008 12:48:03 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-AKO-Attachments:X-IronPort-AV:Received: Received:To:Message-ID:Date:X-Mailer:MIME-Version: Content-Language:Subject:X-Accept-Language:Priority: Content-Type; b=MvZ1lAYs+IULuQLAbK45JXmByrnBu2yxkMig2gkW9NELQ6atl2gvuMCM KcvVm6eCuNkUk7wRU+69Ut2f9IDbfg==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 173796101:10.224.36.65:15 Jul 2008 19:48:28 +0000:$Webmail:None X-AKO-Attachments: ALTO draft charter-rrr.txt X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="txt'?scan'208";a="173796101" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 15 Jul 2008 19:48:06 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Tue, 15 Jul 2008 15:48:06 -0400 To: p2pi@ietf.org Message-ID: Date: Tue, 15 Jul 2008 15:48:06 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal Content-Type: multipart/mixed; boundary="--f371f615c277d0e73b5" Subject: [p2pi] ALTO BoF - 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: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. ----f371f615c277d0e73b5 Content-Type: text/plain; charset=windows-1252 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi=2C all=3A Many of us do not understand the words =22Oracle=22 and =22Tracker=22 ri= ght form the charter=2E So=2C the above two words have been clarified in the modified one as fol= lows (also enclosed in a file with change marks)=2E BR/Radhika DRAFT CHARTER A significant part of the Internet traffic is today generated by peer-to-peer (P2P) applications used for file sharing=2C real-time communications and live media streaming=2E Contrary to client/server architectures=2C P2P applications access resources distributed across the Internet (e=2Eg=2E files or media relays) and exchange large amounts= of data in connections that they establish directly with nodes hosting such resources=2E One of the advantages of P2P systems comes from the fact that the resources they offer are often made available through multiple instances=2E Yet=2C applications generally ignore the topology of the latent overlay network and have to select among available instances based on information they deduce from empirical measurements which often lead to suboptimal choices=2E Optimizing such selection brings about=2C on the one hand=2C an increase in P2P applications performance and=2C on the other hand a better use of network resources=2E The Working Group will produce protocols to enable communications between P2P systems and =22informed=22 external services in order to optimize peer selection=2E The =93informed=94 external service is assume= d to be provided by the peer selection server=2E The WG will consider tr= acker-based P2P systems (a la Bit Torrent) that communicate among its Internet Service P= rovider (ISP)-based P2P systems as well as tracker-less (i=2Ee=2E Non-IS= P) P2P networks=2E Both type of P2P formations -- structured as well as unstructured -- will be considered=2E Furthermore=2C recognizing that the discovery of nearby peers has equal applicability to many real-time communications protocols (for example=2C= the discovery of the nearest relay that will enable the establishment of a VoIP session)=2C the WG will attempt to produce deliverables consisting of generic mechanisms that are broadly applicable to many current and future applications=2E The WG will focus on the following items=2E - Surveys and taxonomies=2E (a) A survey of existing solutions for peer selection optimization=2E Internet coordinate systems=2C path selection services and various forms of collaboration between Internet Service Providers (ISP) and P2P networks have been recently proposed=2C simulated and deployed with encouraging results=2E (b) A survey of existing solutions for service discovery (both in P2P and traditional client-server systems=2E) (c) Taxonomy of other classes of applications -- besides P2P -- that can benefit from topological proximity information=2E - A requirements document=2E This document will list requirements for a peer selection service=2C identifying=2C for example=2C what kind of information P2P applications will need for optimizing their choices=2E - A discovery mechanism for locating the peer selection server oracle=2E= Certain applications may use a tracker and the intelligence embedded in it to find nearby peers=2C others may simply want the oracle to sort a list of IP addresses=2E Regardless=2C applications will use the discovery mechanism for locating the proper server to query=2C which may vary depending on factors such as=2C for example=2C their network location=2E= - A signaling protocol for querying the peer selection server oracle=2E = Once located=2C applications will use this protocol for querying information useful for peer selection=2E A sample deliverable will be a document that defines the PDU layout of the query/response packets=2E Informational documents that outline an API of some sort could also be produced=2E This WG will focus solely on the interface exposed to P2P systems by peer selection services=3B if=2C in the future=2C the IETF will consider= the opportunity to work on protocols for actually implementing such systems (e=2Eg=2E application-layer protocols for Internet coordinate systems=2C routing protocol extensions for ISP-based solutions)=2C such work will be done in strict coordination with the appropriate WGs=2E Issues related to the content exchanged in P2P systems are excluded from the Working Group=27s scope=2C as is the issue dealing with enforci= ng the legality of the content ----f371f615c277d0e73b5 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ALTO draft charter-rrr.txt" DQpEUkFGVCBDSEFSVEVSDQoNCkEgc2lnbmlmaWNhbnQgcGFydCBvZiB0aGUgSW50ZXJuZXQg dHJhZmZpYyBpcyB0b2RheSBnZW5lcmF0ZWQgYnkNCnBlZXItdG8tcGVlciAoUDJQKSBhcHBs aWNhdGlvbnMgdXNlZCBmb3IgZmlsZSBzaGFyaW5nLCByZWFsLXRpbWUNCmNvbW11bmljYXRp b25zIGFuZCBsaXZlIG1lZGlhIHN0cmVhbWluZy4gIENvbnRyYXJ5IHRvIGNsaWVudC9zZXJ2 ZXINCmFyY2hpdGVjdHVyZXMsIFAyUCBhcHBsaWNhdGlvbnMgYWNjZXNzIHJlc291cmNlcyBk aXN0cmlidXRlZCBhY3Jvc3MNCnRoZSBJbnRlcm5ldCAoZS5nLiBmaWxlcyBvciBtZWRpYSBy ZWxheXMpIGFuZCBleGNoYW5nZSBsYXJnZSBhbW91bnRzDQpvZiBkYXRhIGluIGNvbm5lY3Rp b25zIHRoYXQgdGhleSBlc3RhYmxpc2ggZGlyZWN0bHkgd2l0aCBub2RlcyBob3N0aW5nDQpz dWNoIHJlc291cmNlcy4NCg0KT25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIFAyUCBzeXN0ZW1z IGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUNCnJlc291cmNlcyB0aGV5IG9mZmVyIGFy ZSBvZnRlbiBtYWRlIGF2YWlsYWJsZSB0aHJvdWdoIG11bHRpcGxlDQppbnN0YW5jZXMuICBZ ZXQsIGFwcGxpY2F0aW9ucyBnZW5lcmFsbHkgaWdub3JlIHRoZSB0b3BvbG9neSBvZiB0aGUN CmxhdGVudCBvdmVybGF5IG5ldHdvcmsgYW5kIGhhdmUgdG8gc2VsZWN0IGFtb25nIGF2YWls YWJsZSBpbnN0YW5jZXMNCmJhc2VkIG9uIGluZm9ybWF0aW9uIHRoZXkgZGVkdWNlIGZyb20g ZW1waXJpY2FsIG1lYXN1cmVtZW50cyB3aGljaA0Kb2Z0ZW4gbGVhZCB0byBzdWJvcHRpbWFs IGNob2ljZXMuICBPcHRpbWl6aW5nIHN1Y2ggc2VsZWN0aW9uIGJyaW5ncw0KYWJvdXQsIG9u IHRoZSBvbmUgaGFuZCwgYW4gaW5jcmVhc2UgaW4gUDJQIGFwcGxpY2F0aW9ucyBwZXJmb3Jt YW5jZQ0KYW5kLCBvbiB0aGUgb3RoZXIgaGFuZCBhIGJldHRlciB1c2Ugb2YgbmV0d29yayBy ZXNvdXJjZXMuDQoNClRoZSBXb3JraW5nIEdyb3VwIHdpbGwgcHJvZHVjZSBwcm90b2NvbHMg dG8gZW5hYmxlIGNvbW11bmljYXRpb25zDQpiZXR3ZWVuIFAyUCBzeXN0ZW1zIGFuZCAiaW5m b3JtZWQiIGV4dGVybmFsIHNlcnZpY2VzIGluIG9yZGVyIHRvDQpvcHRpbWl6ZSBwZWVyIHNl bGVjdGlvbi4gIFRoZSCTaW5mb3JtZWSUIGV4dGVybmFsIHNlcnZpY2UgaXMgYXNzdW1lZCB0 byBiZSBwcm92aWRlZCBieSB0aGUgcGVlciBzZWxlY3Rpb24gc2VydmVyLiBUaGUgV0cgd2ls bCBjb25zaWRlciB0cmFja2VyLWJhc2VkIFAyUA0Kc3lzdGVtcyAoYSBsYSBCaXQgVG9ycmVu dCkgdGhhdCBjb21tdW5pY2F0ZSBhbW9uZyBpdHMgSW50ZXJuZXQgU2VydmljZSBQcm92aWRl ciAoSVNQKS1iYXNlZCBQMlAgc3lzdGVtcyBhcyB3ZWxsIGFzIHRyYWNrZXItbGVzcyAoaS5l LiBOb24tSVNQKSBQMlAgbmV0d29ya3MuICBCb3RoDQp0eXBlIG9mIFAyUCBmb3JtYXRpb25z IC0tIHN0cnVjdHVyZWQgYXMgd2VsbCBhcyB1bnN0cnVjdHVyZWQgLS0gd2lsbA0KYmUgY29u c2lkZXJlZC4NCg0KRnVydGhlcm1vcmUsIHJlY29nbml6aW5nIHRoYXQgdGhlIGRpc2NvdmVy eSBvZiBuZWFyYnkgcGVlcnMgaGFzIGVxdWFsDQphcHBsaWNhYmlsaXR5IHRvIG1hbnkgcmVh bC10aW1lIGNvbW11bmljYXRpb25zIHByb3RvY29scyAoZm9yIGV4YW1wbGUsDQp0aGUgZGlz Y292ZXJ5IG9mIHRoZSBuZWFyZXN0IHJlbGF5IHRoYXQgd2lsbCBlbmFibGUgdGhlIGVzdGFi bGlzaG1lbnQNCm9mIGEgVm9JUCBzZXNzaW9uKSwgdGhlIFdHIHdpbGwgYXR0ZW1wdCB0byBw cm9kdWNlIGRlbGl2ZXJhYmxlcw0KY29uc2lzdGluZyBvZiBnZW5lcmljIG1lY2hhbmlzbXMg dGhhdCBhcmUgYnJvYWRseSBhcHBsaWNhYmxlIHRvIG1hbnkNCmN1cnJlbnQgYW5kIGZ1dHVy ZSBhcHBsaWNhdGlvbnMuDQoNClRoZSBXRyB3aWxsIGZvY3VzIG9uIHRoZSBmb2xsb3dpbmcg aXRlbXMuDQoNCi0gU3VydmV5cyBhbmQgdGF4b25vbWllcy4gIChhKSBBIHN1cnZleSBvZiBl eGlzdGluZyBzb2x1dGlvbnMgZm9yIHBlZXINCiAgc2VsZWN0aW9uIG9wdGltaXphdGlvbi4g IEludGVybmV0IGNvb3JkaW5hdGUgc3lzdGVtcywgcGF0aCBzZWxlY3Rpb24NCiAgc2Vydmlj ZXMgYW5kIHZhcmlvdXMgZm9ybXMgb2YgY29sbGFib3JhdGlvbiBiZXR3ZWVuIEludGVybmV0 IFNlcnZpY2UNCiAgUHJvdmlkZXJzIChJU1ApIGFuZCBQMlAgbmV0d29ya3MgaGF2ZSBiZWVu IHJlY2VudGx5IHByb3Bvc2VkLA0KICBzaW11bGF0ZWQgYW5kIGRlcGxveWVkIHdpdGggZW5j b3VyYWdpbmcgcmVzdWx0cy4gIChiKSBBIHN1cnZleSBvZg0KICBleGlzdGluZyBzb2x1dGlv bnMgZm9yIHNlcnZpY2UgZGlzY292ZXJ5IChib3RoIGluIFAyUCBhbmQNCiAgdHJhZGl0aW9u YWwgY2xpZW50LXNlcnZlciBzeXN0ZW1zLikgIChjKSBUYXhvbm9teSBvZiBvdGhlciBjbGFz c2VzDQogIG9mIGFwcGxpY2F0aW9ucyAtLSBiZXNpZGVzIFAyUCAtLSB0aGF0IGNhbiBiZW5l Zml0IGZyb20gdG9wb2xvZ2ljYWwNCiAgcHJveGltaXR5IGluZm9ybWF0aW9uLg0KDQotIEEg cmVxdWlyZW1lbnRzIGRvY3VtZW50LiAgVGhpcyBkb2N1bWVudCB3aWxsIGxpc3QgcmVxdWly ZW1lbnRzIGZvciBhDQogIHBlZXIgc2VsZWN0aW9uIHNlcnZpY2UsIGlkZW50aWZ5aW5nLCBm b3IgZXhhbXBsZSwgd2hhdCBraW5kIG9mDQogIGluZm9ybWF0aW9uIFAyUCBhcHBsaWNhdGlv bnMgd2lsbCBuZWVkIGZvciBvcHRpbWl6aW5nIHRoZWlyIGNob2ljZXMuDQoNCi0gQSBkaXNj b3ZlcnkgbWVjaGFuaXNtIGZvciBsb2NhdGluZyB0aGUgcGVlciBzZWxlY3Rpb24gc2VydmVy IG9yYWNsZS4gIENlcnRhaW4gYXBwbGljYXRpb25zDQogIG1heSB1c2UgYSB0cmFja2VyIGFu ZCB0aGUgaW50ZWxsaWdlbmNlIGVtYmVkZGVkIGluIGl0IHRvIGZpbmQgbmVhcmJ5DQogIHBl ZXJzLCBvdGhlcnMgbWF5IHNpbXBseSB3YW50IHRoZSBvcmFjbGUgdG8gc29ydCBhIGxpc3Qg b2YgSVANCiAgYWRkcmVzc2VzLiAgUmVnYXJkbGVzcywgYXBwbGljYXRpb25zIHdpbGwgdXNl IHRoZSBkaXNjb3ZlcnkNCiAgbWVjaGFuaXNtIGZvciBsb2NhdGluZyB0aGUgcHJvcGVyIHNl cnZlciB0byBxdWVyeSwgd2hpY2ggbWF5IHZhcnkNCiAgZGVwZW5kaW5nIG9uIGZhY3RvcnMg c3VjaCBhcywgZm9yIGV4YW1wbGUsIHRoZWlyIG5ldHdvcmsgbG9jYXRpb24uDQoNCi0gQSBz aWduYWxpbmcgcHJvdG9jb2wgZm9yIHF1ZXJ5aW5nIHRoZSBwZWVyIHNlbGVjdGlvbiBzZXJ2 ZXIgb3JhY2xlLiAgT25jZSBsb2NhdGVkLA0KICBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgdGhp cyBwcm90b2NvbCBmb3IgcXVlcnlpbmcgaW5mb3JtYXRpb24gdXNlZnVsDQogIGZvciBwZWVy IHNlbGVjdGlvbi4gIEEgc2FtcGxlIGRlbGl2ZXJhYmxlIHdpbGwgYmUgYSBkb2N1bWVudCB0 aGF0DQogIGRlZmluZXMgdGhlIFBEVSBsYXlvdXQgb2YgdGhlIHF1ZXJ5L3Jlc3BvbnNlIHBh Y2tldHMuICBJbmZvcm1hdGlvbmFsDQogIGRvY3VtZW50cyB0aGF0IG91dGxpbmUgYW4gQVBJ IG9mIHNvbWUgc29ydCBjb3VsZCBhbHNvIGJlIHByb2R1Y2VkLg0KDQpUaGlzIFdHIHdpbGwg Zm9jdXMgc29sZWx5IG9uIHRoZSBpbnRlcmZhY2UgZXhwb3NlZCB0byBQMlAgc3lzdGVtcyBi eQ0KcGVlciBzZWxlY3Rpb24gc2VydmljZXM7IGlmLCBpbiB0aGUgZnV0dXJlLCB0aGUgSUVU RiB3aWxsIGNvbnNpZGVyIHRoZQ0Kb3Bwb3J0dW5pdHkgdG8gd29yayBvbiBwcm90b2NvbHMg Zm9yIGFjdHVhbGx5IGltcGxlbWVudGluZyBzdWNoDQpzeXN0ZW1zIChlLmcuIGFwcGxpY2F0 aW9uLWxheWVyIHByb3RvY29scyBmb3IgSW50ZXJuZXQgY29vcmRpbmF0ZQ0Kc3lzdGVtcywg cm91dGluZyBwcm90b2NvbCBleHRlbnNpb25zIGZvciBJU1AtYmFzZWQgc29sdXRpb25zKSwg c3VjaA0Kd29yayB3aWxsIGJlIGRvbmUgaW4gc3RyaWN0IGNvb3JkaW5hdGlvbiB3aXRoIHRo ZSBhcHByb3ByaWF0ZSBXR3MuDQoNCklzc3VlcyByZWxhdGVkIHRvIHRoZSBjb250ZW50IGV4 Y2hhbmdlZCBpbiBQMlAgc3lzdGVtcyBhcmUgZXhjbHVkZWQNCmZyb20gdGhlIFdvcmtpbmcg R3JvdXAncyBzY29wZSwgYXMgaXMgdGhlIGlzc3VlIGRlYWxpbmcgd2l0aCBlbmZvcmNpbmcN CnRoZSBsZWdhbGl0eSBvZiB0aGUgY29udGVudC4NCg== ----f371f615c277d0e73b5 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 ----f371f615c277d0e73b5-- From p2pi-bounces@ietf.org Tue Jul 15 13:25: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 7BAF53A6B76; Tue, 15 Jul 2008 13:25: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 57D7F3A6B76 for ; Tue, 15 Jul 2008 13:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Y2okMWZJqYko for ; Tue, 15 Jul 2008 13:25:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 458063A6B55 for ; Tue, 15 Jul 2008 13:25: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 m6FKQEE3027491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 15:26:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6FKQ92c001328; Tue, 15 Jul 2008 15:26:10 -0500 (CDT) Message-ID: <487D07E5.4070104@alcatel-lucent.com> Date: Tue, 15 Jul 2008 15:26:13 -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: "Roy, Radhika R Dr CTR USA USAMC" References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - 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 Roy, Radhika R Dr CTR USA USAMC wrote: > Hi, all: > > Many of us do not understand the words "Oracle" and "Tracker" right > form the charter. > > So, the above two words have been clarified in the modified one as > follows (also enclosed in a file with change marks). Radhika: Thank you immensely for a close read. Your point is well taken, however the best place to define any such values will probably be a terminology I-D of some sort. The good folks who have put out the requirements document (please see http://tools.ietf.org/html/draft-kiesel-alto-reqs-00) have started a terminology section in S3 of the above draft. It is expected that this section may expand and consume its own draft at some time in the future. Having said that, I do want to point out that we are using the term "oracle" in the canonical meaning of the word as defined by Merriam-Webster's dictionary; namely a person giving wise or authoritative decisions or opinions Think of the Oracle of Delphi. There is no more magic about it beyond that. Regarding the term tracker, a stab at a definition is already there in the above draft (end of page 6.) The authors would probably be advised to expand on it in subsequent releases of the draft. And finally, one clarification in your suggested modification: OLD: The WG will consider tracker-based P2P systems (a la Bit Torrent) as well as tracker-less P2P networks. NEW: The WG will consider tracker-based P2P systems (a la Bit Torrent) that communicate among its Internet Service Provider (ISP)-based P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. Tracker-less does not necessarily imply non-ISP any more than tracker-based implies explicit ISP support. IMHO, I believe that the text as written in the draft charter is sufficient and the conflation of the role of an ISP with the need for trackers may serve to confuse the issue further. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 15 16:35: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 6F9343A6A36; Tue, 15 Jul 2008 16:35: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 C26573A69A3 for ; Tue, 15 Jul 2008 16:35: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=[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 XViyVrH9JAkr for ; Tue, 15 Jul 2008 16:35:49 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by core3.amsl.com (Postfix) with ESMTP id 04CC43A67CF for ; Tue, 15 Jul 2008 16:35:48 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3017549pyg.24 for ; Tue, 15 Jul 2008 16:36:15 -0700 (PDT) Received: by 10.141.29.14 with SMTP id g14mr7814642rvj.241.1216164974839; Tue, 15 Jul 2008 16:36:14 -0700 (PDT) Received: from Inbox ( [75.210.211.212]) by mx.google.com with ESMTPS id g31sm12267632rvb.2.2008.07.15.16.36.09 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:36:14 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Tue, 15 Jul 2008 16:36:11 -0700 Importance: normal X-Priority: 3 To: Laird Popkin , Salman Abdul Baset Message-ID: <487d346d.1f538c0a.469a.4a2d@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Transport issues belong in the transport area with TANA. Congestion control and everything that deals with depending on network utilization is a transport issue. Static information, costs, caches, and such do not belong in TANA and go to ALTO. -- Stas -----Original Message----- From: "Laird Popkin" To: "Salman Abdul Baset" Cc: p2pi@ietf.org Sent: 7/15/08 6:41 AM Subject: Re: [p2pi] ALTO BoF - generalize the problem In terms of whether this issue is more appropriate in TANA or ALTO, I gather that we'll need to work that out at the BOFs. But I hope that it fits within one of them. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 16:35: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 953003A6AC8; Tue, 15 Jul 2008 16:35: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 3471D3A6AC8 for ; Tue, 15 Jul 2008 16:35:52 -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 NYHcT483Ehmy for ; Tue, 15 Jul 2008 16:35:51 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by core3.amsl.com (Postfix) with ESMTP id 5668A3A67CF for ; Tue, 15 Jul 2008 16:35:51 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3017549pyg.24 for ; Tue, 15 Jul 2008 16:36:20 -0700 (PDT) Received: by 10.140.169.4 with SMTP id r4mr7834026rve.131.1216164978718; Tue, 15 Jul 2008 16:36:18 -0700 (PDT) Received: from Inbox ( [75.210.211.212]) by mx.google.com with ESMTPS id g31sm12267632rvb.2.2008.07.15.16.36.15 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:36:18 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Tue, 15 Jul 2008 16:36:17 -0700 Importance: normal X-Priority: 3 To: Enrico Marocco , Salman Abdul Baset Message-ID: <487d3472.1f538c0a.469a.4a30@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Precisely. Thank you. -----Original Message----- From: "Enrico Marocco" To: "Salman Abdul Baset" Cc: "p2pi@ietf.org" Sent: 7/15/08 5:25 AM Subject: Re: [p2pi] ALTO BoF - generalize the problem Salman Abdul Baset wrote: >>> Yes, there are scenarios where it's not clear whether there is a relevant >>> link capacity, etc., but I'm fine getting no guidance in those situations. >>> Even an 80% accurate knowledge of what the user's network capacity is would >>> be a big improvement over the current situation. >> Not without additional information. If I run five P2P apps on different >> machines in my home and they all know my access link capacity through some >> mechanism, they'll still self-interfere before they have ramped up to that >> capacity. > > It seems that this is a scenario where cable/DSL modem should pass > information of self-interference to other machines behind the same modem. > For example, if mom/dad is using the Internet connection for work and are > not getting the expected speed, they will like to know which child/device is > hogging the connection. This discussion is certainly interesting, but it is not about ALTO any more, is it? I mean, in this context we are trying to charter a working group for developing some mechanism for optimizing peer selection. At best, "network" information will be used for selecting between a peer with FTTH access and a DSL ones, when no additional information is available. The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly covers transport issues like congestion notification and sharing of network resources; its problem statement is available at: http://tools.ietf.org/id/draft-shalunov-tana-problem-statement -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 16:36: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 C01013A696A; Tue, 15 Jul 2008 16:36: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 853843A685C for ; Tue, 15 Jul 2008 16:36:04 -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 nSMwzrHumnsI for ; Tue, 15 Jul 2008 16:36:03 -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 8F6253A696A for ; Tue, 15 Jul 2008 16:36:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4774474rvf.49 for ; Tue, 15 Jul 2008 16:36:31 -0700 (PDT) Received: by 10.140.192.9 with SMTP id p9mr7819704rvf.114.1216164991520; Tue, 15 Jul 2008 16:36:31 -0700 (PDT) Received: from Inbox ( [75.210.211.212]) by mx.google.com with ESMTPS id g31sm12267632rvb.2.2008.07.15.16.36.28 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:36:30 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Tue, 15 Jul 2008 16:36:30 -0700 Importance: normal X-Priority: 3 To: Enrico Marocco , Sebastian Kiesel Message-ID: <487d347e.1f538c0a.469a.4a49@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 would require whatever is giving caches out to query them beforehand, a task easily accomplished by the client. More importantly, this would defeat the point of a cache, no? First, it's empty. So, nobody gets it. So it remains empty. OTOH, unconditionally obtaining the closest cache has no obvious problems. -----Original Message----- From: "Enrico Marocco" To: "Sebastian Kiesel" Cc: "p2pi@ietf.org" Sent: 7/15/08 6:32 AM Subject: Re: [p2pi] Charter and problem statement Sebastian Kiesel wrote: > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >> For this level of discussion, I agree that caches should simply be >> viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., content where > the likelyhood is high, that there is a cache miss when we ask for it > and that the cache will never deliver a second copy of it? It might not > be wise to select a cache which is in the "opposite direction" of the > original content, even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch the > content the request may pass by the client and go through the same "bad" > link plus twice through the "good" one. As long as caches are viewed as regular peers, they will be included in ALTO requests/responses only if they actually have the resource the querying peer wants to access. -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 16:36: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 2F34B3A6B69; Tue, 15 Jul 2008 16:36: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 B8BBC3A6B69 for ; Tue, 15 Jul 2008 16:36:08 -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 iMXR7gAmIg+j for ; Tue, 15 Jul 2008 16:36:08 -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 AF10C3A6B6A for ; Tue, 15 Jul 2008 16:36:07 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4774474rvf.49 for ; Tue, 15 Jul 2008 16:36:36 -0700 (PDT) Received: by 10.141.48.10 with SMTP id a10mr7847647rvk.4.1216164996117; Tue, 15 Jul 2008 16:36:36 -0700 (PDT) Received: from Inbox ( [75.210.211.212]) by mx.google.com with ESMTPS id g31sm12267632rvb.2.2008.07.15.16.36.32 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:36:35 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Tue, 15 Jul 2008 16:36:34 -0700 Importance: normal X-Priority: 3 To: stefano previdi , Laird Popkin , Enrico Marocco Message-ID: <487d3483.1f538c0a.469a.4a4d@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 information conveyed to the client needs to enable the client to find a nearby cache (or three). Whether this information blob can be called opaque then is a semantic question, but to me, calling it opaque is misleading. Anything opaque is transparent to something higher up the stack. For example, should we use DNS to find the cache, the information is opaque on DNS layer. It is no longer opaque when it is used. If it is to allow any client to find the cache, it's not opaque to ALTO. -----Original Message----- From: "stefano previdi" To: "Laird Popkin" ; "Enrico Marocco" Cc: p2pi@ietf.org Sent: 7/15/08 6:41 AM Subject: Re: [p2pi] Charter and problem statement Laird, do you suggest to make the cache entity explicit in the ALTO protocol semantic ? Or is it just part of the opaque protocol data the algorithm (not under standardization at this point) will work with ? I'd vote for the latter... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 16:36: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 4C2383A6B7E; Tue, 15 Jul 2008 16:36: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 0D8B83A6B7E for ; Tue, 15 Jul 2008 16:36:12 -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 z4t+dN8Ol-jo for ; Tue, 15 Jul 2008 16:36:11 -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 1A2F03A6B76 for ; Tue, 15 Jul 2008 16:36:11 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4774474rvf.49 for ; Tue, 15 Jul 2008 16:36:39 -0700 (PDT) Received: by 10.141.88.3 with SMTP id q3mr7827388rvl.94.1216164999585; Tue, 15 Jul 2008 16:36:39 -0700 (PDT) Received: from Inbox ( [75.210.211.212]) by mx.google.com with ESMTPS id g31sm12267632rvb.2.2008.07.15.16.36.36 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:36:39 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Tue, 15 Jul 2008 16:36:38 -0700 Importance: normal X-Priority: 3 To: Salman Abdul Baset , Enrico Marocco Message-ID: <487d3487.1f538c0a.469a.4a51@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Solving self-interference is the very point of congestion control, which is totally in scope for TANA. -----Original Message----- From: "Salman Abdul Baset" To: "Enrico Marocco" Cc: "p2pi@ietf.org" Sent: 7/15/08 6:16 AM Subject: Re: [p2pi] ALTO BoF - generalize Information about self-interference can guide peer selection. For example, with this information, a P2PSIP application running on one of several machines behind the cable/DSL modem can more accurately determine the presence or absence of self-interference. In the absence of self-interference and after network usage has left the P2PSIP application convinced that it has enough capacity, it can advertise itself as a relay in the overlay. > The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly > covers transport issues like congestion notification and sharing of > network resources; its problem statement is available at: > http://tools.ietf.org/id/draft-shalunov-tana-problem-statement It is not clear to me whether it will/should be in the scope of ALTO or TANA to address the self-interference issue. Note that self-interference can be categorized as (1) interference with applications running on the *same* machine (2) interference with applications running on *different* machines that are behind the same cable/DSL modem. -s _______________________________________________ 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 Jul 15 16:43: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 0B0EE3A67CF; Tue, 15 Jul 2008 16:43: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 F1E463A67BD for ; Tue, 15 Jul 2008 16:43:23 -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 fe9yHix5BdVn for ; Tue, 15 Jul 2008 16:43:22 -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 985703A685C for ; Tue, 15 Jul 2008 16:43:22 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1478706yxg.49 for ; Tue, 15 Jul 2008 16:43:50 -0700 (PDT) Received: by 10.140.171.18 with SMTP id t18mr4593891rve.22.1216165429629; Tue, 15 Jul 2008 16:43:49 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id k2sm12334057rvb.4.2008.07.15.16.43.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 16:43:49 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <487D07E5.4070104@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 16:43:46 -0700 References: <487D07E5.4070104@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - 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 And of course we're all familiar with the computer science concept of computation with an oracle, where a Turing machine is fitted with a single-step access to computing an arbitrary (not necessarily partially recursive) function. As for trackers, the concept is probably indeed not widely understood outside of P2P world, but given that ALTO originated in P2PI, it'd seem that it's safe to expect we don't need to define "peer", "tracker", etc., to be understood. But it probably won't hurt either. -- Stas On Jul 15, 2008, at 1:26 PM, Vijay K. Gurbani wrote: > Roy, Radhika R Dr CTR USA USAMC wrote: >> Hi, all: >> Many of us do not understand the words "Oracle" and "Tracker" right >> form the charter. >> So, the above two words have been clarified in the modified one as >> follows (also enclosed in a file with change marks). > > Radhika: Thank you immensely for a close read. > > Your point is well taken, however the best place to define > any such values will probably be a terminology I-D of some sort. > The good folks who have put out the requirements document > (please see http://tools.ietf.org/html/draft-kiesel-alto-reqs-00) > have started a terminology section in S3 of the above draft. > It is expected that this section may expand and consume its own > draft at some time in the future. > > Having said that, I do want to point out that we are using > the term "oracle" in the canonical meaning of the word > as defined by Merriam-Webster's dictionary; namely > > a person giving wise or authoritative decisions or opinions > > Think of the Oracle of Delphi. There is no more magic about it > beyond that. > > Regarding the term tracker, a stab at a definition is already > there in the above draft (end of page 6.) The authors would > probably be advised to expand on it in subsequent releases of > the draft. > > And finally, one clarification in your suggested modification: > > OLD: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > as well as tracker-less P2P networks. > > NEW: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > that communicate among its Internet Service Provider (ISP)-based > P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. > > Tracker-less does not necessarily imply non-ISP any more than > tracker-based implies explicit ISP support. IMHO, I believe that > the text as written in the draft charter is sufficient and > the conflation of the role of an ISP with the need for trackers > may serve to confuse the issue further. > > Thank you. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 17:05: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 AB93A3A6782; Tue, 15 Jul 2008 17:05: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 0134D3A65A6 for ; Tue, 15 Jul 2008 17:05: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 6uFXGUMp+Tv8 for ; Tue, 15 Jul 2008 17:05:21 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id EAF0F3A6782 for ; Tue, 15 Jul 2008 17:05:20 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3023288pyg.24 for ; Tue, 15 Jul 2008 17:05:49 -0700 (PDT) Received: by 10.141.51.15 with SMTP id d15mr7834270rvk.106.1216166748879; Tue, 15 Jul 2008 17:05:48 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id f21sm12349656rvb.0.2008.07.15.17.05.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 17:05:46 -0700 (PDT) Message-Id: <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <48777404.4080208@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 17:05:43 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 11, 2008, at 7:53 AM, Vijay K. Gurbani wrote: > Laird, Stanislav: I think both of you are proposing that cache- > discovery be a part of ALTO. I am trying to make a distinction > between /cache/ and /content/ in the context of our work. Cache is a computer. Content is a sequence of bits. How can there be confusion? > In a P2P application-based overlay, the "best" peer (however > the network defines "best") is where the querying peer should > be sent to get the resource in question from. What's a resource in this context? Like a given file? P2P apps (those that work, that is) are designed to deal with partial files and do so quite reasonably. You generally don't so much get a file from somewhere as you trade pieces with multiple peers. A cache is a special kind of peer simply because it's fast. As it feeds to the data, you discover you can slurp it up from the cache that wants nothing in return. And then you're done. > If we stretch > this analogy a bit further, it does not matter that the resource > is mirrored (cached) at the "best" peer or it appears as > the only instance of resource on the "best peer" (i.e., it is > not cached.) So in cases like this, I believe that sending > a querying peer to the "best" peer is immaterial of whether > or not the "best" peer is a caching-only server versus a > server providing original content. The content is immutable. OK. > In other applications like HTTP-based caching, it matters whether > or not a cache is hit or the origin server is hit. Agreed. > If caching is deemed to be a part of the charter, how do we define > it for ALTO? As long as ALTO provides a way to find it, the application -- be it a P2P app or a web browser -- could then decide how to use it appropriately. HTTP caching has defined semantics with bypass pragmas, etc. Current-gen P2P systems don't need this, because they are currently used only for static content delivery. If ways are found to distribute dynamic content through P2P, the cache notion will evolve, but the mechanism to find the cache would not need to. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 17:13: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 2C2CE3A6904; Tue, 15 Jul 2008 17:13: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 1AF733A67AF for ; Tue, 15 Jul 2008 17:13:07 -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 fRQtyJ1dxtBX for ; Tue, 15 Jul 2008 17:13:06 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 02B873A6904 for ; Tue, 15 Jul 2008 17:13:05 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8246366; Tue, 15 Jul 2008 20:13:03 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 20:13:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 20:12:09 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C102@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: Acjm06wPAyqgc9iuS06OPstmqb5gBAABOqLD From: "Woundy, Richard" To: , , X-OriginalArrivalTime: 16 Jul 2008 00:13:03.0398 (UTC) FILETIME=[B6C88C60:01C8E6D8] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 >OTOH, unconditionally obtaining the closest cache has no obvious problems. I could see a problem here. If ISP X makes an investment in caching servers, to benefit its customers in some way, it may not want ISP Y customers to contact its caching servers. Especially if the ISP X caching servers are closest to ISP Y customers only because ISP Y does not deploy any caching servers. (Of course in this scenario the ISP X caching servers could block non-ISP X traffic, if that is desired. I'm not advocating 'security by obscurity', just trying to avoid public announcement of non-global resources.) In this case, I could see the rationale for ISP X's ALTO server announcing caching servers to ISP X customer / ALTO clients. -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Enrico Marocco ; Sebastian Kiesel Cc: p2pi@ietf.org Sent: Tue Jul 15 19:36:30 2008 Subject: Re: [p2pi] Charter and problem statement It would require whatever is giving caches out to query them beforehand, a task easily accomplished by the client. More importantly, this would defeat the point of a cache, no? First, it's empty. So, nobody gets it. So it remains empty. OTOH, unconditionally obtaining the closest cache has no obvious problems. -----Original Message----- From: "Enrico Marocco" To: "Sebastian Kiesel" Cc: "p2pi@ietf.org" Sent: 7/15/08 6:32 AM Subject: Re: [p2pi] Charter and problem statement Sebastian Kiesel wrote: > On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >> For this level of discussion, I agree that caches should simply be >> viewed as a peer in ALTO. > > What happens if we consider caches and rare content, i.e., content where > the likelyhood is high, that there is a cache miss when we ask for it > and that the cache will never deliver a second copy of it? It might not > be wise to select a cache which is in the "opposite direction" of the > original content, even if connectivity to the cache is "better" > (according to whatever criteria). If the cache tries to fetch the > content the request may pass by the client and go through the same "bad" > link plus twice through the "good" one. As long as caches are viewed as regular peers, they will be included in ALTO requests/responses only if they actually have the resource the querying peer wants to access. -- 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 Jul 15 17:26: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 6BBFE3A6915; Tue, 15 Jul 2008 17:26: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 E9C713A6915 for ; Tue, 15 Jul 2008 17:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.021, 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 WgeEjgh1TVxh for ; Tue, 15 Jul 2008 17:26:35 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 0F7E03A6904 for ; Tue, 15 Jul 2008 17:26:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 438B6E10CCD; Tue, 15 Jul 2008 20:27:03 -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 GW7k0u0+02nY; Tue, 15 Jul 2008 20:27:02 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id ADD65E10CC3; Tue, 15 Jul 2008 20:27:02 -0400 (EDT) Date: Tue, 15 Jul 2008 20:27:02 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <479714973.13561216168022658.JavaMail.root@dkny.pando.com> In-Reply-To: <487d3483.1f538c0a.469a.4a4d@mx.google.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Stefano, Yes, I am suggesting that ALTO should make cache entities explicit to ALTO clients. And the means of doing so should be standardized so that there is interoperability. It could be expressed in the ALTO specification itself, or via the extension mechanism, of course. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: "stefano previdi" , "Laird Popkin" , "Enrico Marocco" Cc: p2pi@ietf.org Sent: Tuesday, July 15, 2008 7:36:34 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement The information conveyed to the client needs to enable the client to find a nearby cache (or three). Whether this information blob can be called opaque then is a semantic question, but to me, calling it opaque is misleading. Anything opaque is transparent to something higher up the stack. For example, should we use DNS to find the cache, the information is opaque on DNS layer. It is no longer opaque when it is used. If it is to allow any client to find the cache, it's not opaque to ALTO. -----Original Message----- From: "stefano previdi" To: "Laird Popkin" ; "Enrico Marocco" Cc: p2pi@ietf.org Sent: 7/15/08 6:41 AM Subject: Re: [p2pi] Charter and problem statement Laird, do you suggest to make the cache entity explicit in the ALTO protocol semantic ? Or is it just part of the opaque protocol data the algorithm (not under standardization at this point) will work with ? I'd vote for the latter... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 17:28: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 066A93A6915; Tue, 15 Jul 2008 17:28: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 507333A691E for ; Tue, 15 Jul 2008 17:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.245 X-Spam-Level: X-Spam-Status: No, score=-10.245 tagged_above=-999 required=5 tests=[AWL=0.020, 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 gosz70U0nyVx for ; Tue, 15 Jul 2008 17:28:09 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 79D6D3A6915 for ; Tue, 15 Jul 2008 17:28:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 12667E10CC9; Tue, 15 Jul 2008 20:28:38 -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 3l7ggpIrDOEo; Tue, 15 Jul 2008 20:28:30 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 8C0B9E10CC3; Tue, 15 Jul 2008 20:28:30 -0400 (EDT) Date: Tue, 15 Jul 2008 20:28:30 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <191748211.13591216168110541.JavaMail.root@dkny.pando.com> In-Reply-To: <487d3487.1f538c0a.469a.4a51@mx.google.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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 Good answer! :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: "Salman Abdul Baset" , "Enrico Marocco" Cc: p2pi@ietf.org Sent: Tuesday, July 15, 2008 7:36:38 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO BoF - generalize the problem Solving self-interference is the very point of congestion control, which is totally in scope for TANA. -----Original Message----- From: "Salman Abdul Baset" To: "Enrico Marocco" Cc: "p2pi@ietf.org" Sent: 7/15/08 6:16 AM Subject: Re: [p2pi] ALTO BoF - generalize Information about self-interference can guide peer selection. For example, with this information, a P2PSIP application running on one of several machines behind the cable/DSL modem can more accurately determine the presence or absence of self-interference. In the absence of self-interference and after network usage has left the P2PSIP application convinced that it has enough capacity, it can advertise itself as a relay in the overlay. > The TANA BoF discussed on the tsv-area@ietf.org mailing list explicitly > covers transport issues like congestion notification and sharing of > network resources; its problem statement is available at: > http://tools.ietf.org/id/draft-shalunov-tana-problem-statement It is not clear to me whether it will/should be in the scope of ALTO or TANA to address the self-interference issue. Note that self-interference can be categorized as (1) interference with applications running on the *same* machine (2) interference with applications running on *different* machines that are behind the same cable/DSL modem. -s _______________________________________________ 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 Jul 15 17:31: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 432C73A691E; Tue, 15 Jul 2008 17:31: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 75A2A3A68DB for ; Tue, 15 Jul 2008 17:31:33 -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 kcVY3BQyArV7 for ; Tue, 15 Jul 2008 17:31:32 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by core3.amsl.com (Postfix) with ESMTP id BAF0D3A6AAF for ; Tue, 15 Jul 2008 17:31:12 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3028117pyg.24 for ; Tue, 15 Jul 2008 17:31:41 -0700 (PDT) Received: by 10.141.190.9 with SMTP id s9mr7843757rvp.290.1216168300838; Tue, 15 Jul 2008 17:31:40 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id g31sm12357792rvb.2.2008.07.15.17.31.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 17:31:40 -0700 (PDT) Message-Id: <44D5BCE0-19FD-4C20-BA83-2474FF0702B8@shlang.com> From: Stanislav Shalunov To: "Woundy, Richard" In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C102@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 17:31:38 -0700 References: <74CCBBDF76102846AFA7B29F3A98D3F60107C102@PACDCEXCMB06.cable.comcast.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Agreed. I was tacitly assuming that the mechanism we use for cache discovery would not allow ISP Y to hand out ISP X's caches, because this is a property of most mechanisms we considered for this. Should ALTO come up with a non-centralized mechanism that does not have this property, it'd make sense to mention that it's in poor taste to make thy customers covet thy neighbor's ass by announcing its address to them. But not to worry: should ISP Y's customers somehow discover ISP X's cache through some sort of unanticipated leak -- say, through peer exchange, the cache, as you point out quite correctly, doesn't need to serve them any data, nor in fact accept their connections. -- Stas On Jul 15, 2008, at 5:12 PM, Woundy, Richard wrote: >> OTOH, unconditionally obtaining the closest cache has no obvious >> problems. > > I could see a problem here. If ISP X makes an investment in caching > servers, to benefit its customers in some way, it may not want ISP Y > customers to contact its caching servers. Especially if the ISP X > caching servers are closest to ISP Y customers only because ISP Y > does not deploy any caching servers. > > (Of course in this scenario the ISP X caching servers could block > non-ISP X traffic, if that is desired. I'm not advocating 'security > by obscurity', just trying to avoid public announcement of non- > global resources.) > > In this case, I could see the rationale for ISP X's ALTO server > announcing caching servers to ISP X customer / ALTO clients. > > -- Rich > > > ----- Original Message ----- > From: p2pi-bounces@ietf.org > To: Enrico Marocco ; Sebastian > Kiesel > Cc: p2pi@ietf.org > Sent: Tue Jul 15 19:36:30 2008 > Subject: Re: [p2pi] Charter and problem statement > > It would require whatever is giving caches out to query them > beforehand, a task easily accomplished by the client. > > More importantly, this would defeat the point of a cache, no? > First, it's empty. So, nobody gets it. So it remains empty. > > OTOH, unconditionally obtaining the closest cache has no obvious > problems. > > -----Original Message----- > From: "Enrico Marocco" > To: "Sebastian Kiesel" > Cc: "p2pi@ietf.org" > Sent: 7/15/08 6:32 AM > Subject: Re: [p2pi] Charter and problem statement > > Sebastian Kiesel wrote: >> On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >>> For this level of discussion, I agree that caches should simply be >>> viewed as a peer in ALTO. >> >> What happens if we consider caches and rare content, i.e., content >> where >> the likelyhood is high, that there is a cache miss when we ask for it >> and that the cache will never deliver a second copy of it? It might >> not >> be wise to select a cache which is in the "opposite direction" of the >> original content, even if connectivity to the cache is "better" >> (according to whatever criteria). If the cache tries to fetch the >> content the request may pass by the client and go through the same >> "bad" >> link plus twice through the "good" one. > > As long as caches are viewed as regular peers, they will be included > in > ALTO requests/responses only if they actually have the resource the > querying peer wants to access. > > -- > Ciao, > Enrico > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 20:44: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 E28F73A683B; Tue, 15 Jul 2008 20:44: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 149E73A683B for ; Tue, 15 Jul 2008 20:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 JxzFEbLarq85 for ; Tue, 15 Jul 2008 20:44:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 312A73A680C for ; Tue, 15 Jul 2008 20:44:27 -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 m6G3itVh013524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 22:44:55 -0500 (CDT) Received: from [135.244.32.252] (vkg.lra.lucent.com [135.244.32.252]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6G3io53023186; Tue, 15 Jul 2008 22:44:51 -0500 (CDT) Message-ID: <487D6EB4.50807@alcatel-lucent.com> Date: Tue, 15 Jul 2008 22:44:52 -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: Stanislav Shalunov References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> In-Reply-To: <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Stanislav Shalunov wrote: > A cache is a special kind of peer simply because it's fast. As it feeds > to the data, you discover you can slurp it up from the cache that wants > nothing in return. And then you're done. OK, excellent definition. Now ... > As long as ALTO provides a way to find it, the application -- be it a > P2P app or a web browser -- could then decide how to use it > appropriately. HTTP caching has defined semantics with bypass pragmas, > etc. Current-gen P2P systems don't need this, because they are > currently used only for static content delivery. If ways are found to > distribute dynamic content through P2P, the cache notion will evolve, > but the mechanism to find the cache would not need to. In an earlier email, you had pointed out one mechanism for cache discovery in BitTorrent: BEP 22. What do you envision ALTO doing above and beyond the techniques outlined in: - BEP 22 (namely, using PTR RR and walking down the DNS tree to the TLD doing SRV RRs)? - DNS-SD work? Excuse me if I am being dense, but I am trying to get a good handle on exactly what can ALTO standardize for cache discovery that is not already covered by some existing protocol. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 15 21:39: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 3161328C0FC; Tue, 15 Jul 2008 21:39: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 0933228C0FC for ; Tue, 15 Jul 2008 21:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 s06+Ju3pfsYJ for ; Tue, 15 Jul 2008 21:39:36 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id CD22F28C0F6 for ; Tue, 15 Jul 2008 21:39:35 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1505918yxg.49 for ; Tue, 15 Jul 2008 21:40:04 -0700 (PDT) Received: by 10.143.32.4 with SMTP id k4mr4952892wfj.251.1216183203607; Tue, 15 Jul 2008 21:40:03 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm6392101wfg.9.2008.07.15.21.40.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 21:40:03 -0700 (PDT) Message-Id: <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> From: Stanislav Shalunov To: "Vijay K. Gurbani" In-Reply-To: <487D6EB4.50807@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 21:40:01 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 15, 2008, at 8:44 PM, Vijay K. Gurbani wrote: > In an earlier email, you had pointed out one mechanism for cache > discovery in BitTorrent: BEP 22. To clarify the status of the BEP documents: they are only meaningful inside the BitTorrent community. This particular BEP is new and is not yet implemented by any client in the wild. To my knowledge, no ISP has configured this either. > What do you envision ALTO doing > above and beyond the techniques outlined in: > - BEP 22 (namely, using PTR RR and walking down the DNS > tree to the TLD doing SRV RRs)? The cache discovery portion of ALTO could be equivalent to BEP 22, or it could literally be the mechanism in BEP 22 and that would be quite sufficient for cache discovery. I did not want to focus on the particular solution at this point, because we still haven't formed a WG, but something like BEP 22 would be one option. > - DNS-SD work? DNS-SD would be another solution, also based on DNS. (BEP 22 could be viewed as inspired by DNS-SD, but self-contained.) There could probably be about a dozen others: special anycast address, etc., etc. > Excuse me if I am being dense, but I am trying to get a good > handle on exactly what can ALTO standardize for cache discovery > that is not already covered by some existing protocol. An ALTO document could, indeed, use an existing mechanism. (And certainly whatever mechanism is used it'd be silly not to use existing protocol building blocks.) The advantage of having it in an IETF standard vs, say, a BEP are: * with an IETF standard, cache vendors would be more confident in the stability of the spec and would be more inclined to build caches * ISPs would be more inclined to use and configure the discovery mechanism * IETF review would likely make the mechanism technically better * cache discovery is about more than BitTorrent, and the IETF is the right place to create a broad standard The usual IETF stuff -- what we're here to do. This is cross-vendor interoperability stuff, the point of standards. While even without the IETF, the BEP series might provide a lightweight form of standardization, I'd much prefer this work to occur in the IETF. Particularly given that there's the ALTO BoF specifically in this space and given that the work is straightforward. (As proof of concept, we could republish BEP 22 as an internet-draft, but again, it's too early for solutions drafts.) Does this make any sense? -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 15 22:32: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 A1DF43A6829; Tue, 15 Jul 2008 22:32: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 270103A6829 for ; Tue, 15 Jul 2008 22:32: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 R2Jn-ur-WjCI for ; Tue, 15 Jul 2008 22:32:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 9DAAC3A681A for ; Tue, 15 Jul 2008 22:32:54 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KIzde1FJ6-0005jl; Wed, 16 Jul 2008 01:33:22 -0400 From: "Stas Khirman" To: "'Stanislav Shalunov'" , "'Vijay K. Gurbani'" References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com><48777404.4080208@alcatel-lucent.com><480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com><487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> Date: Tue, 15 Jul 2008 22:33:14 -0700 Message-ID: <027001c8e705$74a8a040$6500a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjm/gYwsLzMQURrSD+/Q53Ofzwn0AAAMMHg In-Reply-To: <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> X-Provags-ID: V01U2FsdGVkX1/dPB5PccYD4A4FFESYtTY8H1Qu1CjbLuHDgf4 M4P1BScBfCub1KbNlSlhMOLsVXQty66BqJ/ZgYWpesirG8A1eG FdiZhewb5zvRTKV32YelQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 would like to express some doubts: Does "cache discovery" is in the scope of ALTO? Does it make sense to mix together seems to be irrelevant issues? It seems that ALTO can/have to be designed to be protocol and content agnostic. Indeed, from traffic optimization perspective it doesn't matter if peers are using eDonkey, BitTorrent or any other P2P ( or non-P2P) protocol and what content they are sharing. (especially considering that some P2P clients are capable to use multiple protocols ) Making ALTO protocol and content agnostic has many benefits: - can be adopted by variety of P2P networks/applications - can be adopted by non-P2P applications (such as CDN) - eliminates all DMCA-like liability for ISP's deployment of ALTO components - remove end-user privacy concerns IMHO, it is possible to design and implement such "agnostic" approach as peer selection optimization does not depend on specific protocol, but rather on "application requirements" ( minimize delay, localize traffic , etc) , peers capabilities, network topology, current utilizations and other ISP-related characteristics. I strongly believe that agnostic nature has to be one of the requirements for ALTO core implementation. On the other hand, cache discovery depends on (a) protocol and (b) content. BitTorrent cache server will not help in eDonkey traffic optimization. In general case, given content may be preserved in multiple caches or not at all. It seems that "cache discovery" have to be done BEFORE any attempt to "optimize" peer list - exactly like regular peers have to be discovered before ALTO optimization. Frankly, I have no opinion if "cache discovery" discussion belongs to ALTO WG or not. But if it included, IMHO, "cache" issues have to be clearly separated from "optimization" issues and this separation has to be considered in future design/implementation. Regards Stas > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stanislav Shalunov > Sent: Tuesday, July 15, 2008 9:40 PM > To: Vijay K. Gurbani > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > On Jul 15, 2008, at 8:44 PM, Vijay K. Gurbani wrote: > > In an earlier email, you had pointed out one mechanism for cache > > discovery in BitTorrent: BEP 22. > > To clarify the status of the BEP documents: they are only meaningful > inside the BitTorrent community. > > This particular BEP is new and is not yet implemented by any client in > the wild. To my knowledge, no ISP has configured this either. > > > What do you envision ALTO doing > > above and beyond the techniques outlined in: > > - BEP 22 (namely, using PTR RR and walking down the DNS > > tree to the TLD doing SRV RRs)? > > The cache discovery portion of ALTO could be equivalent to BEP 22, or > it could literally be the mechanism in BEP 22 and that would be quite > sufficient for cache discovery. > > I did not want to focus on the particular solution at this point, > because we still haven't formed a WG, but something like BEP 22 would > be one option. > > > - DNS-SD work? > > DNS-SD would be another solution, also based on DNS. (BEP 22 could be > viewed as inspired by DNS-SD, but self-contained.) > > There could probably be about a dozen others: special anycast address, > etc., etc. > > > Excuse me if I am being dense, but I am trying to get a good > > handle on exactly what can ALTO standardize for cache discovery > > that is not already covered by some existing protocol. > > An ALTO document could, indeed, use an existing mechanism. (And > certainly whatever mechanism is used it'd be silly not to use existing > protocol building blocks.) > > The advantage of having it in an IETF standard vs, say, a BEP are: > > * with an IETF standard, cache vendors would be more confident in the > stability of the spec and would be more inclined to build caches > > * ISPs would be more inclined to use and configure the discovery > mechanism > > * IETF review would likely make the mechanism technically better > > * cache discovery is about more than BitTorrent, and the IETF is the > right place to create a broad standard > > The usual IETF stuff -- what we're here to do. This is cross-vendor > interoperability stuff, the point of standards. While even without > the IETF, the BEP series might provide a lightweight form of > standardization, I'd much prefer this work to occur in the IETF. > Particularly given that there's the ALTO BoF specifically in this > space and given that the work is straightforward. (As proof of > concept, we could republish BEP 22 as an internet-draft, but again, > it's too early for solutions drafts.) > > Does this make any sense? > > -- > Stanislav Shalunov > http://shlang.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 Jul 16 00:04: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 B47713A699F; Wed, 16 Jul 2008 00:04: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 944D83A699F for ; Wed, 16 Jul 2008 00:04:29 -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 38zxGPdrQbx2 for ; Wed, 16 Jul 2008 00:04:28 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id DC8933A6892 for ; Wed, 16 Jul 2008 00:04:27 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1515118yxg.49 for ; Wed, 16 Jul 2008 00:04:54 -0700 (PDT) Received: by 10.142.221.19 with SMTP id t19mr4989219wfg.119.1216191894172; Wed, 16 Jul 2008 00:04:54 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm9746977wff.18.2008.07.16.00.04.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jul 2008 00:04:53 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: "Stas Khirman" In-Reply-To: <027001c8e705$74a8a040$6500a8c0@jnpr.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 00:04:51 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com><48777404.4080208@alcatel-lucent.com><480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com><487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <027001c8e705$74a8a040$6500a8c0@jnpr.net> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 15, 2008, at 10:33 PM, Stas Khirman wrote: > It seems that ALTO can/have to be designed to be protocol and content > agnostic. Yes, it can, and it probably should. Naturally it doesn't have to be designed this way, but it would be advantageous. > On the other hand, cache discovery depends on (a) protocol and (b) > content. Protocol, yes, in a trivially parametrizable way. You need to plug in the name of the protocol. Content, not so much, but it could be an argument that's passed in and then mostly ignored. > It seems that "cache discovery" have to be done BEFORE any attempt to > "optimize" peer list That's application-specific. Didn't you just argue to make it agnostic? In BitTorrent, no, we would not put it before. We'd make the cache discovery concurrent with everything else that's going on at the start of a torrent. > Frankly, I have no opinion if "cache discovery" discussion belongs > to ALTO > WG or not. Cache discovery was one of the themes of the workshop in Boston. Multiple P2P app makers, equipment vendors, and ISPs all want it to work. And it's in scope for ALTO. So while you may not have an opinion, others do. > But if it included, IMHO, "cache" issues have to be clearly > separated from "optimization" issues and this separation has to be > considered in future design/implementation. Resource discovery is, of course, a prerequisite for traffic optimization -- you have to know whom to ask before you can ask. I share the desire to have these in different documents, because the discovery piece can be very simple and would allow ALTO to quickly produce a deliverable that would be immediately useful. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 00:27: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 39CBD3A6892; Wed, 16 Jul 2008 00:27: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 A34DC3A6892 for ; Wed, 16 Jul 2008 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=0.133, 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 t9ovCwRmCCl2 for ; Wed, 16 Jul 2008 00:27:42 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 36F693A681A for ; Wed, 16 Jul 2008 00:27:42 -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, 16 Jul 2008 09:28:09 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 09:28:09 +0200 Received: from [10.229.8.112] (10.229.8.112) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 09:28:08 +0200 Message-ID: <487DA2F1.4000909@telecomitalia.it> Date: Wed, 16 Jul 2008 09:27:45 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Laird Popkin References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> In-Reply-To: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 16 Jul 2008 07:28:09.0171 (UTC) FILETIME=[7F096230:01C8E715] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============0569527878==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0569527878== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107060400010502060501" --------------ms090107060400010502060501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Laird Popkin wrote: > Actually, caches will probably want to be included in all ALTO > responses so that they are contacted by peers, so that they can > determine whether they want to cache the content (and have a data > source for the cache if so). Well, to include new caches' addresses in the response, the ALTO server needs to know the application the client is running, but I suspect not all users will be happy to pass such information to an external entity, maybe run by an ISP. Once again, optional extensions to a very simple base protocol will probably be the key. -- Ciao, Enrico --------------ms090107060400010502060501 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTYwNzI3NDVaMCMG CSqGSIb3DQEJBDEWBBRNrtUkfMPrSXm8K8bEApYi6PFMBzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABfkYcPW+LAj yJsaOMwvsCUH3X+dmui/mMQ1MnAsRMj8LmwwM71gfxL5GTME64xNLKvPeV0wjjE9vLIT97/j +GoArkLSeAkRfg/EAj39TeHOdAePj2MqGFgWXsix1eE/wrU81GN3eq19OjnKo9MHaTRKvYmN cTW8ff6VRBn0ICJnE4fVFbV0oIw0miVlYAAVGAfzoiE6CJeeCrGVllNflWTxGbK2BxabIKTB SZ85Nth+iSnI3EfEQ7s75CfIajv6X/QyQtTdRpx6M7asANeTtvP8gJJuKOvd1kzUcTG78eKH gZumM4oMBBdvm1o5ZyjQvRGrKmVzpi0J0+H5GB6diMYAAAAAAAA= --------------ms090107060400010502060501-- --===============0569527878== 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 --===============0569527878==-- From p2pi-bounces@ietf.org Wed Jul 16 00:29: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 E2C4828C162; Wed, 16 Jul 2008 00:29: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 DC8C628C162 for ; Wed, 16 Jul 2008 00:29: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 ep7OxW1K78rF for ; Wed, 16 Jul 2008 00:29:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id D527828C107 for ; Wed, 16 Jul 2008 00:29:55 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KJ1St05nK-0005cy; Wed, 16 Jul 2008 03:30:22 -0400 From: "Stas Khirman" To: "'Stanislav Shalunov'" References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com><48777404.4080208@alcatel-lucent.com><480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com><487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <027001c8e705$74a8a040$6500a8c0@jnpr.net> Date: Wed, 16 Jul 2008 00:30:15 -0700 Message-ID: <02a001c8e715$cd33e980$6500a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjnEkALeQR5JgP/QUarFa1Gh4pOYQAAWKrg In-Reply-To: X-Provags-ID: V01U2FsdGVkX1/JGkYMYGGKc1I6M0a9rlV8ycXqNVlI6NAhhC1 0V33xyR4dsoqlsp+dsdZmB737lPTPovnxxp6G+/s3vG7J5gAAM jgeiKBOnDUCC2yfNp7Iyg== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Stanislav Shalunov [mailto:shalunov@shlang.com] > On Jul 15, 2008, at 10:33 PM, Stas Khirman wrote: > > > > On the other hand, cache discovery depends on (a) protocol and (b) > > content. > > Protocol, yes, in a trivially parametrizable way. You need to plug in > the name of the protocol. > > Content, not so much, but it could be an argument that's passed in and > then mostly ignored. [Stas Khirman] I afraid your model will work only with a centralized cache where all content located in the same single virtual node. In general case, caching service can be distributed across ISP network - for example, very popular content has to be pushed down, as close as possible to the end-user (POP, CMTS, DSLAM ??), while less popular content can be cached in more centralized manner. In this , general model, specific content id (info_hash for BitTorrent) is a VERY important attribute for cache discovery. And certainly, discovery has to be made (a) individually for each unique content as each discovery may return different sets of appropriate caches (b) before attempt to optimize peer list as cache list can be quite unique for given content > > It seems that ALTO can/have to be designed to be protocol and content > > agnostic. > > Yes, it can, and it probably should. Naturally it doesn't have to be > designed this way, but it would be advantageous. > > > But if it included, IMHO, "cache" issues have to be clearly > > separated from "optimization" issues and this separation has to be > > considered in future design/implementation. > > > Resource discovery is, of course, a prerequisite for traffic > optimization -- you have to know whom to ask before you can ask. > > I share the desire to have these in different documents, because the > discovery piece can be very simple and would allow ALTO to quickly > produce a deliverable that would be immediately useful. > [Stas Khirman] We are in agreement on this point. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 00:38: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 5F85F3A6881; Wed, 16 Jul 2008 00:38: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 BF8473A683B for ; Wed, 16 Jul 2008 00:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Jy5ygkx6gKa9 for ; Wed, 16 Jul 2008 00:38:38 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 50E463A681A for ; Wed, 16 Jul 2008 00:38:37 -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, 16 Jul 2008 09:39:05 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 09:39:04 +0200 Received: from [10.229.8.112] (10.229.8.112) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 09:39:04 +0200 Message-ID: <487DA581.3070209@telecomitalia.it> Date: Wed, 16 Jul 2008 09:38:41 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stanislav Shalunov References: <487d347e.1f538c0a.469a.4a49@mx.google.com> In-Reply-To: <487d347e.1f538c0a.469a.4a49@mx.google.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 16 Jul 2008 07:39:04.0748 (UTC) FILETIME=[05CA7EC0:01C8E717] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============1906003331==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1906003331== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050403080203010708080900" --------------ms050403080203010708080900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stanislav Shalunov wrote: > It would require whatever is giving caches out to query them > beforehand, a task easily accomplished by the client. > > More importantly, this would defeat the point of a cache, no? First, > it's empty. So, nobody gets it. So it remains empty. Right, what I meant was a mirror, not really a cache. -- Ciao, Enrico --------------ms050403080203010708080900 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTYwNzM4NDFaMCMG CSqGSIb3DQEJBDEWBBTdnUDS8G61wT6VpOZEBwGseZlgejBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAJlOEl6QXenA SDwJ9zMkfdOARJ+9m5P5YrQmRrQP9LhD/SK2W0gw/PIbeVslJ4xAjKG7t61TNyk5Ax8fZRrH qe4SdHWLC+pshlSfZYhjv17Nr2NMS/mpwHKhc12ZpaTUrsfIGV2A4Qxz1aQ9+iitbTOEzS4X t0HoF5mstNoLqauUSn6eB+9Xv04PhYHGBIR8Znue0uLJsNNKA+TiwpEsb0UkVkPXeVguxu0h 4R3xB5zSK4adXKRqtDFNkrpcVWh49DDAbhgvd2/Rr7x2HwEU8fBw7E8DijA9kipo5ZT04QhA ObixfpeFT7SIDNBgPb6i7/5d0ugtAQx6zHP20idrWhEAAAAAAAA= --------------ms050403080203010708080900-- --===============1906003331== 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 --===============1906003331==-- From p2pi-bounces@ietf.org Wed Jul 16 00:47: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 B8ABD3A683B; Wed, 16 Jul 2008 00:47: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 25D2E3A679C for ; Wed, 16 Jul 2008 00:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 3dAXxmGrm-qn for ; Wed, 16 Jul 2008 00:47:09 -0700 (PDT) Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by core3.amsl.com (Postfix) with ESMTP id 25AD93A683B for ; Wed, 16 Jul 2008 00:47:08 -0700 (PDT) Received: from [192.168.1.103] (67.188.243.194) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 00:47:38 -0700 Message-ID: From: Stanislav Shalunov To: "Stas Khirman" In-Reply-To: <02a001c8e715$cd33e980$6500a8c0@jnpr.net> MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 00:47:37 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com><48777404.4080208@alcatel-lucent.com><480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com><487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <027001c8e705$74a8a040$6500a8c0@jnpr.net> <02a001c8e715$cd33e980$6500a8c0@jnpr.net> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 16, 2008, at 12:30 AM, Stas Khirman wrote: > I afraid your model will work only with a centralized cache where all > content located in the same single virtual node. There's no harm in passing the resource id in, but a sane distributed design is still likely to ignore it, directing the user to the closest existing cache. The good news is that the design of the caching system does not need to be standardized. This is where vendors can innovate on caching strategies while still interoperating. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 00:48: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 A313E3A6AF6; Wed, 16 Jul 2008 00:48: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 9CB6A3A683B for ; Wed, 16 Jul 2008 00:48:04 -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 A9PG+keLqRH3 for ; Wed, 16 Jul 2008 00:48:03 -0700 (PDT) Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by core3.amsl.com (Postfix) with ESMTP id 7DD633A6A51 for ; Wed, 16 Jul 2008 00:48:03 -0700 (PDT) Received: from [192.168.1.103] (67.188.243.194) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 00:48:33 -0700 Message-ID: <0B9976D3-8B71-48EA-8FF1-99D326016294@shlang.com> From: Stanislav Shalunov To: Song Haibin In-Reply-To: <004601c8e716$38142440$4c09a40a@china.huawei.com> MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 00:48:32 -0700 References: <004601c8e716$38142440$4c09a40a@china.huawei.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 16, 2008, at 12:33 AM, Song Haibin wrote: > If so, the ALTO > client must identify the "kind" of cache it wants to get from the ALTO > server's selection. I don't know if it violates the rule of > application > agnostic here. ALTO doesn't need to know anything about BitTorrent to make it possible to discover caches for a string "BitTorrent". You could also ask for "HTTP" or "gopher", and again, ALTO would not need to know how these work. To interoperate on the ALTO level, it is only necessary to standardize these handles. (Whatever is behind that label needs to interoperate somehow, but it's not ALTO's job to make sure it does. It's the job of whoever specified the protocol to which the label refers.) While the list is potentially very long, we're trying to solve a specific problem, for which the practical list will consist of very few entries. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 00:59: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 39DFE3A6A37; Wed, 16 Jul 2008 00:59: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 2087F3A6A37 for ; Wed, 16 Jul 2008 00:59: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=[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 CFrQDxAn+HPJ for ; Wed, 16 Jul 2008 00:59:47 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CFE363A68E6 for ; Wed, 16 Jul 2008 00:59:47 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K43005B6A8GVQ@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:00:16 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300AHGA8E8E@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:00:16 -0700 (PDT) Received: from [172.24.1.12] (Forwarded-For: [10.164.9.76]) by szxmc03-in.huawei.com (mshttpd); Wed, 16 Jul 2008 16:00:02 +0800 Date: Wed, 16 Jul 2008 16:00:02 +0800 From: songhaibin 64081 To: vkg@alcatel-lucent.com, shalunov@shlang.com, stas@khirman.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Stas, I think "cache selection" would be better to describe this issue and should= be included in the scope of ALTO, just like the "peer selection". If cache= s are deployed by the ISP (Probably true in most cases), then it meets the = requirement that ALTO wants to expose the information that P2P application = can't measure for traffic optimization. Here cache is a special kind of peer, which is registered to the ALTO serve= r. ALTO server must respond to peer selection queries with the selected pee= rs and also caches. Of course, client can request resources from the cache = that doesn't have the requested resource, as cache can fetch the resource f= rom other peers/servers even other caches. IMO, there may be kinds of caches, P2P caches, http caches and etc. I don= =92t know if ALTO takes into account all these kinds of caches. If so, the = ALTO client must identify the "kind" of cache it wants to get from the ALTO= server's selection. I don't know if it violates the rule of application ag= nostic here. Best Regards! Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 01:05:02 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 50EF428C1B7; Wed, 16 Jul 2008 01:05:02 -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 17B6028C1BB for ; Wed, 16 Jul 2008 01:05:01 -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 mEua0-2ZzjI3 for ; Wed, 16 Jul 2008 01:05:00 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 4C13928C1AF for ; Wed, 16 Jul 2008 01:05:00 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300BB5AH538@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:05:29 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300AVNAH38E@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:05:29 -0700 (PDT) Received: from [172.24.1.12] (Forwarded-For: [10.164.9.76]) by szxmc03-in.huawei.com (mshttpd); Wed, 16 Jul 2008 16:05:15 +0800 Date: Wed, 16 Jul 2008 16:05:15 +0800 From: songhaibin 64081 In-reply-to: To: songhaibin 64081 Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Because there is something wrong with my email server, please ignore if you= receive this email again. ----- Original Message ----- From: songhaibin 64081 Date: Wednesday, July 16, 2008 4:00 pm Subject: Re: [p2pi] Charter and problem statement > Hi Stas, > = > I think "cache selection" would be better to describe this issue = > and should be included in the scope of ALTO, just like the "peer = > selection". If caches are deployed by the ISP (Probably true in = > most cases), then it meets the requirement that ALTO wants to = > expose the information that P2P application can't measure for = > traffic optimization. > = > Here cache is a special kind of peer, which is registered to the = > ALTO server. ALTO server must respond to peer selection queries = > with the selected peers and also caches. Of course, client can = > request resources from the cache that doesn't have the requested = > resource, as cache can fetch the resource from other peers/servers = > even other caches. > = > IMO, there may be kinds of caches, P2P caches, http caches and = > etc. I don=92t know if ALTO takes into account all these kinds of = > caches. If so, the ALTO client must identify the "kind" of cache = > it wants to get from the ALTO server's selection. I don't know if = > it violates the rule of application agnostic here. > = > Best 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 Wed Jul 16 01:08: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 7C58E3A6978; Wed, 16 Jul 2008 01:08: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 AFCB83A6978 for ; Wed, 16 Jul 2008 01:08:18 -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 kdTJiZ6EWSuI for ; Wed, 16 Jul 2008 01:08:18 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6A5A23A683B for ; Wed, 16 Jul 2008 01:08:17 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300BK7AMM38@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:08:46 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300A4NAML8E@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 01:08:46 -0700 (PDT) Received: from [172.24.1.12] (Forwarded-For: [10.164.9.76]) by szxmc03-in.huawei.com (mshttpd); Wed, 16 Jul 2008 16:08:32 +0800 Date: Wed, 16 Jul 2008 16:08:32 +0800 From: songhaibin 64081 In-reply-to: <0B9976D3-8B71-48EA-8FF1-99D326016294@shlang.com> To: Stanislav Shalunov Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <004601c8e716$38142440$4c09a40a@china.huawei.com> <0B9976D3-8B71-48EA-8FF1-99D326016294@shlang.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Stanislav Shalunov Date: Wednesday, July 16, 2008 3:48 pm Subject: Re: [p2pi] Charter and problem statement > On Jul 16, 2008, at 12:33 AM, Song Haibin wrote: > > If so, the ALTO > > client must identify the "kind" of cache it wants to get from > the ALTO > > server's selection. I don't know if it violates the rule of > > application > > agnostic here. > > > ALTO doesn't need to know anything about BitTorrent to make it > possible to discover caches for a string "BitTorrent". You could > also > ask for "HTTP" or "gopher", and again, ALTO would not need to know > how > these work. > > To interoperate on the ALTO level, it is only necessary to > standardize > these handles. Yes, that is the point. BR Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 02:12: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 95EBF28C299; Wed, 16 Jul 2008 02:12: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 2F7CF28C295 for ; Wed, 16 Jul 2008 02:12:39 -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=[AWL=0.000, 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 awKFUVKZyWFO for ; Wed, 16 Jul 2008 02:12:38 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8E01A28C1AD for ; Wed, 16 Jul 2008 02:12:36 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jul 2008 02:12:48 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 02:12:10 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 02:12:09 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 05:12:08 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 09:12:07 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 02:11:46 -0700 From: Reinaldo Penno To: "Vijay K. Gurbani" , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnI/iOVonYEHVOuUOnylRUVYJm9A== In-Reply-To: <487D6EB4.50807@alcatel-lucent.com> Mime-version: 1.0 X-OriginalArrivalTime: 16 Jul 2008 09:12:08.0200 (UTC) FILETIME=[05C9A880:01C8E724] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 discovery procedure based on DNS and outlined in BEP 22 is related to Local Trackers (you could think of them as ALTO servers/service). The cache discovery piece is done through HTTP. In a ALTO world the DNS based procedure outlined in BEP 22 (SRV based) could be used to find ALTO servers/service and this service could (thorough the protocol) indicate/order a list of caches. Thanks, Reinaldo On 7/15/08 8:44 PM, "Vijay K. Gurbani" wrote: > Stanislav Shalunov wrote: >> A cache is a special kind of peer simply because it's fast. As it feeds >> to the data, you discover you can slurp it up from the cache that wants >> nothing in return. And then you're done. > > OK, excellent definition. Now ... > >> As long as ALTO provides a way to find it, the application -- be it a >> P2P app or a web browser -- could then decide how to use it >> appropriately. HTTP caching has defined semantics with bypass pragmas, >> etc. Current-gen P2P systems don't need this, because they are >> currently used only for static content delivery. If ways are found to >> distribute dynamic content through P2P, the cache notion will evolve, >> but the mechanism to find the cache would not need to. > > In an earlier email, you had pointed out one mechanism for cache > discovery in BitTorrent: BEP 22. What do you envision ALTO doing > above and beyond the techniques outlined in: > - BEP 22 (namely, using PTR RR and walking down the DNS > tree to the TLD doing SRV RRs)? > - DNS-SD work? > > Excuse me if I am being dense, but I am trying to get a good > handle on exactly what can ALTO standardize for cache discovery > that is not already covered by some existing protocol. > > Thanks, > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 02:22: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 DEB5B28C377; Wed, 16 Jul 2008 02:22: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 CF06C28C21D for ; Wed, 16 Jul 2008 02:22:50 -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 9knfDt1YZrTC for ; Wed, 16 Jul 2008 02:22:49 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id E157A28C36A for ; Wed, 16 Jul 2008 02:22:46 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jul 2008 02:23:16 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 02:23:09 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jul 2008 05:23:05 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 09:23:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 02:22:43 -0700 From: Reinaldo Penno To: songhaibin 64081 , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnJYAo2ms5FeuWBUOSg+p49DBxCg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 Jul 2008 09:23:05.0484 (UTC) FILETIME=[8D8F3CC0:01C8E725] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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. We seem to be stuck in caching as if it is something special but it seems to me this is a general problem with any piece of network/topology information an ALTO server wants to convey. The entities involved in this protocol (P2P clients, ALTO servers, etc) need to to be able to encode/decode and understand in a uniform fashion the notions of weight, distance, peer, etc. The notion of passing caching information is just one aspect of it. Thanks, Reinaldo On 7/16/08 1:08 AM, "songhaibin 64081" wrote: > > ----- Original Message ----- > From: Stanislav Shalunov > Date: Wednesday, July 16, 2008 3:48 pm > Subject: Re: [p2pi] Charter and problem statement > >> On Jul 16, 2008, at 12:33 AM, Song Haibin wrote: >>> If so, the ALTO >>> client must identify the "kind" of cache it wants to get from >> the ALTO >>> server's selection. I don't know if it violates the rule of >>> application >>> agnostic here. >> >> >> ALTO doesn't need to know anything about BitTorrent to make it >> possible to discover caches for a string "BitTorrent". You could >> also >> ask for "HTTP" or "gopher", and again, ALTO would not need to know >> how >> these work. >> >> To interoperate on the ALTO level, it is only necessary to >> standardize >> these handles. > > > Yes, that is the point. > > BR > 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 Wed Jul 16 02:44: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 818123A6B78; Wed, 16 Jul 2008 02:44: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 1FAF83A6B78 for ; Wed, 16 Jul 2008 02:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=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 2VoXR0pXJNKO for ; Wed, 16 Jul 2008 02:44:11 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6C65D3A6B76 for ; Wed, 16 Jul 2008 02:44:11 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4300BE3F2G38@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 02:44:40 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K430069AF2EOP@usaga01-in.huawei.com> for p2pi@ietf.org; Wed, 16 Jul 2008 02:44:40 -0700 (PDT) Received: from [172.24.1.12] (Forwarded-For: [10.164.9.76]) by szxmc03-in.huawei.com (mshttpd); Wed, 16 Jul 2008 17:44:26 +0800 Date: Wed, 16 Jul 2008 17:44:26 +0800 From: songhaibin 64081 In-reply-to: To: Reinaldo Penno Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <487D6EB4.50807@alcatel-lucent.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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, > > In a ALTO world the DNS based procedure outlined in BEP 22 (SRV > based) could > be used to find ALTO servers/service and this service could > (thorough the > protocol) indicate/order a list of caches. Do you mean we use DNS SRV(or DNS-SD) to locate the ALTO servers and then use the ALTO service to rank the list of caches for a ALTO client? The question is how to choose a specific ALTO server for a client if there are more than one? BR Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 03:00: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 1D1143A6B7E; Wed, 16 Jul 2008 03:00: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 DD66D3A6B7E for ; Wed, 16 Jul 2008 02:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=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 0dnAgpenz0dM for ; Wed, 16 Jul 2008 02:59:58 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3DE3B3A6B78 for ; Wed, 16 Jul 2008 02:59:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jul 2008 02:57:44 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 02:59:38 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 02:59:38 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 05:59:36 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 09:59:36 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 02:59:14 -0700 From: Reinaldo Penno To: songhaibin 64081 Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnKpoYB/x0Q+SdjkSIC6RizX8P2g== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 Jul 2008 09:59:36.0585 (UTC) FILETIME=[A78EB790:01C8E72A] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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, BEP 22 suggests a procedure based on DNS to make a choice. Others are possible. People have tried to solve the important problem of "locating a server/service" in previous/current WGs with wide different levels of success such as SLPv1/v2, Zeroconf, DNS, DHCP, etc. DNS is usually what is featured on SIP/SIPPING/BEHAVE documents to discover SIP/STUN servers. Thanks, Reinaldo On 7/16/08 2:44 AM, "songhaibin 64081" wrote: > Hi Reinaldo, > >> >> In a ALTO world the DNS based procedure outlined in BEP 22 (SRV >> based) could >> be used to find ALTO servers/service and this service could >> (thorough the >> protocol) indicate/order a list of caches. > > Do you mean we use DNS SRV(or DNS-SD) to locate the ALTO servers and then use > the ALTO service to rank the list of caches for a ALTO client? > > The question is how to choose a specific ALTO server for a client if there are > more than one? > > BR > Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 07:01: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 89C243A69A5; Wed, 16 Jul 2008 07:01: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 BFFCB3A6913 for ; Wed, 16 Jul 2008 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 tdbqf3onUnIA for ; Wed, 16 Jul 2008 07:01:20 -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 293F23A69DF for ; Wed, 16 Jul 2008 07:01:20 -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 m6GE1mB19471; Wed, 16 Jul 2008 16:01:48 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GE1lA21113; Wed, 16 Jul 2008 16:01:47 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:01:22 +0200 From: stefano previdi To: Stanislav Shalunov , Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO BoF - generalize the problem Thread-Index: AcjnTG11q9XsrlM/Ed2IrgAX8vOM8g== In-Reply-To: <7FF88A9D-1C47-41F7-A451-CBF6736A94C0@shlang.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO BoF - generalize the problem 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: Stanislav Shalunov > > The router's in the path. It would seem the most obvious way to ask > it is to just send a packet, and the router would fiddle with > something in the header. I wonder how operators would like to "open" their backbone routers to such external requests... while I see the benefit of an ALTO server to interfaces them. s. > Explicit congestion control is hard to deploy and is a pie-in-the-sky > of transport-level solutions. Often, it can be approximated end-to- > end more easily. End-to-end is just so much easier. It is also > desirable to move forward in the explicit direction. Problem is at > this point we don't know what the right thing to communicate is -- it > remains a research rather than an engineering question. It's also not > something that is easy to experiment with -- imagine the total cost of > the RED and ECN experiments. And they're some of the most lightweight > forms of explicit congestion control. > > -- Stas > > On Jul 15, 2008, at 11:17 AM, Laird Popkin wrote: > >> To address Lars' point below, I think that the "oracle" is probably >> not the best place to ask about link level congestion, as that's a >> real-time stat, so the the best place to answer that question is >> probably the ISP's router nearest the edge (or DSLAM, etc>) but it >> might be the right place to ask for the location of the device to >> ask. :-) >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Salman Abdul Baset" >> To: "Lars Eggert" >> Cc: p2pi@ietf.org >> Sent: Tuesday, July 15, 2008 11:34:55 AM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO BoF - generalize the problem >> >> On Tue, 15 Jul 2008, Lars Eggert wrote: >> >>> On 2008-7-15, at 16:16, ext Salman Abdul Baset wrote: >>>> On Tue, 15 Jul 2008, Enrico Marocco wrote: >>>>> This discussion is certainly interesting, but it is not about >>>>> ALTO any >>>>> more, is it? I mean, in this context we are trying to charter a >>>>> working >>>>> group for developing some mechanism for optimizing peer >>>>> selection. At >>>>> best, "network" information will be used for selecting between a >>>>> peer >>>>> with FTTH access and a DSL ones, when no additional information is >>>>> available. >>> >>> Agree with Enrico. >>> >>>> Information about self-interference can guide peer selection. For >>>> example, >>>> with this information, a P2PSIP application running on one of >>>> several >>>> machines behind the cable/DSL modem can more accurately determine >>>> the >>>> presence or absence of self-interference. In the absence of >>>> self-interference and after network usage has left the P2PSIP >>>> application >>>> convinced that it has enough capacity, it can advertise itself as >>>> a relay >>>> in the overlay. >>> >>> Sure, we can dream up all kinds of information that would be useful >>> to an app >>> or protocol: accurate and timely topology graph information, >>> accurate and >>> timely congestion information, accurate and timely latency >>> information, etc. >>> App wants to know this stuff? Talk to the oracle - done! >> >> I certainly did not mean the extrapolation mentioned above :). I was >> refering to Enrico's point whether determining self-interference can >> guide >> peer selection. The concept of self-interference needs to be properly >> defined, though. Oracles are not a panacea for every problem and >> certainly >> not a solution for determining timely and accurate congestion or >> latency >> information. In addition, where to place oracles or their equivalent >> is an >> open question. >> >> The self-interference example and any ALTO solution must address the >> questions you raised. I will attempt to address your questions for the >> self-interference example later. >> >> -s >> >>> This misses a bunch of key issues, though: >>> >>> * Is it even possible for the oracle to gather all this >>> information? It's difficult for an app, sure - but why >>> do we think it will be easier for an oracle? >>> >>> * How accurate would this information be, how timely would >>> it be and what is the cost to gather and keep it up-to date? >>> >>> * How much interdepence does this create between layers that >>> were so far more loosely coupled? Are we giving up evolvability? >>> >>> * How much "better" (for some definition of better) will this >>> information let the app become? Is it worth the architectural >>> complexity? >>> >>> To make this concrete, lets go back to the self-interference >>> example: How >>> would an access router figure out that a bunch of flows are >>> interfering? On >>> what timescales would this detection mechanism operate, and how >>> sensitive >>> would it be? Will the router need to assume that all flows adhere >>> to some >>> specific congestion control mechanism? How much will performance be >>> improved? >>> >>> >>> Without at least a credible attempt to answer these sorts of >>> questions, I >>> don't think we have a basis to begin thinking about standardization. >>> >>> (And I agree that the more baked proposals in the ALTO space do >>> have answers >>> here.) >>> >>> 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 > > > -- > Stanislav Shalunov > http://shlang.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 Jul 16 07:01: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 BAFA43A6B9A; Wed, 16 Jul 2008 07:01: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 11D723A68FD for ; Wed, 16 Jul 2008 07:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_32=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 rAD49HH6cRxy for ; Wed, 16 Jul 2008 07:01:28 -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 C397728C16E for ; Wed, 16 Jul 2008 07:01:25 -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 m6GE1s119479; Wed, 16 Jul 2008 16:01:54 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GE1nA21242; Wed, 16 Jul 2008 16:01:49 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:01:24 +0200 From: stefano previdi To: songhaibin 64081 , Reinaldo Penno Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnTG6mrXX7VlM/Ed2IrgAX8vOM8g== In-Reply-To: Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: songhaibin 64081 > > Hi Reinaldo, > >> >> In a ALTO world the DNS based procedure outlined in BEP 22 (SRV >> based) could >> be used to find ALTO servers/service and this service could >> (thorough the >> protocol) indicate/order a list of caches. > > Do you mean we use DNS SRV(or DNS-SD) to locate the ALTO servers and then use > the ALTO service to rank the list of caches for a ALTO client? > > The question is how to choose a specific ALTO server for a client if there are > more than one? there are many ways to do that among which there's service differentiation (based on capabilities). ALTO servers may also compete to each others... s. > > BR > 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 Wed Jul 16 07:03: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 2B2DE3A69A5; Wed, 16 Jul 2008 07:03: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 E374B3A69A5 for ; Wed, 16 Jul 2008 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cu2K+u+yF5m8 for ; Wed, 16 Jul 2008 07:03:18 -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 534403A682A for ; Wed, 16 Jul 2008 07:03:18 -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 m6GE3kJ19687; Wed, 16 Jul 2008 16:03:47 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GE3kA25951; Wed, 16 Jul 2008 16:03:46 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:03:20 +0200 From: stefano previdi To: Stanislav Shalunov , Laird Popkin , Enrico Marocco Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnTLPK8okBXlM/Ed2IrgAX8vOM8g== In-Reply-To: <487d3483.1f538c0a.469a.4a4d@mx.google.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Stanislav Shalunov > > The information conveyed to the client needs to enable the client to find a > nearby cache (or three). Whether this information blob can be called opaque > then is a semantic question, but to me, calling it opaque is misleading. ok, I agree that "opaque" may be an overstatement... But I understand that the ALTO protocol shouldn't have a specific state machinery or behavior because it conveys cache based information. > Anything opaque is transparent to something higher up the stack. For example, > should we use DNS to find the cache, the information is opaque on DNS layer. > It is no longer opaque when it is used. > > If it is to allow any client to find the cache, it's not opaque to ALTO. ok. s. > > > > -----Original Message----- > From: "stefano previdi" > To: "Laird Popkin" ; "Enrico Marocco" > > Cc: p2pi@ietf.org > Sent: 7/15/08 6:41 AM > Subject: Re: [p2pi] Charter and problem statement > > Laird, > > do you suggest to make the cache entity explicit in the ALTO protocol > semantic ? > > Or is it just part of the opaque protocol data the algorithm (not under > standardization at this point) will work with ? > > I'd vote for the latter... > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 07:06: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 A59623A69DF; Wed, 16 Jul 2008 07:06: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 243643A682A for ; Wed, 16 Jul 2008 07:06:06 -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 0CkNX2pNMe-z for ; Wed, 16 Jul 2008 07:06:05 -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 C9AED3A679F for ; Wed, 16 Jul 2008 07:06:04 -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 m6GE1nq19475; Wed, 16 Jul 2008 16:01:49 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GE1mA21167; Wed, 16 Jul 2008 16:01:48 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:01:23 +0200 From: stefano previdi To: Reinaldo Penno , songhaibin 64081 , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnJYAo2ms5FeuWBUOSg+p49DBxCgAJu3lX In-Reply-To: Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Reinaldo Penno > > I agree. > > We seem to be stuck in caching as if it is something special but it seems to > me this is a general problem with any piece of network/topology information > an ALTO server wants to convey. yes. > The entities involved in this protocol (P2P clients, ALTO servers, etc) need > to to be able to encode/decode and understand in a uniform fashion the > notions of weight, distance, peer, etc. The notion of passing caching > information is just one aspect of it. I agree. s. > > Thanks, > > Reinaldo > > > On 7/16/08 1:08 AM, "songhaibin 64081" wrote: > >> >> ----- Original Message ----- >> From: Stanislav Shalunov >> Date: Wednesday, July 16, 2008 3:48 pm >> Subject: Re: [p2pi] Charter and problem statement >> >>> On Jul 16, 2008, at 12:33 AM, Song Haibin wrote: >>>> If so, the ALTO >>>> client must identify the "kind" of cache it wants to get from >>> the ALTO >>>> server's selection. I don't know if it violates the rule of >>>> application >>>> agnostic here. >>> >>> >>> ALTO doesn't need to know anything about BitTorrent to make it >>> possible to discover caches for a string "BitTorrent". You could >>> also >>> ask for "HTTP" or "gopher", and again, ALTO would not need to know >>> how >>> these work. >>> >>> To interoperate on the ALTO level, it is only necessary to >>> standardize >>> these handles. >> >> >> Yes, that is the point. >> >> BR >> 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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 07:21: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 803B83A6981; Wed, 16 Jul 2008 07:21: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 E93333A6981 for ; Wed, 16 Jul 2008 07:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 jZvalMkjifbF for ; Wed, 16 Jul 2008 07:21:01 -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 814DA3A697F for ; Wed, 16 Jul 2008 07:21:00 -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 m6GE8pe20098; Wed, 16 Jul 2008 16:08:51 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GE8pA10531; Wed, 16 Jul 2008 16:08:51 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:08:26 +0200 From: stefano previdi To: Laird Popkin , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjnTWouqKCh1FNAEd2IrgAX8vOM8g== In-Reply-To: <479714973.13561216168022658.JavaMail.root@dkny.pando.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 > > Stefano, > > Yes, I am suggesting that ALTO should make cache entities explicit to ALTO > clients. And the means of doing so should be standardized so that there is > interoperability. It could be expressed in the ALTO specification itself, or > via the extension mechanism, of course. now we'll have to explore what kind of cache-specific bits we want to standardize in the ALTO protocol... I have the feeling is going to be quite vast... My point was to keep the ALTO protocol agnostic enough in order to provide a generic protocol between ALTO providers/consumers. Having some bits in the request/response related to a cache entity/object, it's fine but I'm not sure how far we can go without significantly impacting the protocol engine. s. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Stanislav Shalunov" > To: "stefano previdi" , "Laird Popkin" , > "Enrico Marocco" > Cc: p2pi@ietf.org > Sent: Tuesday, July 15, 2008 7:36:34 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > The information conveyed to the client needs to enable the client to find a > nearby cache (or three). Whether this information blob can be called opaque > then is a semantic question, but to me, calling it opaque is misleading. > > Anything opaque is transparent to something higher up the stack. For example, > should we use DNS to find the cache, the information is opaque on DNS layer. > It is no longer opaque when it is used. > > If it is to allow any client to find the cache, it's not opaque to ALTO. > > > > -----Original Message----- > From: "stefano previdi" > To: "Laird Popkin" ; "Enrico Marocco" > > Cc: p2pi@ietf.org > Sent: 7/15/08 6:41 AM > Subject: Re: [p2pi] Charter and problem statement > > Laird, > > do you suggest to make the cache entity explicit in the ALTO protocol > semantic ? > > Or is it just part of the opaque protocol data the algorithm (not under > standardization at this point) will work with ? > > I'd vote for the latter... > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 07:21: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 CD0483A6981; Wed, 16 Jul 2008 07:21: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 F2D293A6981 for ; Wed, 16 Jul 2008 07:21:30 -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 OLe22Gx37vZB for ; Wed, 16 Jul 2008 07:21:30 -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 8F72D3A6913 for ; Wed, 16 Jul 2008 07:21:29 -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 m6GELwR21164; Wed, 16 Jul 2008 16:21:58 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6GELvA16519; Wed, 16 Jul 2008 16:21:57 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 16 Jul 2008 16:21:32 +0200 From: stefano previdi To: Reinaldo Penno , Laird Popkin , Enrico Marocco Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjmgG0Pq4R1ulJzEd2IrgAX8vOM8gADFvQTADCdc7Y= In-Reply-To: Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Reinaldo Penno > > Hi, > > Well, this brings a question if we are here to standardize a client-server > protocol or the data it carries as well. > > As we standardize the protocol we need to go through what kind of > information it queries. Are these peers, network masks, weights, etc? How > they are represented? What is mandatory and what is optional? These can be > opaque to the protocol in the wire but certainly not to the application. I agree. Opaque was referred to the protocol in the sense that it doesn't trigger any specific behavior of the protocol machinery. > Since we are talking about applications and we need to interoperate we need > to define those. At least that was my assumption. > > If we are here to just standardize a client-server protocol, there many, > many choices already available, including good ol' HTTP. > > So, if caches are just peers, they would be identified as peers or a special > type of peer. we need to find some form of characterization of the peer/resource and let the application to handle it. s. PS: I believe we have 3 or 4 threads crossing on the same subject... ;-) > > Thanks, > > Reinaldo > > > On 7/15/08 6:41 AM, "stefano previdi" wrote: > >> Laird, >> >> do you suggest to make the cache entity explicit in the ALTO protocol >> semantic ? >> >> Or is it just part of the opaque protocol data the algorithm (not under >> standardization at this point) will work with ? >> >> I'd vote for the latter... >> >> thanks. >> >> s. >> >>> From: Laird Popkin >>> Date: Tue, 15 Jul 2008 09:38:15 -0400 (EDT) >>> To: Enrico Marocco >>> Cc: >>> Subject: Re: [p2pi] Charter and problem statement >>> >>> Actually, caches will probably want to be included in all ALTO responses so >>> that they are contacted by peers, so that they can determine whether they >>> want >>> to cache the content (and have a data source for the cache if so). >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "Enrico Marocco" >>> To: "Sebastian Kiesel" >>> Cc: "Laird Popkin" , p2pi@ietf.org >>> Sent: Tuesday, July 15, 2008 9:32:18 AM (GMT-0500) America/New_York >>> Subject: Re: [p2pi] Charter and problem statement >>> >>> Sebastian Kiesel wrote: >>>> On Fri, Jul 11, 2008 at 11:10:41AM -0400, Laird Popkin wrote: >>>>> For this level of discussion, I agree that caches should simply be >>>>> viewed as a peer in ALTO. >>>> >>>> What happens if we consider caches and rare content, i.e., content where >>>> the likelyhood is high, that there is a cache miss when we ask for it >>>> and that the cache will never deliver a second copy of it? It might not >>>> be wise to select a cache which is in the "opposite direction" of the >>>> original content, even if connectivity to the cache is "better" >>>> (according to whatever criteria). If the cache tries to fetch the >>>> content the request may pass by the client and go through the same "bad" >>>> link plus twice through the "good" one. >>> >>> As long as caches are viewed as regular peers, they will be included in >>> ALTO requests/responses only if they actually have the resource the >>> querying peer wants to access. >>> >>> -- >>> 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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 08:12: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 88BBA3A697F; Wed, 16 Jul 2008 08:12: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 2444E3A698E for ; Wed, 16 Jul 2008 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 Te6c932-F-xu for ; Wed, 16 Jul 2008 08:12:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 014F33A697F for ; Wed, 16 Jul 2008 08:12:39 -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 m6GFD47o009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 10:13:04 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6GFCxoK011874; Wed, 16 Jul 2008 10:13:00 -0500 (CDT) Message-ID: <487E0FFF.8050504@alcatel-lucent.com> Date: Wed, 16 Jul 2008 10:13:03 -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: Stanislav Shalunov References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> In-Reply-To: <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" Subject: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 I have re-named this thread to track it better and summarize the discussion. Stanislav Shalunov wrote: > The cache discovery portion of ALTO could be equivalent to BEP 22, or it > could literally be the mechanism in BEP 22 and that would be quite > sufficient for cache discovery. Stanislav: I think we're making progress. So, in that spirit, let's try to flesh this out some more. Who do you see doing cache discovery? The ALTO server or the individual peers? If we take the view that a cache is a selfless peer who wants nothing in return, then its discovery is no different than discovering other peers. Then this is best relegated as a normal peer-discovery algorithm/process implemented in any given P2P overlay. Now, let's tackle the ALTO server doing cache discovery. If the ALTO server can use a standard means to discover a cache, why can't the peer use the same means? I believe that if cache discovery is moved to the realm of the ALTO server, it becomes more of cache "dissemination" problem than of cache "discovery." In other words, the ALTO server will be pre-configured by the ISP -- or if it is not operated by the ISP, will use other means -- to maintain a set of known caches. It has been suggested that caches "register" to the ALTO server. I think that this is probably not a good idea for a variety of reasons. Then, peers will query the ALTO server using a protocol yet to be defined (let's refer to this as the TBD protocol.) This TBD protocol will have an extension that the peer can use to provide the ALTO server with some hints (overlay protocol, i.e., BitTorrent, eDonkey; hash of the content, etc.) The TBD protocol will arrange it such that in a response, the querying peer is told to contact the cache first. With some additional work, this extension to the TBD protocol could be used to also find other resources like VoIP relays, and it can also be applicable for non-P2P uses like CDN. Is this an approach that seems feasible? If so, we can word- smith something to this effect and add it to the draft charter. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 16 10:08:23 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 BD1A83A680C; Wed, 16 Jul 2008 10:08: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 388BC28C163 for ; Wed, 16 Jul 2008 10:08: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 wQJFbJmpBaTp for ; Wed, 16 Jul 2008 10:08:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 4A93D3A67EB for ; Wed, 16 Jul 2008 10:08:21 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KJAUf1H8l-0005nD; Wed, 16 Jul 2008 13:08:50 -0400 From: "Stas Khirman" To: "'Enrico Marocco'" , "'Laird Popkin'" References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> <487DA2F1.4000909@telecomitalia.it> Date: Wed, 16 Jul 2008 10:08:37 -0700 Message-ID: <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjnFYHqlDOczpxlSt2fohZ/bItyGQATn4Qw In-Reply-To: <487DA2F1.4000909@telecomitalia.it> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1/pCal5ZdX0tbqaRATkrDKs2mksinYx7lwkVoN 3DKAfQfmMQ7Yu/CkYc0xOh3mNMy+01iSqpp92bQuoD2uakA0ff rYr4vRT6aH9ivEXZOC9Lg== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Enrico Marocco > Well, to include new caches' addresses in the response, the ALTO server > needs to know the application the client is running, but I suspect not > all users will be happy to pass such information to an external entity, > maybe run by an ISP. > [Stas Khirman] As matter of fact, "application" knowledge is just a smallest part of problem - cache discovery requires announcement of specific content request by end-user. It will create a lot of privacy and DMCA issues and probably will be "show-stopper" for adoption both by client application developers and ISPs. It is why I advocate clear separation of mechanisms for - peer selection optimization - resource discovery (cache discovery as a special case) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 10: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 DF19928C17B; Wed, 16 Jul 2008 10: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 954CF28C17B for ; Wed, 16 Jul 2008 10:08:29 -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 xyeibKXPQkBy for ; Wed, 16 Jul 2008 10:08:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 53CFA28C170 for ; Wed, 16 Jul 2008 10:08:28 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KJAUY1oNE-0005nD; Wed, 16 Jul 2008 13:08:45 -0400 From: "Stas Khirman" To: "'Song Haibin'" , "'Stanislav Shalunov'" , "'Vijay K. Gurbani'" References: <027001c8e705$74a8a040$6500a8c0@jnpr.net> <004601c8e716$38142440$4c09a40a@china.huawei.com> Date: Wed, 16 Jul 2008 10:08:37 -0700 Message-ID: <001401c8e766$9ae94b40$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjm/gYwsLzMQURrSD+/Q53Ofzwn0AAAMMHgAASUrlAAFQUMEA== In-Reply-To: <004601c8e716$38142440$4c09a40a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+SCMo0+Y0dWPp3T094y/JD74IMQfWMYoGwntt riemV5qxTg2HbEDtK3IPChP8AMIerCJoF7rtaMxRR4tEEsN3ue 5xCa1l1CostwHPypDQ/tg== Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Song, Actually, we are in the violent agreement here : I also see a complete equivalency between "cache selection" and "peer selection" - the problem is not in the selection, but in discovery. Resource discovery requires knowledge of resource type ( "BitTorrent") and context ( content id and other) and in general case uses little or no information about ISP topology. (I assume that application need to identify an exact cache as cache redirection is not an option for P2P applications - (a) not supported by today's protocols (b) creates a lot of security/privacy issues). Peer selection does not require knowledge about resource types and content, but uses a lot of topology knowledge and other ISP-sensitive information. > -----Original Message----- > From: Song Haibin [mailto:melodysong@huawei.com] > Sent: Wednesday, July 16, 2008 12:33 AM > To: 'Stas Khirman'; 'Stanislav Shalunov'; 'Vijay K. Gurbani' > Cc: p2pi@ietf.org > Subject: RE: [p2pi] Charter and problem statement > > Hi Stas, > > I think "cache selection" would be better to describe this issue and > should > be included in the scope of ALTO, just like the "peer selection". If > caches > are deployed by the ISP (Probably true in most cases), then it meets the > requirement that ALTO wants to expose the information that P2P application > can't measure for traffic optimization. > > Here cache is a special kind of peer, which is registered to the ALTO > server. ALTO server must respond to peer selection queries with the > selected > peers and also caches. Of course, client can request resources from the > cache that doesn't have the requested resource, as cache can fetch the > resource from other peers/servers even other caches. > > IMO, there may be kinds of caches, P2P caches, http caches and etc. I > don't > know if ALTO takes into account all these kinds of caches. If so, the ALTO > client must identify the "kind" of cache it wants to get from the ALTO > server's selection. I don't know if it violates the rule of application > agnostic here. > > Best Regards! > Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 10:24: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 52C193A698C; Wed, 16 Jul 2008 10:24: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 03B3C3A698C for ; Wed, 16 Jul 2008 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=0.103, 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 TwLW0xYsXTAs for ; Wed, 16 Jul 2008 10:24:15 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 5ADFF3A687C for ; Wed, 16 Jul 2008 10:24:14 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 19:24:41 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 19:24:40 +0200 Received: from [10.229.8.112] (10.229.8.112) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 19:24:40 +0200 Message-ID: <487E2EC0.1000109@telecomitalia.it> Date: Wed, 16 Jul 2008 19:24:16 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stas Khirman References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> <487DA2F1.4000909@telecomitalia.it> <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> In-Reply-To: <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 16 Jul 2008 17:24:40.0798 (UTC) FILETIME=[D4823FE0:01C8E768] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============0457579669==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0457579669== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060607070301090809010904" --------------ms060607070301090809010904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stas Khirman wrote: > As matter of fact, "application" knowledge is just a smallest part of > problem - cache discovery requires announcement of specific content request > by end-user. It will create a lot of privacy and DMCA issues and probably > will be "show-stopper" for adoption both by client application developers > and ISPs. I don't see issues as long as disclosure of such information is optional and up to the client. At worst, peers concerned by DMCA issues won't use the cache discovery extension (which in any case would be useful to peers in "controlled" P2P systems such as Pando or BBC's iPlayer). No? -- Ciao, Enrico --------------ms060607070301090809010904 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTYxNzI0MTZaMCMG CSqGSIb3DQEJBDEWBBSD5SjsXfS4wzZpOCtUE5EAJkMNTDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKHB2iv/8Iwo 0URe4Qph0eG3Xw5XtQWxqC+v9d38hFg3Fw2USP+VAfVPz9N5aO9H8GS+0nG2Nt/1ZMVfzsMJ 7/cT5sN9QBcD1FW5zcHYyUyHRDykrY1grMY/hNisuosQGxUraiIMmBnkmuQvGhQQN4kH4DBo fscbZyePR0+EpuWIrb1qS4eBQ2osyAeoWs2vi7OKl77ZilEl5rN/2AQJlDOYuufRUUgHw66Q ayzHoka/2G47bNeyDdUw8Z8HBjruO+G+JDQyJvO6GuqaJVKSL4Q+OlTXrykuhX/yB8LgAx1U xLf40mTpbtExFHXRvADfnUBDLfuQdHPAg1gGtWUo6JAAAAAAAAA= --------------ms060607070301090809010904-- --===============0457579669== 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 --===============0457579669==-- From p2pi-bounces@ietf.org Wed Jul 16 10:56: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 4F97D3A69F8; Wed, 16 Jul 2008 10:56: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 AC38F3A68A1 for ; Wed, 16 Jul 2008 10:56: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 GEbcwZbFfVzs for ; Wed, 16 Jul 2008 10:56:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id D02543A6A4A for ; Wed, 16 Jul 2008 10:56:26 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KJBFC2YDk-0004LY; Wed, 16 Jul 2008 13:56:54 -0400 From: "Stas Khirman" To: "'Enrico Marocco'" References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> <487DA2F1.4000909@telecomitalia.it> <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> <487E2EC0.1000109@telecomitalia.it> Date: Wed, 16 Jul 2008 10:56:49 -0700 Message-ID: <003001c8e76d$54d02dc0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjnaNcDai3rrGvfTC+sp36CQmyRxgAAwI2Q In-Reply-To: <487E2EC0.1000109@telecomitalia.it> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+3E90HgNdydQ/ByHEO4VtTI4iQjQzzQ56QMLP BNxevC/o7D09bnC7cb9srtCYi+tMEVcelyoU+CX/1zv+w8pV0C HfaYz/FY8KT81hhHUQsYg== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Stas Khirman wrote: > > As matter of fact, "application" knowledge is just a smallest part of > > problem - cache discovery requires announcement of specific content > request > > by end-user. It will create a lot of privacy and DMCA issues and > probably > > will be "show-stopper" for adoption both by client application > developers > > and ISPs. > > I don't see issues as long as disclosure of such information is optional > and up to the client. At worst, peers concerned by DMCA issues won't use > the cache discovery extension (which in any case would be useful to > peers in "controlled" P2P systems such as Pando or BBC's iPlayer). No? > [Stas Khirman] DMCA issue is rather ISP problem, not an end-user one. I'm not a layer (happy smile), but it seems that if ISP-own equipment able to distinguish a specific content, under specific conditions they are liable to provide filtering and other DMCA "safe-harbor" features. It will be a case even when a small part of clients includes content identifier into "optimization" request (regardless if ISP has or has no installed cache servers) My main point is that separating "optimization" and "discovery" processes we can eliminate all those issues all together, making ALTO more flexible and ISP less reluctant to deploy it ( or part of it). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 11:14: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 8357328C1C9; Wed, 16 Jul 2008 11:14: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 2F29728C1C9 for ; Wed, 16 Jul 2008 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.019, 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 cpMSr3Z1XJHk for ; Wed, 16 Jul 2008 11:14:44 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2F68328C1C6 for ; Wed, 16 Jul 2008 11:14:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id B0644E10B37; Wed, 16 Jul 2008 14:15:11 -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 Ivd81KP1GVKz; Wed, 16 Jul 2008 14:15:05 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 77A6FE10A4E; Wed, 16 Jul 2008 14:15:05 -0400 (EDT) Date: Wed, 16 Jul 2008 14:15:05 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <1262349316.14801216232105465.JavaMail.root@dkny.pando.com> In-Reply-To: <003001c8e76d$54d02dc0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 we should keep "cache location" and "peer location" distinct, as they have somewhat different specifics. But I think that they can both fit within the same (ALTO) framework, as they have much in common. I agree that keeping content identity out of cache location is a good idea. That being said, cache location doesn't need to be content-specific, because one the p2p client connects to the caches, the caches can determine what they do on a content-specific basis. So ALTO could (for example) decide which cache servers to send to a user based on the user's network location and protocol (e.g. Pando caches might run on different servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO can return multiple cache servers (i.e. pools) the cache servers can manage whether to cache specific content, or where to assign it, transparently to ALTO, without ALTO having to know (for cache location) what content is assigned where. This is good for the caches, as it gives them maximum flexibility, without having to implement a complex state-change mechanism between the cache servers and the ALTO server. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Enrico Marocco" Cc: "Laird Popkin" , p2pi@ietf.org Sent: Wednesday, July 16, 2008 1:56:49 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Stas Khirman wrote: > > As matter of fact, "application" knowledge is just a smallest part of > > problem - cache discovery requires announcement of specific content > request > > by end-user. It will create a lot of privacy and DMCA issues and > probably > > will be "show-stopper" for adoption both by client application > developers > > and ISPs. > > I don't see issues as long as disclosure of such information is optional > and up to the client. At worst, peers concerned by DMCA issues won't use > the cache discovery extension (which in any case would be useful to > peers in "controlled" P2P systems such as Pando or BBC's iPlayer). No? > [Stas Khirman] DMCA issue is rather ISP problem, not an end-user one. I'm not a layer (happy smile), but it seems that if ISP-own equipment able to distinguish a specific content, under specific conditions they are liable to provide filtering and other DMCA "safe-harbor" features. It will be a case even when a small part of clients includes content identifier into "optimization" request (regardless if ISP has or has no installed cache servers) My main point is that separating "optimization" and "discovery" processes we can eliminate all those issues all together, making ALTO more flexible and ISP less reluctant to deploy it ( or part of it). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 11:51: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 3A6B63A6A7E; Wed, 16 Jul 2008 11:51: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 031073A6A7B for ; Wed, 16 Jul 2008 11:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=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 IRA6bhiE3Esi for ; Wed, 16 Jul 2008 11:51:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id BE3613A6A77 for ; Wed, 16 Jul 2008 11:51:10 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KJC6B0qrS-0004Tt; Wed, 16 Jul 2008 14:51:38 -0400 From: "Stas Khirman" To: "'Vijay K. Gurbani'" , "'Stanislav Shalunov'" References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com><48777404.4080208@alcatel-lucent.com><480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com><487D6EB4.50807@alcatel-lucent.com><7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <487E0FFF.8050504@alcatel-lucent.com> Date: Wed, 16 Jul 2008 11:51:34 -0700 Message-ID: <006001c8e774$faa418e0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjnVncDRyvoMFwKRIGyG2GRPUFfHgAGMR7w In-Reply-To: <487E0FFF.8050504@alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1/fkxx6BIbNc9GfA4yOE7nNvp2inJb47iosMtQ +iE+W9zYEL595PxI0HWeaaL/xNGZxxJI7BLOn7LJXNXwVKbdqz +aDpzBO+AMKr/Flsf8kxw== Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 summarize my points from recent threads: "Peer selection optimization" is processes to select "optimal" subset of peers from set of discovered peers that have specific content or part of it. This process could/should be implemented without knowledge of specific protocol (protocols) supported by peers and content they share, but rather based on peers capabilities, ISP topology, utilization and other ISP-sensitive information. A few important assumptions/requirements for "optimization" process: - due necessity to deal with business sensitive information, ALTO "optimization" process will be deployed and operated by ISPs and not by any third-party - in general, good optimization requires a knowledge of set of all peers to chose from (and their capabilities/utilisation). Merging of few "optimized" subsets may result in sub-optimal decision. That, peer set discovery process has to be accomplished BEFORE optimization. - Content and protocol obscurity is very important requirement for ALTO "optimization" as it removes any concerns about end-user privacy and ISP legal exposure, which are one of the main reasons for ISPs reluctance to deal with P2P optimization today (P2P caching as an example) . So far, there are no reliable methods/protocols to satisfy "optimization" task. I strongly believe that once offered, content/protocol agnostic ALTO "peer selection optimization" will be quickly adopted by application developers and ISPs. "Resource discovery" is a process to discover [additional] peers that may be useful in content delivery. Cache discovery is a special case of it. A few important assumptions/requirements for "discovery" process: - Resource discovery process does not need to use ISP-sensitive information, such as topology, peering agreements, etc. - Resource discovery process requires some context information, such as type of resource, content id, etc. - Resource discovery do not need to deliver "optimal" set of peers. As matter of fact, it probably has no enough knowledge to do it. - Resource discovery and associated resources may be own and run by various entities, not just end-user ISP. For example, group of regional ISPs may run a shared caching service in the peering point. Resource discovery may be run by third party unrelated to given ISP(as matter of fact, BitTorrent tracker is a "discovery" service as well). - "Discovery" and "optimization" services may or may not run on the same equipment. IMHO, there are no technical needs to mix them together at all. - Discovery may have a number of issues with end-user privacy and ISP legal exposure There are already few proprietary "discovery protocols" (CacheLogics/BitTorrect CDP for example), but no one had been widely adopted. Considering expressed interest, it will be beneficiary to include open flexible "resource discovery" into ALTO scope. However, due legal issues, some ISPs may be reluctant to deploy any kind of ALTO "discovery" components. Considering business, legal and technical points above, I advocate to keep "optimization" and "discovery" as separate independent methods, protocols, implementations, components, etc.... Stas > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: Wednesday, July 16, 2008 8:13 AM > To: Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) > > I have re-named this thread to track it better and summarize > the discussion. > > Stanislav Shalunov wrote: > > The cache discovery portion of ALTO could be equivalent to BEP 22, or it > > could literally be the mechanism in BEP 22 and that would be quite > > sufficient for cache discovery. > > Stanislav: I think we're making progress. So, in that spirit, > let's try to flesh this out some more. > > Who do you see doing cache discovery? The ALTO server or the > individual peers? > > If we take the view that a cache is a selfless peer who wants > nothing in return, then its discovery is no different than > discovering other peers. Then this is best relegated as a > normal peer-discovery algorithm/process implemented in any > given P2P overlay. > > Now, let's tackle the ALTO server doing cache discovery. If the > ALTO server can use a standard means to discover a cache, why > can't the peer use the same means? > > I believe that if cache discovery is moved to the realm of > the ALTO server, it becomes more of cache "dissemination" problem > than of cache "discovery." In other words, the ALTO server > will be pre-configured by the ISP -- or if it is not operated by > the ISP, will use other means -- to maintain a set of known caches. > It has been suggested that caches "register" to the ALTO server. > I think that this is probably not a good idea for a variety of > reasons. > > Then, peers will query the ALTO server using a protocol yet to > be defined (let's refer to this as the TBD protocol.) This > TBD protocol will have an extension that the peer can use to > provide the ALTO server with some hints (overlay protocol, i.e., > BitTorrent, eDonkey; hash of the content, etc.) The TBD > protocol will arrange it such that in a response, the querying > peer is told to contact the cache first. > > With some additional work, this extension to the TBD protocol > could be used to also find other resources like VoIP relays, > and it can also be applicable for non-P2P uses like CDN. > > Is this an approach that seems feasible? If so, we can word- > smith something to this effect and add it to the draft > charter. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Wed Jul 16 11:53: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 016BB28C1ED; Wed, 16 Jul 2008 11:53: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 818DC28C1ED for ; Wed, 16 Jul 2008 11:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Kh1JYFVF16Cb for ; Wed, 16 Jul 2008 11:53:55 -0700 (PDT) Received: from EXHUB015-4.exch015.msoutlookonline.net (exhub015-4.exch015.msoutlookonline.net [207.5.72.96]) by core3.amsl.com (Postfix) with ESMTP id A10ED28C1E5 for ; Wed, 16 Jul 2008 11:53:55 -0700 (PDT) Received: from [192.168.1.103] (67.188.243.194) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 11:54:26 -0700 Message-ID: From: Stanislav Shalunov To: Stas Khirman In-Reply-To: <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 11:54:24 -0700 References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> <487DA2F1.4000909@telecomitalia.it> <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 16, 2008, at 10:08 AM, Stas Khirman wrote: > It will create a lot of privacy and DMCA issues and probably > will be "show-stopper" for adoption both by client application > developers > and ISPs. From the client perspective, it will not tell the ISP anything it doesn't already know, except in encrypted mode, where it'll naturally be disabled. This list has plenty of client application developers and ISPs. There is no need to hypothesize what they might or might not consider a show- stopper or a problem at all. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 12:07: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 474433A692A; Wed, 16 Jul 2008 12:07: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 DBAA53A6988 for ; Wed, 16 Jul 2008 12:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 N2mj-XgVRyUR for ; Wed, 16 Jul 2008 12:07:12 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 4311B3A692A for ; Wed, 16 Jul 2008 12:06:35 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KJCL9076f-0005oQ; Wed, 16 Jul 2008 15:07:05 -0400 From: "Stas Khirman" To: "'Stanislav Shalunov'" References: <598359409.6681216129095493.JavaMail.root@dkny.pando.com> <487DA2F1.4000909@telecomitalia.it> <001501c8e766$9e4aecd0$a00d11ac@jnpr.net> Date: Wed, 16 Jul 2008 12:07:02 -0700 Message-ID: <008101c8e777$22f5d5c0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjndV7vXbKaoaicSCWIAQ8PLs1smQAAD9Dw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX189bEXVoqyjqsNxb5DEk+CCduWClJWUwexQ8qi Q4a6m04HzE8Jhnfm9t4XGzhCpiKg6+C36k+k+D+iwghlqOr0zb bqzhbHcOV8MoBBjVTM6vg== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Stanislav Shalunov [mailto:shalunov@shlang.com] > From the client perspective, it will not tell the ISP anything it > doesn't already know, except in encrypted mode, where it'll naturally > be disabled. > [Stas Khirman] I respectfully disagree - without DPI, ISPs have no knowledge about specific content exchanged. With DPI, they have such knowledge, but can claim a "safe-harbor" as they are not facilitating exchange (and probably restricted to intervene due "net neutrality"). > This list has plenty of client application developers and ISPs. There > is no need to hypothesize what they might or might not consider a show- > stopper or a problem at all. [Stas Khirman] It is exactly a main reason for my postings - I want to clarify this issue in a large community of potential ALTO customers (mostly ISPs). I may be right or wrong in my opinion, but believe in clarifying major requirements before spending major efforts in design. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 12:11: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 37EB23A6844; Wed, 16 Jul 2008 12:11: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 08B2E3A6818 for ; Wed, 16 Jul 2008 12:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 j9tuNO+rVr-C for ; Wed, 16 Jul 2008 12:11:32 -0700 (PDT) Received: from exhub015-1.exch015.msoutlookonline.net (exhub015-1.exch015.msoutlookonline.net [207.5.72.93]) by core3.amsl.com (Postfix) with ESMTP id 55C653A68B4 for ; Wed, 16 Jul 2008 12:11:13 -0700 (PDT) Received: from [192.168.1.103] (67.188.243.194) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 12:11:43 -0700 Message-ID: <4484FA60-72D5-4200-821E-1B54803439C8@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <487E0FFF.8050504@alcatel-lucent.com> MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 12:11:42 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <487E0FFF.8050504@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote: > Who do you see doing cache discovery? The ALTO server or the > individual peers? Peers mainly. The ALTO server might use these same means as a convenience, but one can think of it as being configured with this information. > If we take the view that a cache is a selfless peer who wants > nothing in return, then its discovery is no different than > discovering other peers. Then this is best relegated as a > normal peer-discovery algorithm/process implemented in any > given P2P overlay. Unfortunately, this won't work too well. Consider a large BitTorrent swarm. You're only going to ever unchoke a very small fraction of the swarm, and the cache, most probably, is not going to be in it. Further, the cache would need to be cued by something like DPI then to even know it needs to be in the swarm. If you actively come to it knowing it's a very special peer, it solves both problems. > Now, let's tackle the ALTO server doing cache discovery. If the > ALTO server can use a standard means to discover a cache, why > can't the peer use the same means? It should. > I believe that if cache discovery is moved to the realm of > the ALTO server, it becomes more of cache "dissemination" problem > than of cache "discovery." In other words, the ALTO server > will be pre-configured by the ISP -- or if it is not operated by > the ISP, will use other means -- to maintain a set of known caches. > It has been suggested that caches "register" to the ALTO server. > I think that this is probably not a good idea for a variety of > reasons. I don't see why we need to standardize how ALTO servers are configured in this regard. The ISP buys something that somehow makes it work. Maybe it uses automated discovery so you don't configured it twice. Maybe it's bundled with the DNS server so you don't configure it twice (probably not, but a theoretic possibility). Maybe it's manually configured. > Then, peers will query the ALTO server using a protocol yet to > be defined (let's refer to this as the TBD protocol.) This > TBD protocol will have an extension that the peer can use to > provide the ALTO server with some hints (overlay protocol, i.e., > BitTorrent, eDonkey; hash of the content, etc.) The TBD > protocol will arrange it such that in a response, the querying > peer is told to contact the cache first. It might or might not work, depending on what an ALTO server is. If, for example, an ALTO server is a URL that contains BGP dump with all the communities, it'll work for traffic optimization, but won't help you find the cache. On the other hand, if you find the cache in the same way you find whatever is the ALTO server, it will definitely work, and it's easier to do. > With some additional work, this extension to the TBD protocol > could be used to also find other resources like VoIP relays, > and it can also be applicable for non-P2P uses like CDN. Yes. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 12:57: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 72EAA3A681A; Wed, 16 Jul 2008 12:57: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 946A93A681A for ; Wed, 16 Jul 2008 12:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.947 X-Spam-Level: X-Spam-Status: No, score=-9.947 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=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 E9d5jD2bgjWN for ; Wed, 16 Jul 2008 12:57:57 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 0748F3A63EC for ; Wed, 16 Jul 2008 12:57:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id B324CE10B5D; Wed, 16 Jul 2008 15:58:26 -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 o3XPSo4vifGR; Wed, 16 Jul 2008 15:57:58 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 7C2BCE10B5A; Wed, 16 Jul 2008 15:57:58 -0400 (EDT) Date: Wed, 16 Jul 2008 15:57:58 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <1529517116.15191216238278469.JavaMail.root@dkny.pando.com> In-Reply-To: <006001c8e774$faa418e0$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: Stanislav Shalunov , p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 A few comments: I believe that "- due necessity to deal with business sensitive information, ALTO "optimization" process will be deployed and operated by ISPs and not by any third-party" should not be a requirement for ALTO. While some ISPs want to use proprietary information to provide guidance, and thus want to run their own P4P iTrackers (and, by analogy, future ALTO servers), other ISPs feel just as strongly that they prefer to have an independent third party (like IANA) operate between the ISPs and the P2P networks. Given this, I believe that ALTO should not mandate a specific option, but should preserve flexibility for the ISPs to choose either model. Also, "discovery" and "optimization" are quite similar issues (because caches are p2p nodes), communicating related information between the same participants at the same time, so while a few minor details are different, they feel (to me) to be issues that should be addressed within the same framework and protocol. Given that ALTO is extensible, I'd prefer that we address cache location within ALTO than to invent two very similar protocols. The definition of "peer selection optimization" is (IMO) incorrect, unless I am misinterpreting your terminology. Let me try to provide an example to illustrate. Consider a swarm with 10,000 peers, of which a given peer knows about 40 peers, and is connected to 10. The greatest contribution that ALTO can make is to help the p2p network determine the best 40 peers to tell a peer to connect to, because the speed and performance savings are large, because it would take a long time (perhaps 2,000 minutes) to exchange data with all 10,000 peers and determine which are best/closest. There is minimal if any value in telling a peer which of the 40 known peers is closest, because the peer can fairly rapidly (perhaps 1 minute) measure throughput with all 40 peers and determine the best/closest peers without ALTO. Given this, the assertion that "peer set discovery process has to be accomplished BEFORE optimization" is incorrect, as the ALTO optimization is used to provide the optimal peer set to be 'discovered' by a peer. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Vijay K. Gurbani" , "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Wednesday, July 16, 2008 2:51:34 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) To summarize my points from recent threads: "Peer selection optimization" is processes to select "optimal" subset of peers from set of discovered peers that have specific content or part of it. This process could/should be implemented without knowledge of specific protocol (protocols) supported by peers and content they share, but rather based on peers capabilities, ISP topology, utilization and other ISP-sensitive information. A few important assumptions/requirements for "optimization" process: - due necessity to deal with business sensitive information, ALTO "optimization" process will be deployed and operated by ISPs and not by any third-party - in general, good optimization requires a knowledge of set of all peers to chose from (and their capabilities/utilisation). Merging of few "optimized" subsets may result in sub-optimal decision. That, peer set discovery process has to be accomplished BEFORE optimization. - Content and protocol obscurity is very important requirement for ALTO "optimization" as it removes any concerns about end-user privacy and ISP legal exposure, which are one of the main reasons for ISPs reluctance to deal with P2P optimization today (P2P caching as an example) . So far, there are no reliable methods/protocols to satisfy "optimization" task. I strongly believe that once offered, content/protocol agnostic ALTO "peer selection optimization" will be quickly adopted by application developers and ISPs. "Resource discovery" is a process to discover [additional] peers that may be useful in content delivery. Cache discovery is a special case of it. A few important assumptions/requirements for "discovery" process: - Resource discovery process does not need to use ISP-sensitive information, such as topology, peering agreements, etc. - Resource discovery process requires some context information, such as type of resource, content id, etc. - Resource discovery do not need to deliver "optimal" set of peers. As matter of fact, it probably has no enough knowledge to do it. - Resource discovery and associated resources may be own and run by various entities, not just end-user ISP. For example, group of regional ISPs may run a shared caching service in the peering point. Resource discovery may be run by third party unrelated to given ISP(as matter of fact, BitTorrent tracker is a "discovery" service as well). - "Discovery" and "optimization" services may or may not run on the same equipment. IMHO, there are no technical needs to mix them together at all. - Discovery may have a number of issues with end-user privacy and ISP legal exposure There are already few proprietary "discovery protocols" (CacheLogics/BitTorrect CDP for example), but no one had been widely adopted. Considering expressed interest, it will be beneficiary to include open flexible "resource discovery" into ALTO scope. However, due legal issues, some ISPs may be reluctant to deploy any kind of ALTO "discovery" components. Considering business, legal and technical points above, I advocate to keep "optimization" and "discovery" as separate independent methods, protocols, implementations, components, etc.... Stas > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: Wednesday, July 16, 2008 8:13 AM > To: Stanislav Shalunov > Cc: p2pi@ietf.org > Subject: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) > > I have re-named this thread to track it better and summarize > the discussion. > > Stanislav Shalunov wrote: > > The cache discovery portion of ALTO could be equivalent to BEP 22, or it > > could literally be the mechanism in BEP 22 and that would be quite > > sufficient for cache discovery. > > Stanislav: I think we're making progress. So, in that spirit, > let's try to flesh this out some more. > > Who do you see doing cache discovery? The ALTO server or the > individual peers? > > If we take the view that a cache is a selfless peer who wants > nothing in return, then its discovery is no different than > discovering other peers. Then this is best relegated as a > normal peer-discovery algorithm/process implemented in any > given P2P overlay. > > Now, let's tackle the ALTO server doing cache discovery. If the > ALTO server can use a standard means to discover a cache, why > can't the peer use the same means? > > I believe that if cache discovery is moved to the realm of > the ALTO server, it becomes more of cache "dissemination" problem > than of cache "discovery." In other words, the ALTO server > will be pre-configured by the ISP -- or if it is not operated by > the ISP, will use other means -- to maintain a set of known caches. > It has been suggested that caches "register" to the ALTO server. > I think that this is probably not a good idea for a variety of > reasons. > > Then, peers will query the ALTO server using a protocol yet to > be defined (let's refer to this as the TBD protocol.) This > TBD protocol will have an extension that the peer can use to > provide the ALTO server with some hints (overlay protocol, i.e., > BitTorrent, eDonkey; hash of the content, etc.) The TBD > protocol will arrange it such that in a response, the querying > peer is told to contact the cache first. > > With some additional work, this extension to the TBD protocol > could be used to also find other resources like VoIP relays, > and it can also be applicable for non-P2P uses like CDN. > > Is this an approach that seems feasible? If so, we can word- > smith something to this effect and add it to the draft > charter. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 13:08: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 69CC93A6816; Wed, 16 Jul 2008 13:08: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 63CE93A681A for ; Wed, 16 Jul 2008 13:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 ej+2LCKmt1PT for ; Wed, 16 Jul 2008 13:08:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 765E93A6816 for ; Wed, 16 Jul 2008 13:08:28 -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 m6GK8vEv004306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 15:08:58 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6GK8qZe016311; Wed, 16 Jul 2008 15:08:53 -0500 (CDT) Message-ID: <487E5558.7000503@alcatel-lucent.com> Date: Wed, 16 Jul 2008 15:08: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: Stanislav Shalunov References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <487E0FFF.8050504@alcatel-lucent.com> <4484FA60-72D5-4200-821E-1B54803439C8@shlang.com> In-Reply-To: <4484FA60-72D5-4200-821E-1B54803439C8@shlang.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Stanislav Shalunov wrote: > On Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote: >> Who do you see doing cache discovery? The ALTO server or the >> individual peers? > > Peers mainly. The ALTO server might use these same means as a > convenience, but one can think of it as being configured with this > information. OK; good. So we have peers that mainly perform cache discovery using some protocol (more on this below.) >> I believe that if cache discovery is moved to the realm of >> the ALTO server, it becomes more of cache "dissemination" problem >> than of cache "discovery." In other words, the ALTO server >> will be pre-configured by the ISP -- or if it is not operated by >> the ISP, will use other means -- to maintain a set of known caches. >> It has been suggested that caches "register" to the ALTO server. >> I think that this is probably not a good idea for a variety of >> reasons. > > I don't see why we need to standardize how ALTO servers are configured > in this regard. You misunderstood. I was not saying that we standardize how ALTO servers are configured (we should not go down that path, obviously.) The point of my paragraph above was to determine if the ALTO server is the only entity that does cache discovery, do we need to specify a protocol at all? So, it looks like the following statements apply (for sake of sanity, I will take a leap of faith and assume that we have an actual ALTO server instead of representing it a URL of a BGP dump): Discovering caches and other resources: 1) Peers may discover caches using a protocol X. The protocol X may be as simple as using well known DNS techniques to bootstrap the discovery process (i.e., something akin to DNS-SD, BEP-22, etc.) 2) The ALTO server may be asked by the peers to discover caches using certain extensions to the ALTO protocol Y (Note: Y != X). When so asked, the ALTO server can use protocol X to discover those caches on behalf of the peers, and using additional information provided by the peer. 3) The ALTO server may be asked by applications to discover other resources using certain extensions to the ALTO protocol Y. When so asked, the ALTO server can use protocol X to discover such resources on behalf of the applications, and using additional information provided by the application. Yes? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 16 13:22:09 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 B7BFE3A683C; Wed, 16 Jul 2008 13:22:09 -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 9246A3A682C for ; Wed, 16 Jul 2008 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 PKHukXZojhdQ for ; Wed, 16 Jul 2008 13:22:07 -0700 (PDT) Received: from EXHUB015-4.exch015.msoutlookonline.net (exhub015-4.exch015.msoutlookonline.net [207.5.72.96]) by core3.amsl.com (Postfix) with ESMTP id AAA753A683C for ; Wed, 16 Jul 2008 13:22:07 -0700 (PDT) Received: from [192.168.1.103] (67.188.243.194) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 16 Jul 2008 13:22:38 -0700 Message-ID: <07A66517-DB3E-4491-BC65-AB600CA64123@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <487E5558.7000503@alcatel-lucent.com> MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 16 Jul 2008 13:22:36 -0700 References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <487E0FFF.8050504@alcatel-lucent.com> <4484FA60-72D5-4200-821E-1B54803439C8@shlang.com> <487E5558.7000503@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Jul 16, 2008, at 1:08 PM, Vijay K. Gurbani wrote: > Discovering caches and other resources: > > 1) Peers may discover caches using a protocol X. The protocol > X may be as simple as using well known DNS techniques to > bootstrap the discovery process (i.e., something akin to > DNS-SD, BEP-22, etc.) Yes. This is the main and easiest case. > 2) The ALTO server may be asked by the peers to discover caches > using certain extensions to the ALTO protocol Y (Note: Y != X). Perhaps, I believe cache discovery would work fine either way, whether or not Y exists. This sort of Y could produce caches, dynamic information about nearby peers, etc. > When so asked, the ALTO server can use protocol X to discover > those caches on behalf of the peers, and using additional > information provided by the peer. Yes. > 3) The ALTO server may be asked by applications to discover > other resources using certain extensions to the ALTO protocol Y. > When so asked, the ALTO server can use protocol X to discover > such resources on behalf of the applications, and using additional > information provided by the application. Not sure what kind of resources, but yes, potentially. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 13: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 DE6A73A68B4; Wed, 16 Jul 2008 13: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 E8D263A68AB for ; Wed, 16 Jul 2008 13:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.033, 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 c-fhiz6dGqtv for ; Wed, 16 Jul 2008 13:22:35 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 960B53A683C for ; Wed, 16 Jul 2008 13:22:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id B49EBE10B75; Wed, 16 Jul 2008 16:23: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 bH+LUKOsfLpW; Wed, 16 Jul 2008 16:22:46 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 6E63AE10BB5; Wed, 16 Jul 2008 16:22:46 -0400 (EDT) Date: Wed, 16 Jul 2008 16:22:46 -0400 (EDT) From: Laird Popkin To: "Vijay K. Gurbani" Message-ID: <575703953.15381216239766411.JavaMail.root@dkny.pando.com> In-Reply-To: <1791397884.15361216239445332.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 There are different entities in different p2p networks that might do cache discovery. The current caching vendors provide: - In-line 'cache discovery' where the cache is in-line in traffic, caching data and responding to requests rather than passing the requests for cached data on to other peers. This is fragile and doesn't scale well. - DPI-based 'cache discovery', where a DPI box inspects the p2p traffic and tells the p2p cache server about p2p tranfers, which the cache server can join into. This is also fragile, involving protocol reverse engineering. - Client-based cache discovery, where each p2p client on each download start would perform (theoretically) one cache check for each cache vendor, and use whatever comes back. This is complex and inefficient. - Server-based cache discovery, where each p2p network knows where p2p cache servers are and tells appropriate peers to connect to the caches. This is the most efficient approach, but requires ISPs to inform p2p networks of cache locations and rules (e.g. IP prefixes) for assigning users to caches, or equivalent lookups. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Wednesday, July 16, 2008 4:08:56 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) Stanislav Shalunov wrote: > On Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote: >> Who do you see doing cache discovery? The ALTO server or the >> individual peers? > > Peers mainly. The ALTO server might use these same means as a > convenience, but one can think of it as being configured with this > information. OK; good. So we have peers that mainly perform cache discovery using some protocol (more on this below.) >> I believe that if cache discovery is moved to the realm of >> the ALTO server, it becomes more of cache "dissemination" problem >> than of cache "discovery." In other words, the ALTO server >> will be pre-configured by the ISP -- or if it is not operated by >> the ISP, will use other means -- to maintain a set of known caches. >> It has been suggested that caches "register" to the ALTO server. >> I think that this is probably not a good idea for a variety of >> reasons. > > I don't see why we need to standardize how ALTO servers are configured > in this regard. You misunderstood. I was not saying that we standardize how ALTO servers are configured (we should not go down that path, obviously.) The point of my paragraph above was to determine if the ALTO server is the only entity that does cache discovery, do we need to specify a protocol at all? So, it looks like the following statements apply (for sake of sanity, I will take a leap of faith and assume that we have an actual ALTO server instead of representing it a URL of a BGP dump): Discovering caches and other resources: 1) Peers may discover caches using a protocol X. The protocol X may be as simple as using well known DNS techniques to bootstrap the discovery process (i.e., something akin to DNS-SD, BEP-22, etc.) 2) The ALTO server may be asked by the peers to discover caches using certain extensions to the ALTO protocol Y (Note: Y != X). When so asked, the ALTO server can use protocol X to discover those caches on behalf of the peers, and using additional information provided by the peer. 3) The ALTO server may be asked by applications to discover other resources using certain extensions to the ALTO protocol Y. When so asked, the ALTO server can use protocol X to discover such resources on behalf of the applications, and using additional information provided by the application. Yes? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Wed Jul 16 13:23: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 3A28D3A683C; Wed, 16 Jul 2008 13:23: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 D24E13A683C for ; Wed, 16 Jul 2008 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 CcH7PnhTt2kG for ; Wed, 16 Jul 2008 13:23:42 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 1D77A3A682C for ; Wed, 16 Jul 2008 13:23:42 -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 m6GKO9vd006880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 15:24:09 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6GKO5hL001907; Wed, 16 Jul 2008 15:24:05 -0500 (CDT) Message-ID: <487E58E9.5070509@alcatel-lucent.com> Date: Wed, 16 Jul 2008 15:24:09 -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: Stanislav Shalunov References: <870236426.500961215785602281.JavaMail.root@dkny.pando.com> <48777404.4080208@alcatel-lucent.com> <480E66E3-E287-48C3-9D97-A286B524CAAD@shlang.com> <487D6EB4.50807@alcatel-lucent.com> <7C3E1366-F37C-472A-9760-F8714D09B29D@shlang.com> <487E0FFF.8050504@alcatel-lucent.com> <4484FA60-72D5-4200-821E-1B54803439C8@shlang.com> <487E5558.7000503@alcatel-lucent.com> <07A66517-DB3E-4491-BC65-AB600CA64123@shlang.com> In-Reply-To: <07A66517-DB3E-4491-BC65-AB600CA64123@shlang.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Stanislav Shalunov wrote: > Not sure what kind of resources, but yes, potentially. VoIP relays, CDN caches, etc. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 16 13:28: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 EAE073A6891; Wed, 16 Jul 2008 13:28: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 5CFA03A688A for ; Wed, 16 Jul 2008 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 cRnRWhAreiUJ for ; Wed, 16 Jul 2008 13:28:53 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 337B73A6818 for ; Wed, 16 Jul 2008 13:28:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jul 2008 13:28:29 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 13:27:53 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 16:27:51 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 20:27:50 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 13:27:28 -0700 From: Reinaldo Penno To: "Vijay K. Gurbani" , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) Thread-Index: Acjngl14c2qBrnBqdkueXkokPx2KxQ== In-Reply-To: <487E58E9.5070509@alcatel-lucent.com> Mime-version: 1.0 X-OriginalArrivalTime: 16 Jul 2008 20:27:51.0248 (UTC) FILETIME=[6B53D500:01C8E782] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 fine. On 7/16/08 1:24 PM, "Vijay K. Gurbani" wrote: > Stanislav Shalunov wrote: >> Not sure what kind of resources, but yes, potentially. > > VoIP relays, CDN caches, etc. > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 16 13:36: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 6A8063A68DA; Wed, 16 Jul 2008 13:36: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 EC59E3A67A3 for ; Wed, 16 Jul 2008 13:36:54 -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.059, 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 KTF6hBePD7wu for ; Wed, 16 Jul 2008 13:36:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 222193A68DA for ; Wed, 16 Jul 2008 13:36:53 -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 m6GKbM46014792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 15:37:23 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6GKbIV5015410; Wed, 16 Jul 2008 15:37:18 -0500 (CDT) Message-ID: <487E5C02.1020204@alcatel-lucent.com> Date: Wed, 16 Jul 2008 15:37:22 -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: Laird Popkin References: <575703953.15381216239766411.JavaMail.root@dkny.pando.com> In-Reply-To: <575703953.15381216239766411.JavaMail.root@dkny.pando.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Laird Popkin wrote: > There are different entities in different p2p networks that might do > cache discovery. Laird: Thank you for this taxonomy. It is good. More inline. > The current caching vendors provide: - In-line 'cache discovery' > where the cache is in-line in traffic, caching data and responding to > requests rather than passing the requests for cached data on to > other peers. This is fragile and doesn't scale well Sure; this is what I call the "Squid" model. Besides the dis- advantages you mention above, content expiry (or staleness) is another disadvantage. > - DPI-based 'cache discovery', where a DPI box inspects the p2p > traffic and tells the p2p cache server about p2p tranfers, which the > cache server can join into. This is also fragile, involving protocol > reverse engineering. Sure. Agreed. > - Client-based cache discovery, where each p2p client on each > download start would perform (theoretically) one cache check for each > cache vendor, and use whatever comes back. This is complex and > inefficient. Yes. > - Server-based cache discovery, where each p2p network knows where > p2p cache servers are and tells appropriate peers to connect to the > caches. This is the most efficient approach, but requires ISPs to > inform p2p networks of cache locations and rules (e.g. IP prefixes) > for assigning users to caches, or equivalent lookups. This is essentially what people seem to be interested in. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 16 14:54: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 0B21F3A69E3; Wed, 16 Jul 2008 14:54: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 ACC963A68AB for ; Wed, 16 Jul 2008 14:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 WXlgr+vmS1At for ; Wed, 16 Jul 2008 14:54:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 3CBFC3A69E3 for ; Wed, 16 Jul 2008 14:54:16 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KJExM01GD-0004RZ; Wed, 16 Jul 2008 17:54:44 -0400 From: "Stas Khirman" To: "'Laird Popkin'" References: <003001c8e76d$54d02dc0$a00d11ac@jnpr.net> <1262349316.14801216232105465.JavaMail.root@dkny.pando.com> Date: Wed, 16 Jul 2008 14:54:39 -0700 Message-ID: <00ab01c8e78e$8e24d550$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjnb+zIa8jcm+KOTeyN+qPVhDHXoAAGjS/g In-Reply-To: <1262349316.14801216232105465.JavaMail.root@dkny.pando.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1/V2Koya7LcUvug5urBvEZ28j6/3GB6Jxwwxv0 70ASOv4b7YidUfiB+6Lfk7lUmpqhYkGTeH6bZY7f/dtCmBm5XI MGAD8Y4UI5qM2QNcTfIkQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Wednesday, July 16, 2008 11:15 AM > > I agree that keeping content identity out of cache location is a good idea. [Stas Khirman] Laird, It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. It will be very important to get confirmation/rejection of this assumption from ISP's representatives. > That being said, cache location doesn't need to be content-specific, > because one the p2p client connects to the caches, the caches can > determine what they do on a content-specific basis. So ALTO could (for > example) decide which cache servers to send to a user based on the user's > network location and protocol (e.g. Pando caches might run on different > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO can > return multiple cache servers (i.e. pools) the cache servers can manage > whether to cache specific content, or where to assign it, transparently to > ALTO, without ALTO having to know (for cache location) what content is > assigned where. This is good for the caches, as it gives them maximum > flexibility, without having to implement a complex state-change mechanism > between the cache servers and the ALTO server. > [Stas Khirman] Lets review a few usage cases to decide if ALTO can locate optimal cache without content identity. 1.) Cache implemented as a single virtual peer or as a set of peers with the same cached content. Certainly, no content knowledge needed to locate a most appropriate server. However, such architecture doesn't scale. 2.) Cache implemented as distributed set of servers where given content may be located in some subset of nodes. If ALTO return [ordered] list of all known servers, it will be up to client application to poll them to discover which one has appropriate content. Sometimes it will work, but with large list it takes significant time, especially harmful for applications that uses cache for bootstrapped playback. 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer to a master cache (cache director). Upon client connection, master redirects it to a slave cache that has appropriate content. However, "master" do not have enough knowledge to pick "ALTO optimized" slave server from set of appropriate ( I assume that popular content may be presented in multiple cache locations). Master can resolve this issue with a second ALTO lookup, but it not different from separated "discovery" and "optimization" calls as I suggested. 4.) Cache service implemented by third party CDN ( I assume you referred to this specific case). In this case decision what cache to be used is under control on another party (CDN owner) who may have "optimization" policy quite different then originating ISP (those diminishing value of ISP-own ALTO service). Probably it is extreme speculation, but in theory, Tier-1 ISP operated CDN may use "selection" policy that increase its own profit, but not decrease cost of originating ISP. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 17 00:13: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 6093728C145; Thu, 17 Jul 2008 00:13: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 7363028C176 for ; Thu, 17 Jul 2008 00:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=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 ThzO4+OcASKh for ; Thu, 17 Jul 2008 00:13:18 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id B239A28C141 for ; Thu, 17 Jul 2008 00:13:17 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m6H7DkZ2002819; Thu, 17 Jul 2008 09:13:47 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jul 2008 09:13:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 09:13:16 +0200 Message-ID: <00275A5B436CA441900CB10936742A38CE18FB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <575703953.15381216239766411.JavaMail.root@dkny.pando.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) Thread-Index: AcjngcYZ+N6IavmlQdSNWzdSNBTY+wAA2zVA References: <1791397884.15361216239445332.JavaMail.root@dkny.pando.com> <575703953.15381216239766411.JavaMail.root@dkny.pando.com> From: "PAPADIMITRIOU Dimitri" To: "Laird Popkin" , "GURBANI Vijay" X-OriginalArrivalTime: 17 Jul 2008 07:13:46.0951 (UTC) FILETIME=[A786CD70:01C8E7DC] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 indeed. you have the traffic-driven discovery (case 1 and 2) and the control-driven discovery (case 3 and 4). case 3 works w/exploration with all its drawbacks. case 2 in part. breaks the end-to-end communication by requiring intermediate nodes to inspect traffic (requestor being not aware of the modification of traffic data path/processing). i strongly oppose to any protocol development that would rely on such fwd'ing infrastructure change that are globally detrimental to the Internet accessibility, in part. those relying on DPI. there should be a clear statement on the charter that ALTO is not going to develop protocols, e.g. discovery, for infrastructures sabotaged by DPI. case 4 has real potential (Server-based cache discovery) note that the knowledge of cache location may be partial only for the system to work. -d. > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Laird Popkin > Sent: Wednesday, July 16, 2008 10:23 PM > To: GURBANI Vijay > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and > problem statement) > > There are different entities in different p2p networks that > might do cache discovery. > > The current caching vendors provide: > - In-line 'cache discovery' where the cache is in-line in > traffic, caching data and responding to requests rather than > passing the requests for cached data on to other peers. This > is fragile and doesn't scale well. > - DPI-based 'cache discovery', where a DPI box inspects the > p2p traffic and tells the p2p cache server about p2p > tranfers, which the cache server can join into. This is also > fragile, involving protocol reverse engineering. > - Client-based cache discovery, where each p2p client on each > download start would perform (theoretically) one cache check > for each cache vendor, and use whatever comes back. This is > complex and inefficient. > - Server-based cache discovery, where each p2p network knows > where p2p cache servers are and tells appropriate peers to > connect to the caches. This is the most efficient approach, > but requires ISPs to inform p2p networks of cache locations > and rules (e.g. IP prefixes) for assigning users to caches, > or equivalent lookups. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Vijay K. Gurbani" > To: "Stanislav Shalunov" > Cc: p2pi@ietf.org > Sent: Wednesday, July 16, 2008 4:08:56 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and > problem statement) > > Stanislav Shalunov wrote: > > On Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote: > >> Who do you see doing cache discovery? The ALTO server or the > >> individual peers? > > > > Peers mainly. The ALTO server might use these same means as a > > convenience, but one can think of it as being configured with this > > information. > > OK; good. So we have peers that mainly perform cache discovery > using some protocol (more on this below.) > > >> I believe that if cache discovery is moved to the realm of > >> the ALTO server, it becomes more of cache "dissemination" problem > >> than of cache "discovery." In other words, the ALTO server > >> will be pre-configured by the ISP -- or if it is not operated by > >> the ISP, will use other means -- to maintain a set of known caches. > >> It has been suggested that caches "register" to the ALTO server. > >> I think that this is probably not a good idea for a variety of > >> reasons. > > > > I don't see why we need to standardize how ALTO servers are > configured > > in this regard. > > You misunderstood. I was not saying that we standardize how ALTO > servers are configured (we should not go down that path, obviously.) > The point of my paragraph above was to determine if the ALTO server > is the only entity that does cache discovery, do we need to > specify a protocol at all? > > So, it looks like the following statements apply (for sake of > sanity, I will take a leap of faith and assume that we have an > actual ALTO server instead of representing it a URL of a BGP dump): > > Discovering caches and other resources: > > 1) Peers may discover caches using a protocol X. The protocol > X may be as simple as using well known DNS techniques to > bootstrap the discovery process (i.e., something akin to > DNS-SD, BEP-22, etc.) > > 2) The ALTO server may be asked by the peers to discover caches > using certain extensions to the ALTO protocol Y (Note: Y != X). > When so asked, the ALTO server can use protocol X to discover > those caches on behalf of the peers, and using additional > information provided by the peer. > > 3) The ALTO server may be asked by applications to discover > other resources using certain extensions to the ALTO protocol Y. > When so asked, the ALTO server can use protocol X to discover > such resources on behalf of the applications, and using additional > information provided by the application. > > Yes? > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 17 11:38: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 935DC3A6A1C; Thu, 17 Jul 2008 11:38: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 B2E1A3A6847 for ; Thu, 17 Jul 2008 11:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 dhdqzhxhkXih for ; Thu, 17 Jul 2008 11:38:35 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id A999E3A6A1C for ; Thu, 17 Jul 2008 11:38:35 -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 m6HId6YS015345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jul 2008 13:39:07 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6HId2Qr008980 for ; Thu, 17 Jul 2008 13:39:02 -0500 (CDT) Message-ID: <487F91CA.2090106@alcatel-lucent.com> Date: Thu, 17 Jul 2008 13:39:06 -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" References: <1791397884.15361216239445332.JavaMail.root@dkny.pando.com> <575703953.15381216239766411.JavaMail.root@dkny.pando.com> <00275A5B436CA441900CB10936742A38CE18FB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38CE18FB@FRVELSMBS22.ad2.ad.alcatel.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 PAPADIMITRIOU Dimitri wrote: > case 4 has real potential (Server-based cache discovery) note that the > knowledge of cache location may be partial only for the system to work. Dimitri: OK, thanks. The general consensus appears to that server- based cache discovery is probably the best way forward (again, taking a leap of faith and assume that we have an actual ALTO server instead of representing it a URL of a BGP dump.) We have allocated time to Reinaldo Penno for presentation on the caching discussion, including summarizing the consensus on the discussions we have had on the mailing list over the last couple of days. The updated agenda is available on the IETF website (please see http://www.ietf.org/proceedings/08jul/agenda/alto.html). Thank you all for a good discussion on this. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Thu Jul 17 19:35: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 D08DC3A6A40; Thu, 17 Jul 2008 19:35: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 6D47E3A6A40 for ; Thu, 17 Jul 2008 19:35:00 -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 TZJINYPCm5ZT for ; Thu, 17 Jul 2008 19:34: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 3BB4C3A6A39 for ; Thu, 17 Jul 2008 19:34:59 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8479207; Thu, 17 Jul 2008 22:35:08 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 22:35:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 22:34:48 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <00ab01c8e78e$8e24d550$a00d11ac@jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: Acjnb+zIa8jcm+KOTeyN+qPVhDHXoAAGjS/gADxkSiA= References: <003001c8e76d$54d02dc0$a00d11ac@jnpr.net><1262349316.14801216232105465.JavaMail.root@dkny.pando.com> <00ab01c8e78e$8e24d550$a00d11ac@jnpr.net> From: "Woundy, Richard" To: "Stas Khirman" , "Laird Popkin" X-OriginalArrivalTime: 18 Jul 2008 02:35:08.0008 (UTC) FILETIME=[E4AC4E80:01C8E87E] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. >It will be very important to get confirmation/rejection of this assumption from ISP's representatives. I've been thinking about this since yesterday, and I'm not really sure I agree with this statement. I definitely understand that there would likely be privacy concerns if ALTO mandated content identification in its messages. Content identities should be an optional parameter in the ALTO message exchange (if we can agree that it should be kept at all). But I would think that having the content identity could help an ALTO server make a better recommendation, at least for P2P caches. Consider the case when the ISP is operating an ALTO server as well as a P2P cache. If there isn't an issue of violating customer privacy, why would it be undesirable to reveal the content identity to the ALTO server, when it is necessary to reveal the content identity to the P2P caching server? In fact, the P2P caching server knows potentially more valuable information than the content identity. ALTO would only know about metadata for content, whereas the P2P cache would have a copy of the actual content. To illustrate, suppose that some content's metadata (e.g. torrent) indicates that the file is "Spiderman" and not much more. It is possible that the file represents a DVD rip of a Spiderman movie. It is equally possible that the file represents a digital home video of someone's child wearing a Spiderman costume for Halloween. Examining the actual content (as stored on the P2P cache) would help determine which scenario is true. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Stas Khirman Sent: Wednesday, July 16, 2008 5:55 PM To: 'Laird Popkin' Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Wednesday, July 16, 2008 11:15 AM > > I agree that keeping content identity out of cache location is a good idea. [Stas Khirman] Laird, It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. It will be very important to get confirmation/rejection of this assumption from ISP's representatives. > That being said, cache location doesn't need to be content-specific, > because one the p2p client connects to the caches, the caches can > determine what they do on a content-specific basis. So ALTO could (for > example) decide which cache servers to send to a user based on the user's > network location and protocol (e.g. Pando caches might run on different > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO can > return multiple cache servers (i.e. pools) the cache servers can manage > whether to cache specific content, or where to assign it, transparently to > ALTO, without ALTO having to know (for cache location) what content is > assigned where. This is good for the caches, as it gives them maximum > flexibility, without having to implement a complex state-change mechanism > between the cache servers and the ALTO server. > [Stas Khirman] Lets review a few usage cases to decide if ALTO can locate optimal cache without content identity. 1.) Cache implemented as a single virtual peer or as a set of peers with the same cached content. Certainly, no content knowledge needed to locate a most appropriate server. However, such architecture doesn't scale. 2.) Cache implemented as distributed set of servers where given content may be located in some subset of nodes. If ALTO return [ordered] list of all known servers, it will be up to client application to poll them to discover which one has appropriate content. Sometimes it will work, but with large list it takes significant time, especially harmful for applications that uses cache for bootstrapped playback. 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer to a master cache (cache director). Upon client connection, master redirects it to a slave cache that has appropriate content. However, "master" do not have enough knowledge to pick "ALTO optimized" slave server from set of appropriate ( I assume that popular content may be presented in multiple cache locations). Master can resolve this issue with a second ALTO lookup, but it not different from separated "discovery" and "optimization" calls as I suggested. 4.) Cache service implemented by third party CDN ( I assume you referred to this specific case). In this case decision what cache to be used is under control on another party (CDN owner) who may have "optimization" policy quite different then originating ISP (those diminishing value of ISP-own ALTO service). Probably it is extreme speculation, but in theory, Tier-1 ISP operated CDN may use "selection" policy that increase its own profit, but not decrease cost of originating ISP. _______________________________________________ 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 Jul 17 20:28: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 3D6DA3A6A48; Thu, 17 Jul 2008 20:28: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 4A2BF3A6A48 for ; Thu, 17 Jul 2008 20:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_33=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 Jx6ycGlAJg6a for ; Thu, 17 Jul 2008 20:28:23 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id C1B1E3A6A38 for ; Thu, 17 Jul 2008 20:28:22 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8480658; Thu, 17 Jul 2008 23:28:30 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 23:28:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 23:28:11 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C16C@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <00275A5B436CA441900CB10936742A38CE18FB@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) Thread-Index: AcjngcYZ+N6IavmlQdSNWzdSNBTY+wAA2zVAAD+G/FA= References: <1791397884.15361216239445332.JavaMail.root@dkny.pando.com><575703953.15381216239766411.JavaMail.root@dkny.pando.com> <00275A5B436CA441900CB10936742A38CE18FB@FRVELSMBS22.ad2.ad.alcatel.com> From: "Woundy, Richard" To: "PAPADIMITRIOU Dimitri" , "Laird Popkin" , "GURBANI Vijay" X-OriginalArrivalTime: 18 Jul 2008 03:28:30.0663 (UTC) FILETIME=[599AAD70:01C8E886] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) 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 Here are a few more thoughts on P2P caching. >case 3 [Client-based cache discovery] works w/exploration with all its drawbacks. Here's a thought: could it be possible for the client to learn that content may be cached (or is cachable) by an entity (e.g. his ISP) via content metadata? Then the client could learn the actual P2P cache location using an ALTO request, say. >there should be a clear statement on the charter that ALTO is not going to develop protocols, e.g. discovery, for infrastructures sabotaged by DPI. Personally, I would agree that ALTO should develop P2P cache discovery mechanisms that do NOT rely on DPI diversion of traffic. It would be much more elegant for a peer and/or tracker to consciously choose to leverage a P2P cache, than for a middlebox to make that choice. (Offline, some folks have pointed out that the DPI could divert P2P traffic on a customer opt-in basis. However, it would seem to be very difficult for the customer to opt-in for diversion for some content downloads, but not for others, but I digress.) But I feel obliged to note that the use of DPI diversion for P2P traffic is common in vendor pitches for P2P caching products, and I suspect that a number of ISPs (emphatically NOT Comcast) have already deployed P2P caching in conjunction with DPI. And of course the core reason is that there is little to no support for cache discovery in existing clients and trackers -- which hopefully will change soon. I thought I should point this out before we agree to "outlaw" the DPI approach. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of PAPADIMITRIOU Dimitri Sent: Thursday, July 17, 2008 3:13 AM To: Laird Popkin; GURBANI Vijay Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement) indeed. you have the traffic-driven discovery (case 1 and 2) and the control-driven discovery (case 3 and 4). case 3 works w/exploration with all its drawbacks. case 2 in part. breaks the end-to-end communication by requiring intermediate nodes to inspect traffic (requestor being not aware of the modification of traffic data path/processing). i strongly oppose to any protocol development that would rely on such fwd'ing infrastructure change that are globally detrimental to the Internet accessibility, in part. those relying on DPI. there should be a clear statement on the charter that ALTO is not going to develop protocols, e.g. discovery, for infrastructures sabotaged by DPI. case 4 has real potential (Server-based cache discovery) note that the knowledge of cache location may be partial only for the system to work. -d. > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Laird Popkin > Sent: Wednesday, July 16, 2008 10:23 PM > To: GURBANI Vijay > Cc: p2pi@ietf.org > Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and > problem statement) > > There are different entities in different p2p networks that > might do cache discovery. > > The current caching vendors provide: > - In-line 'cache discovery' where the cache is in-line in > traffic, caching data and responding to requests rather than > passing the requests for cached data on to other peers. This > is fragile and doesn't scale well. > - DPI-based 'cache discovery', where a DPI box inspects the > p2p traffic and tells the p2p cache server about p2p > tranfers, which the cache server can join into. This is also > fragile, involving protocol reverse engineering. > - Client-based cache discovery, where each p2p client on each > download start would perform (theoretically) one cache check > for each cache vendor, and use whatever comes back. This is > complex and inefficient. > - Server-based cache discovery, where each p2p network knows > where p2p cache servers are and tells appropriate peers to > connect to the caches. This is the most efficient approach, > but requires ISPs to inform p2p networks of cache locations > and rules (e.g. IP prefixes) for assigning users to caches, > or equivalent lookups. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Vijay K. Gurbani" > To: "Stanislav Shalunov" > Cc: p2pi@ietf.org > Sent: Wednesday, July 16, 2008 4:08:56 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and > problem statement) > > Stanislav Shalunov wrote: > > On Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote: > >> Who do you see doing cache discovery? The ALTO server or the > >> individual peers? > > > > Peers mainly. The ALTO server might use these same means as a > > convenience, but one can think of it as being configured with this > > information. > > OK; good. So we have peers that mainly perform cache discovery > using some protocol (more on this below.) > > >> I believe that if cache discovery is moved to the realm of > >> the ALTO server, it becomes more of cache "dissemination" problem > >> than of cache "discovery." In other words, the ALTO server > >> will be pre-configured by the ISP -- or if it is not operated by > >> the ISP, will use other means -- to maintain a set of known caches. > >> It has been suggested that caches "register" to the ALTO server. > >> I think that this is probably not a good idea for a variety of > >> reasons. > > > > I don't see why we need to standardize how ALTO servers are > configured > > in this regard. > > You misunderstood. I was not saying that we standardize how ALTO > servers are configured (we should not go down that path, obviously.) > The point of my paragraph above was to determine if the ALTO server > is the only entity that does cache discovery, do we need to > specify a protocol at all? > > So, it looks like the following statements apply (for sake of > sanity, I will take a leap of faith and assume that we have an > actual ALTO server instead of representing it a URL of a BGP dump): > > Discovering caches and other resources: > > 1) Peers may discover caches using a protocol X. The protocol > X may be as simple as using well known DNS techniques to > bootstrap the discovery process (i.e., something akin to > DNS-SD, BEP-22, etc.) > > 2) The ALTO server may be asked by the peers to discover caches > using certain extensions to the ALTO protocol Y (Note: Y != X). > When so asked, the ALTO server can use protocol X to discover > those caches on behalf of the peers, and using additional > information provided by the peer. > > 3) The ALTO server may be asked by applications to discover > other resources using certain extensions to the ALTO protocol Y. > When so asked, the ALTO server can use protocol X to discover > such resources on behalf of the applications, and using additional > information provided by the application. > > Yes? > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 > _______________________________________________ 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 Jul 18 03:57: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 4CDEA3A69D7; Fri, 18 Jul 2008 03:57: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 365703A693E for ; Fri, 18 Jul 2008 03:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 bnrqMRRNn-XX for ; Fri, 18 Jul 2008 03:57:03 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id E05A33A69C2 for ; Fri, 18 Jul 2008 03:57:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 7C3D5E10ACE; Fri, 18 Jul 2008 06:57:29 -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 oAYxikyhxHsV; Fri, 18 Jul 2008 06:57:17 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 2939EE10ABD; Fri, 18 Jul 2008 06:57:17 -0400 (EDT) Date: Fri, 18 Jul 2008 06:57:17 -0400 (EDT) From: Laird Popkin To: Richard Woundy Message-ID: <1117197229.19991216378637139.JavaMail.root@dkny.pando.com> In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Richard - as long as content ID's are optional and abstracted (e.g. content ID's are not Torrent ID's) I don't think there's a privacy issue. There are a number of use cases where metadata related to the content could be useful in allowing the ALTO server to make decisions. For example, an ISP might want to implement policies in their ALTO server such as: - Don't cache consumer generated content (requires being able to differentiate between CGC and commercial content). - Provide different guidance to different applications (requires knowledge of p2p application). - Provide guidance based on distribution of that content (requires ID of that specific content). It's a good point that once content is cached the ISP knows a lot about the content and its distribution. In particular, since it's participating in the p2p network it knows the IP addresses of people exchanging the content, whatever metadata is exposed about the content in the protocol (e.g. size, number of files, names). And for p2p networks that don't secure content on caches (Pando does, but some others do not) the ISP has the content on the cache server and can inspect it directly. But this is (IMO, IANAL) similar to the case of an HTTP cache or an email server - the ISP is providing a service, and privacy of use of that service is protected by policy, not by technology. Given all of that, ALTO can certainly be applied to content that isn't cached, and it should preserve privacy for that content. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Woundy" To: "Stas Khirman" , "Laird Popkin" Cc: p2pi@ietf.org Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement >It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. >It will be very important to get confirmation/rejection of this assumption from ISP's representatives. I've been thinking about this since yesterday, and I'm not really sure I agree with this statement. I definitely understand that there would likely be privacy concerns if ALTO mandated content identification in its messages. Content identities should be an optional parameter in the ALTO message exchange (if we can agree that it should be kept at all). But I would think that having the content identity could help an ALTO server make a better recommendation, at least for P2P caches. Consider the case when the ISP is operating an ALTO server as well as a P2P cache. If there isn't an issue of violating customer privacy, why would it be undesirable to reveal the content identity to the ALTO server, when it is necessary to reveal the content identity to the P2P caching server? In fact, the P2P caching server knows potentially more valuable information than the content identity. ALTO would only know about metadata for content, whereas the P2P cache would have a copy of the actual content. To illustrate, suppose that some content's metadata (e.g. torrent) indicates that the file is "Spiderman" and not much more. It is possible that the file represents a DVD rip of a Spiderman movie. It is equally possible that the file represents a digital home video of someone's child wearing a Spiderman costume for Halloween. Examining the actual content (as stored on the P2P cache) would help determine which scenario is true. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Stas Khirman Sent: Wednesday, July 16, 2008 5:55 PM To: 'Laird Popkin' Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Wednesday, July 16, 2008 11:15 AM > > I agree that keeping content identity out of cache location is a good idea. [Stas Khirman] Laird, It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. It will be very important to get confirmation/rejection of this assumption from ISP's representatives. > That being said, cache location doesn't need to be content-specific, > because one the p2p client connects to the caches, the caches can > determine what they do on a content-specific basis. So ALTO could (for > example) decide which cache servers to send to a user based on the user's > network location and protocol (e.g. Pando caches might run on different > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO can > return multiple cache servers (i.e. pools) the cache servers can manage > whether to cache specific content, or where to assign it, transparently to > ALTO, without ALTO having to know (for cache location) what content is > assigned where. This is good for the caches, as it gives them maximum > flexibility, without having to implement a complex state-change mechanism > between the cache servers and the ALTO server. > [Stas Khirman] Lets review a few usage cases to decide if ALTO can locate optimal cache without content identity. 1.) Cache implemented as a single virtual peer or as a set of peers with the same cached content. Certainly, no content knowledge needed to locate a most appropriate server. However, such architecture doesn't scale. 2.) Cache implemented as distributed set of servers where given content may be located in some subset of nodes. If ALTO return [ordered] list of all known servers, it will be up to client application to poll them to discover which one has appropriate content. Sometimes it will work, but with large list it takes significant time, especially harmful for applications that uses cache for bootstrapped playback. 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer to a master cache (cache director). Upon client connection, master redirects it to a slave cache that has appropriate content. However, "master" do not have enough knowledge to pick "ALTO optimized" slave server from set of appropriate ( I assume that popular content may be presented in multiple cache locations). Master can resolve this issue with a second ALTO lookup, but it not different from separated "discovery" and "optimization" calls as I suggested. 4.) Cache service implemented by third party CDN ( I assume you referred to this specific case). In this case decision what cache to be used is under control on another party (CDN owner) who may have "optimization" policy quite different then originating ISP (those diminishing value of ISP-own ALTO service). Probably it is extreme speculation, but in theory, Tier-1 ISP operated CDN may use "selection" policy that increase its own profit, but not decrease cost of originating ISP. _______________________________________________ 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 Jul 18 04:00: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 0680E3A693E; Fri, 18 Jul 2008 04:00: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 C67763A68DC for ; Fri, 18 Jul 2008 04:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.030, 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 CRRRbwP17r2C for ; Fri, 18 Jul 2008 04:00:57 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C44063A693E for ; Fri, 18 Jul 2008 04:00:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 07D5BE10ABD; Fri, 18 Jul 2008 07:01:30 -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 hhcv8-yrb3aq; Fri, 18 Jul 2008 07:01:23 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id C6651E10AD5; Fri, 18 Jul 2008 07:01:23 -0400 (EDT) Date: Fri, 18 Jul 2008 07:01:23 -0400 (EDT) From: Laird Popkin To: stefano previdi Message-ID: <1615221227.20021216378883787.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 We should minimize the amount of caching metadata and logic are exposed in ALTO. As long as ALTO can introduce the p2p cache server to the p2p clients, and tell them that they are caches rather than normal peers, the rest (specific content assignment to specific caches, preferential use of caches over normal peers, etc.) can be negotiated between the p2p clients and the caches using the p2p protocols, without ALTO's involvement. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" To: "Laird Popkin" , "Stanislav Shalunov" Cc: p2pi@ietf.org, "Enrico Marocco" Sent: Wednesday, July 16, 2008 10:08:26 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Charter and problem statement > From: Laird Popkin > > Stefano, > > Yes, I am suggesting that ALTO should make cache entities explicit to ALTO > clients. And the means of doing so should be standardized so that there is > interoperability. It could be expressed in the ALTO specification itself, or > via the extension mechanism, of course. now we'll have to explore what kind of cache-specific bits we want to standardize in the ALTO protocol... I have the feeling is going to be quite vast... My point was to keep the ALTO protocol agnostic enough in order to provide a generic protocol between ALTO providers/consumers. Having some bits in the request/response related to a cache entity/object, it's fine but I'm not sure how far we can go without significantly impacting the protocol engine. s. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Stanislav Shalunov" > To: "stefano previdi" , "Laird Popkin" , > "Enrico Marocco" > Cc: p2pi@ietf.org > Sent: Tuesday, July 15, 2008 7:36:34 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > The information conveyed to the client needs to enable the client to find a > nearby cache (or three). Whether this information blob can be called opaque > then is a semantic question, but to me, calling it opaque is misleading. > > Anything opaque is transparent to something higher up the stack. For example, > should we use DNS to find the cache, the information is opaque on DNS layer. > It is no longer opaque when it is used. > > If it is to allow any client to find the cache, it's not opaque to ALTO. > > > > -----Original Message----- > From: "stefano previdi" > To: "Laird Popkin" ; "Enrico Marocco" > > Cc: p2pi@ietf.org > Sent: 7/15/08 6:41 AM > Subject: Re: [p2pi] Charter and problem statement > > Laird, > > do you suggest to make the cache entity explicit in the ALTO protocol > semantic ? > > Or is it just part of the opaque protocol data the algorithm (not under > standardization at this point) will work with ? > > I'd vote for the latter... > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 18 15:42: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 E4F9B3A6877; Fri, 18 Jul 2008 15:42: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 2FDEF3A67E4 for ; Fri, 18 Jul 2008 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ePBipmKap8VA for ; Fri, 18 Jul 2008 15:42:39 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id B036C3A6877 for ; Fri, 18 Jul 2008 15:42:38 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48321381; Fri, 18 Jul 2008 18:42:56 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 18:42:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 18:42:14 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C1A2@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <1117197229.19991216378637139.JavaMail.root@dkny.pando.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjoxRvXu93mmbCaSZaSbZuhTY1XNgAYaFNA References: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com> <1117197229.19991216378637139.JavaMail.root@dkny.pando.com> From: "Woundy, Richard" To: "Laird Popkin" X-OriginalArrivalTime: 18 Jul 2008 22:42:55.0601 (UTC) FILETIME=[9EB97610:01C8E927] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Sounds reasonable to me -- thanks for listening, Laird. :) Sometime in the future, we'll have to refine the list of potential ISP policies for the ALTO server. For example, there may be some user generated content that is cacheable by the ISP and other UGC that is not. -- Rich -----Original Message----- From: Laird Popkin [mailto:laird@pando.com] Sent: Friday, July 18, 2008 6:57 AM To: Woundy, Richard Cc: p2pi@ietf.org; Stas Khirman Subject: Re: [p2pi] Charter and problem statement I agree with Richard - as long as content ID's are optional and abstracted (e.g. content ID's are not Torrent ID's) I don't think there's a privacy issue. There are a number of use cases where metadata related to the content could be useful in allowing the ALTO server to make decisions. For example, an ISP might want to implement policies in their ALTO server such as: - Don't cache consumer generated content (requires being able to differentiate between CGC and commercial content). - Provide different guidance to different applications (requires knowledge of p2p application). - Provide guidance based on distribution of that content (requires ID of that specific content). It's a good point that once content is cached the ISP knows a lot about the content and its distribution. In particular, since it's participating in the p2p network it knows the IP addresses of people exchanging the content, whatever metadata is exposed about the content in the protocol (e.g. size, number of files, names). And for p2p networks that don't secure content on caches (Pando does, but some others do not) the ISP has the content on the cache server and can inspect it directly. But this is (IMO, IANAL) similar to the case of an HTTP cache or an email server - the ISP is providing a service, and privacy of use of that service is protected by policy, not by technology. Given all of that, ALTO can certainly be applied to content that isn't cached, and it should preserve privacy for that content. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Woundy" To: "Stas Khirman" , "Laird Popkin" Cc: p2pi@ietf.org Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement >It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. >It will be very important to get confirmation/rejection of this assumption from ISP's representatives. I've been thinking about this since yesterday, and I'm not really sure I agree with this statement. I definitely understand that there would likely be privacy concerns if ALTO mandated content identification in its messages. Content identities should be an optional parameter in the ALTO message exchange (if we can agree that it should be kept at all). But I would think that having the content identity could help an ALTO server make a better recommendation, at least for P2P caches. Consider the case when the ISP is operating an ALTO server as well as a P2P cache. If there isn't an issue of violating customer privacy, why would it be undesirable to reveal the content identity to the ALTO server, when it is necessary to reveal the content identity to the P2P caching server? In fact, the P2P caching server knows potentially more valuable information than the content identity. ALTO would only know about metadata for content, whereas the P2P cache would have a copy of the actual content. To illustrate, suppose that some content's metadata (e.g. torrent) indicates that the file is "Spiderman" and not much more. It is possible that the file represents a DVD rip of a Spiderman movie. It is equally possible that the file represents a digital home video of someone's child wearing a Spiderman costume for Halloween. Examining the actual content (as stored on the P2P cache) would help determine which scenario is true. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Stas Khirman Sent: Wednesday, July 16, 2008 5:55 PM To: 'Laird Popkin' Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Wednesday, July 16, 2008 11:15 AM > > I agree that keeping content identity out of cache location is a good idea. [Stas Khirman] Laird, It seems that we agree on the key point - content identity in ALTO ["peer selection"] request will be harmful. It will be very important to get confirmation/rejection of this assumption from ISP's representatives. > That being said, cache location doesn't need to be content-specific, > because one the p2p client connects to the caches, the caches can > determine what they do on a content-specific basis. So ALTO could (for > example) decide which cache servers to send to a user based on the user's > network location and protocol (e.g. Pando caches might run on different > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO can > return multiple cache servers (i.e. pools) the cache servers can manage > whether to cache specific content, or where to assign it, transparently to > ALTO, without ALTO having to know (for cache location) what content is > assigned where. This is good for the caches, as it gives them maximum > flexibility, without having to implement a complex state-change mechanism > between the cache servers and the ALTO server. > [Stas Khirman] Lets review a few usage cases to decide if ALTO can locate optimal cache without content identity. 1.) Cache implemented as a single virtual peer or as a set of peers with the same cached content. Certainly, no content knowledge needed to locate a most appropriate server. However, such architecture doesn't scale. 2.) Cache implemented as distributed set of servers where given content may be located in some subset of nodes. If ALTO return [ordered] list of all known servers, it will be up to client application to poll them to discover which one has appropriate content. Sometimes it will work, but with large list it takes significant time, especially harmful for applications that uses cache for bootstrapped playback. 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer to a master cache (cache director). Upon client connection, master redirects it to a slave cache that has appropriate content. However, "master" do not have enough knowledge to pick "ALTO optimized" slave server from set of appropriate ( I assume that popular content may be presented in multiple cache locations). Master can resolve this issue with a second ALTO lookup, but it not different from separated "discovery" and "optimization" calls as I suggested. 4.) Cache service implemented by third party CDN ( I assume you referred to this specific case). In this case decision what cache to be used is under control on another party (CDN owner) who may have "optimization" policy quite different then originating ISP (those diminishing value of ISP-own ALTO service). Probably it is extreme speculation, but in theory, Tier-1 ISP operated CDN may use "selection" policy that increase its own profit, but not decrease cost of originating ISP. _______________________________________________ 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 Jul 18 19:34:23 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 183E93A688E; Fri, 18 Jul 2008 19:34: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 548BF3A688E for ; Fri, 18 Jul 2008 19:34: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 4TvpzMPOTNXN for ; Fri, 18 Jul 2008 19:34:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 8AD503A680E for ; Fri, 18 Jul 2008 19:34:21 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KK2HW1dXq-0005R9; Fri, 18 Jul 2008 22:34:55 -0400 From: "Stas Khirman" To: "'Laird Popkin'" , "'stefano previdi'" References: <1615221227.20021216378883787.JavaMail.root@dkny.pando.com> Date: Fri, 18 Jul 2008 19:34:40 -0700 Message-ID: <000001c8e948$071e4300$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjoxaLxSiIw7F+GQN+U0YETZT1SigAgUfYg In-Reply-To: <1615221227.20021216378883787.JavaMail.root@dkny.pando.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX193cK1cPFnAjBhB0xIH24YJ2aFbriX9iAbdOSD Gq+Uylv9GMw05m09VgucTDi6mX6v4O5hcLBT3924xorlAyKXrv OUSqKzDaRNK/lGPP03OLQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Laird Popkin > Sent: Friday, July 18, 2008 4:01 AM > To: stefano previdi > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > We should minimize the amount of caching metadata and logic are exposed in > ALTO. As long as ALTO can introduce the p2p cache server to the p2p > clients, and tell them that they are caches rather than normal peers, the > rest (specific content assignment to specific caches, preferential use of > caches over normal peers, etc.) can be negotiated between the p2p clients > and the caches using the p2p protocols, without ALTO's involvement. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > [Stas Khirman] Sorry, does " specific content assignment to specific caches... can be negotiated between the p2p clients and the caches ... without ALTO's involvement " mean that what p2p client will negotiate what specific cache server to use without ALTO assistance/recommendation ? In this case, selected cache may not be an optimal (closes, cheapest, etc ) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jul 18 22:12: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 CE3E13A6996; Fri, 18 Jul 2008 22:12: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 84A403A6996 for ; Fri, 18 Jul 2008 22:12:50 -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 NDtBtQG4gIYt for ; Fri, 18 Jul 2008 22:12:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DFB673A683A for ; Fri, 18 Jul 2008 22:12:48 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KK4kt40XW-0004hm; Sat, 19 Jul 2008 01:13:22 -0400 From: "Stas Khirman" To: "'Laird Popkin'" , "'Richard Woundy'" References: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com> <1117197229.19991216378637139.JavaMail.root@dkny.pando.com> Date: Fri, 18 Jul 2008 22:13:15 -0700 Message-ID: <001201c8e95e$2a565e00$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjoxRsLo/toTwlMTJ6LlgTQJ9Z5vAAZu75w In-Reply-To: <1117197229.19991216378637139.JavaMail.root@dkny.pando.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1/Tg4sNqijot89oON5lF9FUlki2z9hLnNOHvtI tD378JmQCrTedJCql2RiA+6WSx4MuWNU3y8+RGHnPbfuHuEOMY tdwHB7U3l26SeDbxhCMgw== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Friday, July 18, 2008 3:57 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > I agree with Richard - as long as content ID's are optional and > abstracted (e.g. content ID's are not Torrent ID's) I don't think there's > a privacy issue. [Stas Khirman] Laird and Richard, Thank you for clarifying this issue - I convinced that content id does not create additional problems in use case when ISP is using cache servers. Indeed, if any kind of caching implemented on ISP level, they already have privacy/DMCA questions resolved somehow. It also true for use case of P2P CDN that use P4P architecture (ALTO server polled by pTracker ). In those use cases, including content id in ALTO request makes no harm, and can be quite useful for cache location and [probably] other goals (differentiated QoS ?) However, I still worry about use case that seems to be more "popular" ( in term on number of users) : due variety of [legal] reasons, ISP does not install caching at all, but want to use ALTO-powered transport optimization for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P clients adopted ALTO). In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. And it is not just hypothetical speculation - see for example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . Probably, "optionally" can be achieved if during ALTO server discovery stage ( DNS?) client receives some kind of "configuration" flag and will be mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have no idea, but assume that the better "DMCA-proof" solution is to separate "content-sensitive" functionalities (like cache discovery) from "content agnostic" ones. > > There are a number of use cases where metadata related to the content > could be useful in allowing the ALTO server to make decisions. For example, > an ISP might want to implement policies in their ALTO server such as: > > - Don't cache consumer generated content (requires being able to > differentiate between CGC and commercial content). > - Provide different guidance to different applications (requires knowledge > of p2p application). > - Provide guidance based on distribution of that content (requires ID of > that specific content). > > It's a good point that once content is cached the ISP knows a lot about > the content and its distribution. In particular, since it's participating > in the p2p network it knows the IP addresses of people exchanging the > content, whatever metadata is exposed about the content in the protocol > (e.g. size, number of files, names). And for p2p networks that don't > secure content on caches (Pando does, but some others do not) the ISP has > the content on the cache server and can inspect it directly. But this is > (IMO, IANAL) similar to the case of an HTTP cache or an email server - the > ISP is providing a service, and privacy of use of that service is > protected by policy, not by technology. > > Given all of that, ALTO can certainly be applied to content that isn't > cached, and it should preserve privacy for that content. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > >It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > I've been thinking about this since yesterday, and I'm not really sure I > agree with this statement. > > I definitely understand that there would likely be privacy concerns if > ALTO mandated content identification in its messages. Content identities > should be an optional parameter in the ALTO message exchange (if we can > agree that it should be kept at all). > > But I would think that having the content identity could help an ALTO > server make a better recommendation, at least for P2P caches. > > Consider the case when the ISP is operating an ALTO server as well as a > P2P cache. If there isn't an issue of violating customer privacy, why > would it be undesirable to reveal the content identity to the ALTO > server, when it is necessary to reveal the content identity to the P2P > caching server? > > In fact, the P2P caching server knows potentially more valuable > information than the content identity. ALTO would only know about > metadata for content, whereas the P2P cache would have a copy of the > actual content. > > To illustrate, suppose that some content's metadata (e.g. torrent) > indicates that the file is "Spiderman" and not much more. It is possible > that the file represents a DVD rip of a Spiderman movie. It is equally > possible that the file represents a digital home video of someone's > child wearing a Spiderman costume for Halloween. Examining the actual > content (as stored on the P2P cache) would help determine which scenario > is true. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stas Khirman > Sent: Wednesday, July 16, 2008 5:55 PM > To: 'Laird Popkin' > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > I agree that keeping content identity out of cache location is a good > idea. > > [Stas Khirman] > Laird, > > It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > > > That being said, cache location doesn't need to be content-specific, > > because one the p2p client connects to the caches, the caches can > > determine what they do on a content-specific basis. So ALTO could (for > > example) decide which cache servers to send to a user based on the > user's > > network location and protocol (e.g. Pando caches might run on > different > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > can > > return multiple cache servers (i.e. pools) the cache servers can > manage > > whether to cache specific content, or where to assign it, > transparently to > > ALTO, without ALTO having to know (for cache location) what content is > > assigned where. This is good for the caches, as it gives them maximum > > flexibility, without having to implement a complex state-change > mechanism > > between the cache servers and the ALTO server. > > > [Stas Khirman] > Lets review a few usage cases to decide if ALTO can locate optimal cache > without content identity. > > 1.) Cache implemented as a single virtual peer or as a set of peers with > the > same cached content. Certainly, no content knowledge needed to locate a > most > appropriate server. However, such architecture doesn't scale. > > 2.) Cache implemented as distributed set of servers where given content > may > be located in some subset of nodes. If ALTO return [ordered] list of all > known servers, it will be up to client application to poll them to > discover > which one has appropriate content. Sometimes it will work, but with > large > list it takes significant time, especially harmful for applications that > uses cache for bootstrapped playback. > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > to a > master cache (cache director). Upon client connection, master redirects > it > to a slave cache that has appropriate content. However, "master" do not > have > enough knowledge to pick "ALTO optimized" slave server from set of > appropriate ( I assume that popular content may be presented in multiple > cache locations). Master can resolve this issue with a second ALTO > lookup, > but it not different from separated "discovery" and "optimization" calls > as > I suggested. > > 4.) Cache service implemented by third party CDN ( I assume you referred > to > this specific case). In this case decision what cache to be used is > under > control on another party (CDN owner) who may have "optimization" policy > quite different then originating ISP (those diminishing value of ISP-own > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > ISP > operated CDN may use "selection" policy that increase its own profit, > but > not decrease cost of originating ISP. > > > > > _______________________________________________ > 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 Sat Jul 19 06:04: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 3EDF13A6859; Sat, 19 Jul 2008 06:04: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 7B3F03A6859 for ; Sat, 19 Jul 2008 06:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Vf2Wftpii+4J for ; Sat, 19 Jul 2008 06:04:15 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2481B3A67E7 for ; Sat, 19 Jul 2008 06:04:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D726AE10AD1; Sat, 19 Jul 2008 09:04:42 -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 P+G-kiuzrSns; Sat, 19 Jul 2008 09:04:21 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 7CFF9E10AD0; Sat, 19 Jul 2008 09:04:21 -0400 (EDT) Date: Sat, 19 Jul 2008 09:04:21 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <797668489.29111216472661464.JavaMail.root@dkny.pando.com> In-Reply-To: <001201c8e95e$2a565e00$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: Richard Woundy , p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Note that content optimization can also (potentially) be content-specific. For example, in P4P, the guidance to the p2p networks can be 'tuned' to reflect the specific distribution of content. So for both peer selection optimization and for cache location there are use cases that could utilize some form of content identifier. Perhaps the way to phrase this is that the ALTO server MUST support operation with no content identifiers, but ALTO clients MAY send content identifiers? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Laird Popkin" , "Richard Woundy" Cc: p2pi@ietf.org Sent: Saturday, July 19, 2008 1:13:15 AM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Friday, July 18, 2008 3:57 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > I agree with Richard - as long as content ID's are optional and > abstracted (e.g. content ID's are not Torrent ID's) I don't think there's > a privacy issue. [Stas Khirman] Laird and Richard, Thank you for clarifying this issue - I convinced that content id does not create additional problems in use case when ISP is using cache servers. Indeed, if any kind of caching implemented on ISP level, they already have privacy/DMCA questions resolved somehow. It also true for use case of P2P CDN that use P4P architecture (ALTO server polled by pTracker ). In those use cases, including content id in ALTO request makes no harm, and can be quite useful for cache location and [probably] other goals (differentiated QoS ?) However, I still worry about use case that seems to be more "popular" ( in term on number of users) : due variety of [legal] reasons, ISP does not install caching at all, but want to use ALTO-powered transport optimization for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P clients adopted ALTO). In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. And it is not just hypothetical speculation - see for example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . Probably, "optionally" can be achieved if during ALTO server discovery stage ( DNS?) client receives some kind of "configuration" flag and will be mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have no idea, but assume that the better "DMCA-proof" solution is to separate "content-sensitive" functionalities (like cache discovery) from "content agnostic" ones. > > There are a number of use cases where metadata related to the content > could be useful in allowing the ALTO server to make decisions. For example, > an ISP might want to implement policies in their ALTO server such as: > > - Don't cache consumer generated content (requires being able to > differentiate between CGC and commercial content). > - Provide different guidance to different applications (requires knowledge > of p2p application). > - Provide guidance based on distribution of that content (requires ID of > that specific content). > > It's a good point that once content is cached the ISP knows a lot about > the content and its distribution. In particular, since it's participating > in the p2p network it knows the IP addresses of people exchanging the > content, whatever metadata is exposed about the content in the protocol > (e.g. size, number of files, names). And for p2p networks that don't > secure content on caches (Pando does, but some others do not) the ISP has > the content on the cache server and can inspect it directly. But this is > (IMO, IANAL) similar to the case of an HTTP cache or an email server - the > ISP is providing a service, and privacy of use of that service is > protected by policy, not by technology. > > Given all of that, ALTO can certainly be applied to content that isn't > cached, and it should preserve privacy for that content. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > >It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > I've been thinking about this since yesterday, and I'm not really sure I > agree with this statement. > > I definitely understand that there would likely be privacy concerns if > ALTO mandated content identification in its messages. Content identities > should be an optional parameter in the ALTO message exchange (if we can > agree that it should be kept at all). > > But I would think that having the content identity could help an ALTO > server make a better recommendation, at least for P2P caches. > > Consider the case when the ISP is operating an ALTO server as well as a > P2P cache. If there isn't an issue of violating customer privacy, why > would it be undesirable to reveal the content identity to the ALTO > server, when it is necessary to reveal the content identity to the P2P > caching server? > > In fact, the P2P caching server knows potentially more valuable > information than the content identity. ALTO would only know about > metadata for content, whereas the P2P cache would have a copy of the > actual content. > > To illustrate, suppose that some content's metadata (e.g. torrent) > indicates that the file is "Spiderman" and not much more. It is possible > that the file represents a DVD rip of a Spiderman movie. It is equally > possible that the file represents a digital home video of someone's > child wearing a Spiderman costume for Halloween. Examining the actual > content (as stored on the P2P cache) would help determine which scenario > is true. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stas Khirman > Sent: Wednesday, July 16, 2008 5:55 PM > To: 'Laird Popkin' > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > I agree that keeping content identity out of cache location is a good > idea. > > [Stas Khirman] > Laird, > > It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > > > That being said, cache location doesn't need to be content-specific, > > because one the p2p client connects to the caches, the caches can > > determine what they do on a content-specific basis. So ALTO could (for > > example) decide which cache servers to send to a user based on the > user's > > network location and protocol (e.g. Pando caches might run on > different > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > can > > return multiple cache servers (i.e. pools) the cache servers can > manage > > whether to cache specific content, or where to assign it, > transparently to > > ALTO, without ALTO having to know (for cache location) what content is > > assigned where. This is good for the caches, as it gives them maximum > > flexibility, without having to implement a complex state-change > mechanism > > between the cache servers and the ALTO server. > > > [Stas Khirman] > Lets review a few usage cases to decide if ALTO can locate optimal cache > without content identity. > > 1.) Cache implemented as a single virtual peer or as a set of peers with > the > same cached content. Certainly, no content knowledge needed to locate a > most > appropriate server. However, such architecture doesn't scale. > > 2.) Cache implemented as distributed set of servers where given content > may > be located in some subset of nodes. If ALTO return [ordered] list of all > known servers, it will be up to client application to poll them to > discover > which one has appropriate content. Sometimes it will work, but with > large > list it takes significant time, especially harmful for applications that > uses cache for bootstrapped playback. > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > to a > master cache (cache director). Upon client connection, master redirects > it > to a slave cache that has appropriate content. However, "master" do not > have > enough knowledge to pick "ALTO optimized" slave server from set of > appropriate ( I assume that popular content may be presented in multiple > cache locations). Master can resolve this issue with a second ALTO > lookup, > but it not different from separated "discovery" and "optimization" calls > as > I suggested. > > 4.) Cache service implemented by third party CDN ( I assume you referred > to > this specific case). In this case decision what cache to be used is > under > control on another party (CDN owner) who may have "optimization" policy > quite different then originating ISP (those diminishing value of ISP-own > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > ISP > operated CDN may use "selection" policy that increase its own profit, > but > not decrease cost of originating ISP. > > > > > _______________________________________________ > 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 Sat Jul 19 06:27: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 4EA1F3A6864; Sat, 19 Jul 2008 06:27: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 DE16F3A6864 for ; Sat, 19 Jul 2008 06:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.027, 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 9y5IXwRYlunK for ; Sat, 19 Jul 2008 06:27:57 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D014F3A67D4 for ; Sat, 19 Jul 2008 06:27:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D01A5E10AF6; Sat, 19 Jul 2008 09:28: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 ec71A-tIzv0A; Sat, 19 Jul 2008 09:28:23 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 8F607E10AF2; Sat, 19 Jul 2008 09:28:23 -0400 (EDT) Date: Sat, 19 Jul 2008 09:28:23 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <344227576.29161216474103564.JavaMail.root@dkny.pando.com> In-Reply-To: <1398206987.29141216472942336.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 There are a couple of ways that ALTO and p2p caching could interact (that I can think of - I am sure that there are more). - ALTO returns a list of several nearby cache servers. The p2p client connects to all of the caches (as peers) and tries to use them. Each cache server individually (or collectively) decides what to cache where, and thus each cache server chooses to particpate (or not) in a given swarm. Note that it's desirable for a p2p client to receive data from multiple p2p caches, as it produces better delivery performance, and operational resilience than a single cache server. - ALTO returns one nearest cache server. The p2p client connects to it, and the cache server either serves the content, redirects to another cache server that has the content, or determines that the content isn't cached. Note that p2p protocols don't have a 'redirect' in the way that HTTP does (for example), but they provide comparable mechanisms (e.g. peer exchange) that could be used to connect the peer and the other cache. The 'redirect' could be ALTO guided (e.g. the first cache uses ALTO to find other cache servers near the p2p client). - The cache system operates a 'master' that knows where all content is cached, the network topology, etc. ALTO tells all peers in the ISP to connect to the 'master' which they redirects all p2p transfers to the appropriate caches. In all of these scenarios, ALTO provides relatively static network-aware information (e.g. location of nearby caches), and the caching system decides what is cached where (which is highly dynamic). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Laird Popkin" , "stefano previdi" Cc: p2pi@ietf.org Sent: Friday, July 18, 2008 10:34:40 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Laird Popkin > Sent: Friday, July 18, 2008 4:01 AM > To: stefano previdi > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > We should minimize the amount of caching metadata and logic are exposed in > ALTO. As long as ALTO can introduce the p2p cache server to the p2p > clients, and tell them that they are caches rather than normal peers, the > rest (specific content assignment to specific caches, preferential use of > caches over normal peers, etc.) can be negotiated between the p2p clients > and the caches using the p2p protocols, without ALTO's involvement. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > [Stas Khirman] Sorry, does " specific content assignment to specific caches... can be negotiated between the p2p clients and the caches ... without ALTO's involvement " mean that what p2p client will negotiate what specific cache server to use without ALTO assistance/recommendation ? In this case, selected cache may not be an optimal (closes, cheapest, etc ) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jul 19 07:32: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 726103A689C; Sat, 19 Jul 2008 07:32: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 862153A689C for ; Sat, 19 Jul 2008 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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 8AVPRTSt4s0C for ; Sat, 19 Jul 2008 07:32:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id B55173A6881 for ; Sat, 19 Jul 2008 07:32:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5991933C34; Sat, 19 Jul 2008 10:32:40 -0400 (EDT) Date: Sat, 19 Jul 2008 10:32:40 -0400 From: John Leslie To: Laird Popkin Message-ID: <20080719143240.GA64676@verdi> References: <001201c8e95e$2a565e00$6400a8c0@jnpr.net> <797668489.29111216472661464.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <797668489.29111216472661464.JavaMail.root@dkny.pando.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: [p2pi] Content Identifiers sent to ALTO server? 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: > > Note that content optimization can also (potentially) be > content-specific. For example, in P4P, the guidance to the p2p > networks can be 'tuned' to reflect the specific distribution of > content. This is (potentially) helpful when content is sufficiently static to flood the distribution information to all ALTO servers. This is not the general case, and might not even be the most common case in future scenarios. > Perhaps the way to phrase this is that the ALTO server MUST support > operation with no content identifiers, but ALTO clients MAY send > content identifiers? I think Stas was saying that even receiving and discarding content Identifiers could cause undesirable legal exposure to large ISPs. In any case, I agree it could. I see two very different use cases for what we're discussing here. 1. Client has a list of IP addresses, and wants to know which to try first; 2. Client doesn't have a list of IP addresses, but has a Content Identifier, and wants an ordered list of IP addresses to try. I frankly would much prefer to develop these separately. The second might well have reason to call upon the first; but the first never has any reason to make use of the second. Trying to combine both into a single protocol complicates things unnecessarily (even before the legal complications come into play). Also, the two cases deal in information best known by parties with vastly different interests in limiting distribution of that information -- up to and including a business decision to obscure or even falsify the information passed to certain other parties. The technical problems of combining both into a single protocol look easy enough, but yield no measurable benefit. The legal and information-protection problem are much more serious. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jul 19 09:05: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 1619A3A69E9; Sat, 19 Jul 2008 09:05: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 E4F8E3A69AD for ; Sat, 19 Jul 2008 09:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 3l3UxvpdQFwo for ; Sat, 19 Jul 2008 09:05:48 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 09C4A3A69A2 for ; Sat, 19 Jul 2008 09:05:44 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sat, 19 Jul 2008 09:06:12 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jul 2008 09:05:18 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 19 Jul 2008 12:05:17 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Sat, 19 Jul 2008 16:05:16 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 19 Jul 2008 09:04:53 -0700 From: Reinaldo Penno To: Laird Popkin , Stas Khirman Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjpuS3/fSbO6lrJy0uxXlwMqxaPLA== In-Reply-To: <344227576.29161216474103564.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 19 Jul 2008 16:05:17.0343 (UTC) FILETIME=[3C81F2F0:01C8E9B9] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Laird, I agree with your assessment but I think from an ALTO perspective they boil down to having an extensible protocol. The second or third redirection steps seems to be outside the scope of ALTO (at this point). >From a protocol requirements perspective what we are saying is that ALTO protocol need to have types/handles for cache and other resources. Cache is certainly a low-hanging fruit because a cache is also a peer, but an ALTO server might need to convey IP addresses related to other resources. Regards, Reinaldo On 7/19/08 6:28 AM, "Laird Popkin" wrote: > There are a couple of ways that ALTO and p2p caching could interact (that I > can think of - I am sure that there are more). > > - ALTO returns a list of several nearby cache servers. The p2p client connects > to all of the caches (as peers) and tries to use them. Each cache server > individually (or collectively) decides what to cache where, and thus each > cache server chooses to particpate (or not) in a given swarm. Note that it's > desirable for a p2p client to receive data from multiple p2p caches, as it > produces better delivery performance, and operational resilience than a single > cache server. > > - ALTO returns one nearest cache server. The p2p client connects to it, and > the cache server either serves the content, redirects to another cache server > that has the content, or determines that the content isn't cached. Note that > p2p protocols don't have a 'redirect' in the way that HTTP does (for example), > but they provide comparable mechanisms (e.g. peer exchange) that could be used > to connect the peer and the other cache. The 'redirect' could be ALTO guided > (e.g. the first cache uses ALTO to find other cache servers near the p2p > client). > > - The cache system operates a 'master' that knows where all content is cached, > the network topology, etc. ALTO tells all peers in the ISP to connect to the > 'master' which they redirects all p2p transfers to the appropriate caches. > > In all of these scenarios, ALTO provides relatively static network-aware > information (e.g. location of nearby caches), and the caching system decides > what is cached where (which is highly dynamic). > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Stas Khirman" > To: "Laird Popkin" , "stefano previdi" > Cc: p2pi@ietf.org > Sent: Friday, July 18, 2008 10:34:40 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >> Laird Popkin >> Sent: Friday, July 18, 2008 4:01 AM >> To: stefano previdi >> Cc: p2pi@ietf.org >> Subject: Re: [p2pi] Charter and problem statement >> >> We should minimize the amount of caching metadata and logic are exposed in >> ALTO. As long as ALTO can introduce the p2p cache server to the p2p >> clients, and tell them that they are caches rather than normal peers, the >> rest (specific content assignment to specific caches, preferential use of >> caches over normal peers, etc.) can be negotiated between the p2p clients >> and the caches using the p2p protocols, without ALTO's involvement. >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> > [Stas Khirman] > Sorry, does " specific content assignment to specific caches... can be > negotiated between the p2p clients and the caches ... without ALTO's > involvement " mean that what p2p client will negotiate what specific cache > server to use without ALTO assistance/recommendation ? > > In this case, selected cache may not be an optimal (closes, cheapest, etc ) > > > > _______________________________________________ > 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 Sat Jul 19 09:38: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 737413A6927; Sat, 19 Jul 2008 09:38: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 E03C03A6909 for ; Sat, 19 Jul 2008 09:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.038, 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 58NmhNK8VqG7 for ; Sat, 19 Jul 2008 09:38:30 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 095FC3A6849 for ; Sat, 19 Jul 2008 09:38:29 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48331796; Sat, 19 Jul 2008 12:38:39 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jul 2008 12:38:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 19 Jul 2008 12:38:31 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F6019405FA@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjoxRsLo/toTwlMTJ6LlgTQJ9Z5vAAZu75wACP/nYo= References: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com><1117197229.19991216378637139.JavaMail.root@dkny.pando.com> <001201c8e95e$2a565e00$6400a8c0@jnpr.net> From: "Woundy, Richard" To: "Stas Khirman" , "Laird Popkin" X-OriginalArrivalTime: 19 Jul 2008 16:38:39.0703 (UTC) FILETIME=[E601D670:01C8E9BD] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 >In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. Maybe the client could determine by out-of-band means (e.g. metadata) whether it makes sense to send the content ID in an ALTO request. There is an underlying assumption here that every P2P user is going to request at least some illicit content (copyright infringing or kiddie porn). What if P2P was primarily used for "legitimate" content distribution? How would that assumption influence our requirements? At the same time, I would caution against assuming that the lack of content identification in any ALTO request implies that the user is attempting something illegal. There are obviously many privacy concerns besides trying to evade one's legal system... -- Rich ________________________________ From: p2pi-bounces@ietf.org on behalf of Stas Khirman Sent: Sat 7/19/2008 1:13 AM To: 'Laird Popkin'; Woundy, Richard Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Friday, July 18, 2008 3:57 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > I agree with Richard - as long as content ID's are optional and > abstracted (e.g. content ID's are not Torrent ID's) I don't think there's > a privacy issue. [Stas Khirman] Laird and Richard, Thank you for clarifying this issue - I convinced that content id does not create additional problems in use case when ISP is using cache servers. Indeed, if any kind of caching implemented on ISP level, they already have privacy/DMCA questions resolved somehow. It also true for use case of P2P CDN that use P4P architecture (ALTO server polled by pTracker ). In those use cases, including content id in ALTO request makes no harm, and can be quite useful for cache location and [probably] other goals (differentiated QoS ?) However, I still worry about use case that seems to be more "popular" ( in term on number of users) : due variety of [legal] reasons, ISP does not install caching at all, but want to use ALTO-powered transport optimization for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P clients adopted ALTO). In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. And it is not just hypothetical speculation - see for example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . Probably, "optionally" can be achieved if during ALTO server discovery stage ( DNS?) client receives some kind of "configuration" flag and will be mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have no idea, but assume that the better "DMCA-proof" solution is to separate "content-sensitive" functionalities (like cache discovery) from "content agnostic" ones. > > There are a number of use cases where metadata related to the content > could be useful in allowing the ALTO server to make decisions. For example, > an ISP might want to implement policies in their ALTO server such as: > > - Don't cache consumer generated content (requires being able to > differentiate between CGC and commercial content). > - Provide different guidance to different applications (requires knowledge > of p2p application). > - Provide guidance based on distribution of that content (requires ID of > that specific content). > > It's a good point that once content is cached the ISP knows a lot about > the content and its distribution. In particular, since it's participating > in the p2p network it knows the IP addresses of people exchanging the > content, whatever metadata is exposed about the content in the protocol > (e.g. size, number of files, names). And for p2p networks that don't > secure content on caches (Pando does, but some others do not) the ISP has > the content on the cache server and can inspect it directly. But this is > (IMO, IANAL) similar to the case of an HTTP cache or an email server - the > ISP is providing a service, and privacy of use of that service is > protected by policy, not by technology. > > Given all of that, ALTO can certainly be applied to content that isn't > cached, and it should preserve privacy for that content. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > >It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > I've been thinking about this since yesterday, and I'm not really sure I > agree with this statement. > > I definitely understand that there would likely be privacy concerns if > ALTO mandated content identification in its messages. Content identities > should be an optional parameter in the ALTO message exchange (if we can > agree that it should be kept at all). > > But I would think that having the content identity could help an ALTO > server make a better recommendation, at least for P2P caches. > > Consider the case when the ISP is operating an ALTO server as well as a > P2P cache. If there isn't an issue of violating customer privacy, why > would it be undesirable to reveal the content identity to the ALTO > server, when it is necessary to reveal the content identity to the P2P > caching server? > > In fact, the P2P caching server knows potentially more valuable > information than the content identity. ALTO would only know about > metadata for content, whereas the P2P cache would have a copy of the > actual content. > > To illustrate, suppose that some content's metadata (e.g. torrent) > indicates that the file is "Spiderman" and not much more. It is possible > that the file represents a DVD rip of a Spiderman movie. It is equally > possible that the file represents a digital home video of someone's > child wearing a Spiderman costume for Halloween. Examining the actual > content (as stored on the P2P cache) would help determine which scenario > is true. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stas Khirman > Sent: Wednesday, July 16, 2008 5:55 PM > To: 'Laird Popkin' > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > I agree that keeping content identity out of cache location is a good > idea. > > [Stas Khirman] > Laird, > > It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > > > That being said, cache location doesn't need to be content-specific, > > because one the p2p client connects to the caches, the caches can > > determine what they do on a content-specific basis. So ALTO could (for > > example) decide which cache servers to send to a user based on the > user's > > network location and protocol (e.g. Pando caches might run on > different > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > can > > return multiple cache servers (i.e. pools) the cache servers can > manage > > whether to cache specific content, or where to assign it, > transparently to > > ALTO, without ALTO having to know (for cache location) what content is > > assigned where. This is good for the caches, as it gives them maximum > > flexibility, without having to implement a complex state-change > mechanism > > between the cache servers and the ALTO server. > > > [Stas Khirman] > Lets review a few usage cases to decide if ALTO can locate optimal cache > without content identity. > > 1.) Cache implemented as a single virtual peer or as a set of peers with > the > same cached content. Certainly, no content knowledge needed to locate a > most > appropriate server. However, such architecture doesn't scale. > > 2.) Cache implemented as distributed set of servers where given content > may > be located in some subset of nodes. If ALTO return [ordered] list of all > known servers, it will be up to client application to poll them to > discover > which one has appropriate content. Sometimes it will work, but with > large > list it takes significant time, especially harmful for applications that > uses cache for bootstrapped playback. > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > to a > master cache (cache director). Upon client connection, master redirects > it > to a slave cache that has appropriate content. However, "master" do not > have > enough knowledge to pick "ALTO optimized" slave server from set of > appropriate ( I assume that popular content may be presented in multiple > cache locations). Master can resolve this issue with a second ALTO > lookup, > but it not different from separated "discovery" and "optimization" calls > as > I suggested. > > 4.) Cache service implemented by third party CDN ( I assume you referred > to > this specific case). In this case decision what cache to be used is > under > control on another party (CDN owner) who may have "optimization" policy > quite different then originating ISP (those diminishing value of ISP-own > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > ISP > operated CDN may use "selection" policy that increase its own profit, > but > not decrease cost of originating ISP. > > > > > _______________________________________________ > 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 Sat Jul 19 12:35: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 612A83A6A80; Sat, 19 Jul 2008 12:35: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 BF9943A6A80 for ; Sat, 19 Jul 2008 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 cALz74oUodm8 for ; Sat, 19 Jul 2008 12:35:56 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.238]) by core3.amsl.com (Postfix) with ESMTP id CFB4C3A6A6C for ; Sat, 19 Jul 2008 12:35:55 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id q18so2862319qba.41 for ; Sat, 19 Jul 2008 12:36:31 -0700 (PDT) Received: by 10.142.229.5 with SMTP id b5mr615287wfh.50.1216496190693; Sat, 19 Jul 2008 12:36:30 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 32sm4828040wfc.12.2008.07.19.12.36.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Jul 2008 12:36:29 -0700 (PDT) Message-Id: <6B45387E-6798-4277-980C-E38319C11161@shlang.com> From: Stanislav Shalunov To: "Woundy, Richard" In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6019405FA@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 19 Jul 2008 12:36:21 -0700 References: <74CCBBDF76102846AFA7B29F3A98D3F60107C168@PACDCEXCMB06.cable.comcast.com><1117197229.19991216378637139.JavaMail.root@dkny.pando.com> <001201c8e95e$2a565e00$6400a8c0@jnpr.net> <74CCBBDF76102846AFA7B29F3A98D3F6019405FA@PACDCEXCMB06.cable.comcast.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Jul 19, 2008, at 9:38 AM, Woundy, Richard wrote: > Maybe the client could determine by out-of-band means (e.g. > metadata) whether it makes sense to send the content ID in an ALTO > request. Note that, at least in BitTorrent, clients that view the network adversarially already have a manually triggered mechanism, encrypted mode, to deal with it. Encrypted mode might well be sufficient. > > > There is an underlying assumption here that every P2P user is going > to request at least some illicit content (copyright infringing or > kiddie porn). What if P2P was primarily used for "legitimate" > content distribution? How would that assumption influence our > requirements? > > At the same time, I would caution against assuming that the lack of > content identification in any ALTO request implies that the user is > attempting something illegal. There are obviously many privacy > concerns besides trying to evade one's legal system... > > -- Rich > > ________________________________ > > From: p2pi-bounces@ietf.org on behalf of Stas Khirman > Sent: Sat 7/19/2008 1:13 AM > To: 'Laird Popkin'; Woundy, Richard > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > >> -----Original Message----- >> From: Laird Popkin [mailto:laird@pando.com] >> Sent: Friday, July 18, 2008 3:57 AM >> To: Richard Woundy >> Cc: p2pi@ietf.org; Stas Khirman >> Subject: Re: [p2pi] Charter and problem statement >> >> I agree with Richard - as long as content ID's are optional and >> abstracted (e.g. content ID's are not Torrent ID's) I don't think >> there's >> a privacy issue. > > [Stas Khirman] > > Laird and Richard, > > Thank you for clarifying this issue - I convinced that content id > does not > create additional problems in use case when ISP is using cache > servers. > Indeed, if any kind of caching implemented on ISP level, they > already have > privacy/DMCA questions resolved somehow. It also true for use case > of P2P > CDN that use P4P architecture (ALTO server polled by pTracker ). In > those > use cases, including content id in ALTO request makes no harm, and > can be > quite useful for cache location and [probably] other goals > (differentiated > QoS ?) > > However, I still worry about use case that seems to be more > "popular" ( in > term on number of users) : due variety of [legal] reasons, ISP does > not > install caching at all, but want to use ALTO-powered transport > optimization > for BitTorrent, eDonkey and similar P2P traffic (assuming that major > P2P > clients adopted ALTO). > > In this use case, inclusion of content id into ALTO request makes no > sense > at all but opens a Pandora box of potential liabilities. Making it > optional > with end-user manual configuration will not help - even if small > part of > users keep it ON, it will create a sufficient reason for DMCA-like > request > to filter P2P content. And it is not just hypothetical speculation - > see for > example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss > http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . > > Probably, "optionally" can be achieved if during ALTO server > discovery stage > ( DNS?) client receives some kind of "configuration" flag and will be > mandated NOT TO send content id. Will it pass legal scrutiny? Will > be ALTO > server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I > have no > idea, but assume that the better "DMCA-proof" solution is to separate > "content-sensitive" functionalities (like cache discovery) from > "content > agnostic" ones. > > >> >> There are a number of use cases where metadata related to the content >> could be useful in allowing the ALTO server to make decisions. For > example, >> an ISP might want to implement policies in their ALTO server such as: >> >> - Don't cache consumer generated content (requires being able to >> differentiate between CGC and commercial content). >> - Provide different guidance to different applications (requires >> knowledge >> of p2p application). >> - Provide guidance based on distribution of that content (requires >> ID of >> that specific content). >> >> It's a good point that once content is cached the ISP knows a lot >> about >> the content and its distribution. In particular, since it's >> participating >> in the p2p network it knows the IP addresses of people exchanging the >> content, whatever metadata is exposed about the content in the >> protocol >> (e.g. size, number of files, names). And for p2p networks that don't >> secure content on caches (Pando does, but some others do not) the >> ISP has >> the content on the cache server and can inspect it directly. But >> this is >> (IMO, IANAL) similar to the case of an HTTP cache or an email >> server - the >> ISP is providing a service, and privacy of use of that service is >> protected by policy, not by technology. >> >> Given all of that, ALTO can certainly be applied to content that >> isn't >> cached, and it should preserve privacy for that content. :-) >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Richard Woundy" >> To: "Stas Khirman" , "Laird Popkin" > > >> Cc: p2pi@ietf.org >> Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York >> Subject: RE: [p2pi] Charter and problem statement >> >>> It seems that we agree on the key point - content identity in ALTO >> ["peer >> selection"] request will be harmful. >> >>> It will be very important to get confirmation/rejection of this >> assumption >> from ISP's representatives. >> >> I've been thinking about this since yesterday, and I'm not really >> sure I >> agree with this statement. >> >> I definitely understand that there would likely be privacy concerns >> if >> ALTO mandated content identification in its messages. Content >> identities >> should be an optional parameter in the ALTO message exchange (if we >> can >> agree that it should be kept at all). >> >> But I would think that having the content identity could help an ALTO >> server make a better recommendation, at least for P2P caches. >> >> Consider the case when the ISP is operating an ALTO server as well >> as a >> P2P cache. If there isn't an issue of violating customer privacy, why >> would it be undesirable to reveal the content identity to the ALTO >> server, when it is necessary to reveal the content identity to the >> P2P >> caching server? >> >> In fact, the P2P caching server knows potentially more valuable >> information than the content identity. ALTO would only know about >> metadata for content, whereas the P2P cache would have a copy of the >> actual content. >> >> To illustrate, suppose that some content's metadata (e.g. torrent) >> indicates that the file is "Spiderman" and not much more. It is >> possible >> that the file represents a DVD rip of a Spiderman movie. It is >> equally >> possible that the file represents a digital home video of someone's >> child wearing a Spiderman costume for Halloween. Examining the actual >> content (as stored on the P2P cache) would help determine which >> scenario >> is true. >> >> -- Rich >> >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On >> Behalf Of >> Stas Khirman >> Sent: Wednesday, July 16, 2008 5:55 PM >> To: 'Laird Popkin' >> Cc: p2pi@ietf.org >> Subject: Re: [p2pi] Charter and problem statement >> >>> -----Original Message----- >>> From: Laird Popkin [mailto:laird@pando.com] >>> Sent: Wednesday, July 16, 2008 11:15 AM >>> >>> I agree that keeping content identity out of cache location is a >>> good >> idea. >> >> [Stas Khirman] >> Laird, >> >> It seems that we agree on the key point - content identity in ALTO >> ["peer >> selection"] request will be harmful. >> >> It will be very important to get confirmation/rejection of this >> assumption >> from ISP's representatives. >> >> >>> That being said, cache location doesn't need to be content-specific, >>> because one the p2p client connects to the caches, the caches can >>> determine what they do on a content-specific basis. So ALTO could >>> (for >>> example) decide which cache servers to send to a user based on the >> user's >>> network location and protocol (e.g. Pando caches might run on >> different >>> servers from Kontiki caches or HTTP caches, etc.). But as long as >>> ALTO >> can >>> return multiple cache servers (i.e. pools) the cache servers can >> manage >>> whether to cache specific content, or where to assign it, >> transparently to >>> ALTO, without ALTO having to know (for cache location) what >>> content is >>> assigned where. This is good for the caches, as it gives them >>> maximum >>> flexibility, without having to implement a complex state-change >> mechanism >>> between the cache servers and the ALTO server. >>> >> [Stas Khirman] >> Lets review a few usage cases to decide if ALTO can locate optimal >> cache >> without content identity. >> >> 1.) Cache implemented as a single virtual peer or as a set of peers >> with >> the >> same cached content. Certainly, no content knowledge needed to >> locate a >> most >> appropriate server. However, such architecture doesn't scale. >> >> 2.) Cache implemented as distributed set of servers where given >> content >> may >> be located in some subset of nodes. If ALTO return [ordered] list >> of all >> known servers, it will be up to client application to poll them to >> discover >> which one has appropriate content. Sometimes it will work, but with >> large >> list it takes significant time, especially harmful for applications >> that >> uses cache for bootstrapped playback. >> >> 3.) Cache implemented in master-slave hierarchy. ALTO returns a >> pointer >> to a >> master cache (cache director). Upon client connection, master >> redirects >> it >> to a slave cache that has appropriate content. However, "master" do >> not >> have >> enough knowledge to pick "ALTO optimized" slave server from set of >> appropriate ( I assume that popular content may be presented in >> multiple >> cache locations). Master can resolve this issue with a second ALTO >> lookup, >> but it not different from separated "discovery" and "optimization" >> calls >> as >> I suggested. >> >> 4.) Cache service implemented by third party CDN ( I assume you >> referred >> to >> this specific case). In this case decision what cache to be used is >> under >> control on another party (CDN owner) who may have "optimization" >> policy >> quite different then originating ISP (those diminishing value of >> ISP-own >> ALTO service). Probably it is extreme speculation, but in theory, >> Tier-1 >> ISP >> operated CDN may use "selection" policy that increase its own profit, >> but >> not decrease cost of originating ISP. >> >> >> >> >> _______________________________________________ >> 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 -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jul 19 16:42: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 8282E3A688B; Sat, 19 Jul 2008 16:42: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 1C47D3A688B for ; Sat, 19 Jul 2008 16:42: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 EStT7pp5nv2n for ; Sat, 19 Jul 2008 16:42:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 748E43A67F7 for ; Sat, 19 Jul 2008 16:42:00 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KKM4M0zH5-0004Lo; Sat, 19 Jul 2008 19:42:34 -0400 From: "Stas Khirman" To: "'Laird Popkin'" References: <001201c8e95e$2a565e00$6400a8c0@jnpr.net> <797668489.29111216472661464.JavaMail.root@dkny.pando.com> Date: Sat, 19 Jul 2008 16:42:29 -0700 Message-ID: <007901c8e9f9$1e4a3f50$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjpoAsUmSpRMLpCQf+sgMGtmqc0AgAVvpQg In-Reply-To: <797668489.29111216472661464.JavaMail.root@dkny.pando.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX19eqV7W52f7wg8ix6YkgiPyL/ilhhNXIv2XxfC 4ZHiz83bcgT9AcGiSXsVabEnPccU8dW7fxeN6M9Ts2Og3ngC2j yaMxeG9iCvy6WcHFjgQWw== Cc: 'Richard Woundy' , p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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: Saturday, July 19, 2008 6:04 AM > To: Stas Khirman > Cc: p2pi@ietf.org; Richard Woundy > Subject: Re: [p2pi] Charter and problem statement > > Note that content optimization can also (potentially) be content-specific. > For example, in P4P, the guidance to the p2p networks can be 'tuned' to > reflect the specific distribution of content. So for both peer selection > optimization and for cache location there are use cases that could utilize > some form of content identifier. > [Stas Khirman] Sorry, probably I missed your point - how content information can be used in peer selection (traffic optimization) ? Let's consider a use case when ALTO has no knowledge about additional peers (such as cache) to "enrich" list supplied by client for optimization. ALTO receives list of peers ( and their characteristics) from client and should send back ordered ( and probably filtered) list of the same peers. What kind of information to be used in this process? IMHO, ALTO needs to know peers characteristics (leeacher, seeder, firewalled, etc),network topology, utilization, some traffic business rules, but I fail to see how content information can be useful here at all.... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 07:28: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 A9B1D3A683B; Mon, 21 Jul 2008 07:28: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 AD8983A6780 for ; Mon, 21 Jul 2008 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.026, 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 LvntAPJ3nX1t for ; Mon, 21 Jul 2008 07:28:24 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 5F6CB3A683B for ; Mon, 21 Jul 2008 07:28:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id CC772E10C72; Mon, 21 Jul 2008 10:28:50 -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 xvtRpFxA5mC1; Mon, 21 Jul 2008 10:28:50 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 2D9E8E10C6B; Mon, 21 Jul 2008 10:28:50 -0400 (EDT) Date: Mon, 21 Jul 2008 10:28:50 -0400 (EDT) From: Laird Popkin To: John Leslie Message-ID: <441209888.30961216650530155.JavaMail.root@dkny.pando.com> In-Reply-To: <137868081.30911216649763195.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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 don't think that either of the scenarios that you list is particularly likely for p2p swarm file downloading. I'll explain why, they outline the model of ALTO that seems most valuable for that application. 1. If the client has a list of IP addresses, the list is short enough that it can test throughput with each of them all fairly quickly, so the value of ALTO is low in terms of optimizing p2p performance. This scenario makes sense for some other applications (e.g. finding a good network relay, or optimizing small swarm downloads). 2) I think that it's safe to assume that p2p networks will never send a list of all IP addresses associated with a particular content swarm to an ISP's ALTO server. This raises obvious business, privacy and legal issues, which are at best quite concerning. In addition, putting the ALTO protocol in the middle of a peer request creates unacceptable operational problems for the p2p network that would be far worse than any optimization that ALTO could provide. Let's compare a standard BitTorrent "tracker announce", a tracker announce with ALTO IP lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of 10,000 peers. standard: peer announces, Tracker responds from list in memory (one MTU each way, UDP). Fast, reliable in-memory operation. ALTO IP list: In this model, information sent into or out of ALTO is lists of IP addresses. Peer announces. Tracker sends request, with the peer address and a complete list of the 10,000 peers in the swarm, to the ALTO server. ALTO server computes optimal list and returns 50 peers. Tracker returns list to peer. Tracker does this (send swarm peer list, receive ALTO peer list) 2,000 times per second. This makes the p2p tracker slow and unreliable (by adding external communication to what is now an in-memory operation), and places a huge operational burden on the ISP's ALTO server. I suspect that ISPs would have problems with this as well, because it would effectly make their ALTO server a p2p tracker, with all that implies. ALTO guidance: Tracker (updated periodically, asynchronously) receives optimization rules from the ALTO server. Peer announces. Tracker picks optimal list from known swarm peers based on the ISP's rules, and returns 50 peers to announcing peer. This is slightly slower than a standard announce, but it's all in memory in the Tracker, and only imposes a low volume of ALTO communications. Communication is the same as the first case (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.) to update the optimization rules. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Laird Popkin" Cc: "Stas Khirman" , p2pi@ietf.org Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York Subject: Content Identifiers sent to ALTO server? Laird Popkin wrote: > > Note that content optimization can also (potentially) be > content-specific. For example, in P4P, the guidance to the p2p > networks can be 'tuned' to reflect the specific distribution of > content. This is (potentially) helpful when content is sufficiently static to flood the distribution information to all ALTO servers. This is not the general case, and might not even be the most common case in future scenarios. > Perhaps the way to phrase this is that the ALTO server MUST support > operation with no content identifiers, but ALTO clients MAY send > content identifiers? I think Stas was saying that even receiving and discarding content Identifiers could cause undesirable legal exposure to large ISPs. In any case, I agree it could. I see two very different use cases for what we're discussing here. 1. Client has a list of IP addresses, and wants to know which to try first; 2. Client doesn't have a list of IP addresses, but has a Content Identifier, and wants an ordered list of IP addresses to try. I frankly would much prefer to develop these separately. The second might well have reason to call upon the first; but the first never has any reason to make use of the second. Trying to combine both into a single protocol complicates things unnecessarily (even before the legal complications come into play). Also, the two cases deal in information best known by parties with vastly different interests in limiting distribution of that information -- up to and including a business decision to obscure or even falsify the information passed to certain other parties. The technical problems of combining both into a single protocol look easy enough, but yield no measurable benefit. The legal and information-protection problem are much more serious. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 10:10: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 147EE3A6ADA; Mon, 21 Jul 2008 10:10: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 B881A3A6AD8 for ; Mon, 21 Jul 2008 10:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 m9Fts82cWiNl for ; Mon, 21 Jul 2008 10:10:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 4AA8B3A6ADA for ; Mon, 21 Jul 2008 10:10:05 -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 m6LHAiNl023164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jul 2008 12:10:44 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6LHAd2u021374 for ; Mon, 21 Jul 2008 12:10:39 -0500 (CDT) Message-ID: <4884C313.70703@alcatel-lucent.com> Date: Mon, 21 Jul 2008 12:10:43 -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.33 Subject: [p2pi] Updated 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 Folks: Enrico and I have updated the charter to reflect the caching discussion we have had on the list over the past few days. The updated charter is available at http://alto.tilab.com/docs/charter.txt We've added the last bullet list -- reproduce here -- based on the list discussion: - A discovery mechanism for locating nearby hosts the querying node may not be aware of. In certain P2P networks, hosts operating caches may be able to fulfill the node's needs as well as keep the traffic between peers localized. In VoIP networks, nearby hosts operating relays may effectively be discovered to aid a VoIP client in establishing multimedia communications. It is anticipated that if existing resource discovery mechanisms are sufficient to suit this purpose, then the WG will produce one or more documents describing how these discovery mechanisms may be used to effectively find the peers. The discovery mechanism can be executed in the clients as well as in the oracle. To allow clients that prefer the oracle to provide such information, the WG will produce extensions to the oracle signaling protocol to enable the peer or client to transfer the desired properties to the oracle for subsequent lookups. Comments on it will be welcome. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 21 10:23: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 BB83228C13B; Mon, 21 Jul 2008 10:23: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 8EFE728C177 for ; Mon, 21 Jul 2008 10:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=0.093, 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 mrQ4zYGnf2Ng for ; Mon, 21 Jul 2008 10:23:33 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id B629428C146 for ; Mon, 21 Jul 2008 10:23:32 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 19:24:11 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 19:24:10 +0200 Received: from [10.229.8.100] (10.229.8.100) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 21 Jul 2008 19:24:10 +0200 Message-ID: <4884C622.30606@telecomitalia.it> Date: Mon, 21 Jul 2008 19:23:46 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4884C313.70703@alcatel-lucent.com> In-Reply-To: <4884C313.70703@alcatel-lucent.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 21 Jul 2008 17:24:10.0763 (UTC) FILETIME=[96AC05B0:01C8EB56] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Updated 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="===============1794890702==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1794890702== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080303080008010202050402" --------------ms080303080008010202050402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > The updated charter is available at > http://alto.tilab.com/docs/charter.txt > > We've added the last bullet list -- reproduce here -- based > on the list discussion: The new version also includes some changes reflecting comments received on the mailing list. Diffs from the previous version are available at http://alto.tilab.com/docs/charter.txt.diff -- Ciao, Enrico --------------ms080303080008010202050402 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MjExNzIzNDZaMCMG CSqGSIb3DQEJBDEWBBSddHmeWhY/vLSHZiRJx5M/iw0ALDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAJUa+lE/IqK/ GLOv54Y73sH1iofhvExEVGSVfliFso/m9nYpFShCfbl5d8UE958D/jJLJ8uZrv1+O1NTj95y NPrxsMydogIin0KQEOytaI6yZsOdRGJlM0ETqvk+qy/rLLzSeNew41TPkic8W8xcjRScVfdC ec24Wg930n+YRPKzur6Ejee0zPnWPmEfBfGqPMcigygGql7TOfyziXh5pk6JoVJyqFzELDW6 pPz8bC0xNYoKjAYSjt8PyuGln+RmimX9vIE+s2tQqnPsXUv0J47zroKodZ9c9M0rYNeVZxep 26IrHEhxcbSjCxbEuG0fKo9m7dlcAPnV0EsXoPjypQgAAAAAAAA= --------------ms080303080008010202050402-- --===============1794890702== 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 --===============1794890702==-- From p2pi-bounces@ietf.org Mon Jul 21 11:12: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 C66B33A6928; Mon, 21 Jul 2008 11:12: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 0F2AA3A6928 for ; Mon, 21 Jul 2008 11:12:00 -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=[AWL=0.350, 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 4MOO3ULHCMem for ; Mon, 21 Jul 2008 11:11:58 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id A3F393A68C1 for ; Mon, 21 Jul 2008 11:11:57 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=VGwwo4FEeSD8PwnfYSpMLcjzKiVQNgI1qjHEIDIOlJ6m4+lPPUWZ950c JUngIChNmN/h8qkdM+pX7faTXIvztQ==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 180195933:10.224.36.65:21 Jul 2008 18:12:35 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="180195933" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 21 Jul 2008 18:12:35 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 21 Jul 2008 14:12:35 -0400 To: "Vijay K. Gurbani" Message-ID: Date: Mon, 21 Jul 2008 14:12:35 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <4884C313.70703@alcatel-lucent.com> References: <4884C313.70703@alcatel-lucent.com> Content-Disposition: inline Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Updated 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 Gurbani: We thought that you accepted the comment on tracker-based system per your last email (July 15): OLD: The WG will consider tracker-based P2P systems (a la Bit Torrent) as well as tracker-less P2P networks. NEW: The WG will consider tracker-based P2P systems (a la Bit Torrent) that communicate among its Internet Service Provider (ISP)-based P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. BR/Radhika PS: We are glad that you included a clarification on "oracle," this serves our purpose. ----- Original Message ----- From: "Vijay K. Gurbani" Date: Monday, July 21, 2008 13:11 Subject: [p2pi] Updated charter To: "p2pi@ietf.org" > Folks: Enrico and I have updated the charter to reflect the caching > discussion we have had on the list over the past few days. > > The updated charter is available at > http://alto.tilab.com/docs/charter.txt > > We've added the last bullet list -- reproduce here -- based > on the list discussion: > > - A discovery mechanism for locating nearby hosts the querying node > may not be aware of. In certain P2P networks, hosts operating > caches may be able to fulfill the node's needs as well as keep > the traffic > between peers localized. In VoIP networks, nearby hosts operating > relays may effectively be discovered to aid a VoIP client in > establishing multimedia communications. It is anticipated that > if existing resource discovery mechanisms are sufficient to suit > this purpose, then the WG will produce one or more documents > describing how these discovery mechanisms may be used to > effectively find the peers. The discovery mechanism can be > executed in the clients as well as in the oracle. To allow > clients that prefer the oracle to provide such information, the > WG will produce extensions to the oracle signaling protocol to > enable the peer or client to transfer the desired properties > to the oracle for subsequent lookups. > > Comments on it will be welcome. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 21 12:16: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 8F9683A68F6; Mon, 21 Jul 2008 12:16: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 BC1E73A68F6 for ; Mon, 21 Jul 2008 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cWr3Pvgr1QQp for ; Mon, 21 Jul 2008 12:16:25 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 51DA73A6782 for ; Mon, 21 Jul 2008 12:16:25 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58002153; Mon, 21 Jul 2008 15:16:47 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 15:16:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 15:16:06 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C1C1@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Updated charter Thread-Index: AcjrXWhQwSSGATaJQvCpu4Marg6D0AAAholg References: <4884C313.70703@alcatel-lucent.com> From: "Woundy, Richard" To: "Roy, Radhika R Dr CTR USA USAMC" , "Vijay K. Gurbani" X-OriginalArrivalTime: 21 Jul 2008 19:16:48.0028 (UTC) FILETIME=[5250D5C0:01C8EB66] Cc: p2pi@ietf.org Subject: Re: [p2pi] Updated 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 Radhika, ISPs typically don't operate trackers, so I wouldn't refer to a trackerless system as a "non-ISP" system. Here is a more conventional understanding of a trackerless system copied from http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29: "Completed torrent files are typically published on websites or elsewhere, and registered with a tracker. The tracker maintains lists of the clients currently participating in the torrent. Alternatively, in a trackerless system (decentralized tracking) every peer acts as a tracker." Or am I missing something? -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Roy, Radhika R Dr CTR USA USAMC Sent: Monday, July 21, 2008 2:13 PM To: Vijay K. Gurbani Cc: p2pi@ietf.org Subject: Re: [p2pi] Updated charter Gurbani: We thought that you accepted the comment on tracker-based system per your last email (July 15): OLD: The WG will consider tracker-based P2P systems (a la Bit Torrent) as well as tracker-less P2P networks. NEW: The WG will consider tracker-based P2P systems (a la Bit Torrent) that communicate among its Internet Service Provider (ISP)-based P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. BR/Radhika PS: We are glad that you included a clarification on "oracle," this serves our purpose. ----- Original Message ----- From: "Vijay K. Gurbani" Date: Monday, July 21, 2008 13:11 Subject: [p2pi] Updated charter To: "p2pi@ietf.org" > Folks: Enrico and I have updated the charter to reflect the caching > discussion we have had on the list over the past few days. > > The updated charter is available at > http://alto.tilab.com/docs/charter.txt > > We've added the last bullet list -- reproduce here -- based > on the list discussion: > > - A discovery mechanism for locating nearby hosts the querying node > may not be aware of. In certain P2P networks, hosts operating > caches may be able to fulfill the node's needs as well as keep > the traffic > between peers localized. In VoIP networks, nearby hosts operating > relays may effectively be discovered to aid a VoIP client in > establishing multimedia communications. It is anticipated that > if existing resource discovery mechanisms are sufficient to suit > this purpose, then the WG will produce one or more documents > describing how these discovery mechanisms may be used to > effectively find the peers. The discovery mechanism can be > executed in the clients as well as in the oracle. To allow > clients that prefer the oracle to provide such information, the > WG will produce extensions to the oracle signaling protocol to > enable the peer or client to transfer the desired properties > to the oracle for subsequent lookups. > > Comments on it will be welcome. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 12:32: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 62CE33A6A7F; Mon, 21 Jul 2008 12:32: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 6D1983A6A7F for ; Mon, 21 Jul 2008 12:32:40 -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 yBhbwwLGsbBI for ; Mon, 21 Jul 2008 12:32:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7EE673A680F for ; Mon, 21 Jul 2008 12:32:39 -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 m6LJXGU8028748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 14:33:16 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6LJX64P014062; Mon, 21 Jul 2008 14:33:09 -0500 (CDT) Message-ID: <4884E477.5020409@alcatel-lucent.com> Date: Mon, 21 Jul 2008 14:33:11 -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: "Roy, Radhika R Dr CTR USA USAMC" References: <4884C313.70703@alcatel-lucent.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Updated 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 Roy, Radhika R Dr CTR USA USAMC wrote: > Gurbani: > > We thought that you accepted the comment on tracker-based system per > your last email (July 15): > > OLD: The WG will consider tracker-based P2P systems (a la Bit > Torrent) as well as tracker-less P2P networks. > > NEW: The WG will consider tracker-based P2P systems (a la Bit > Torrent) that communicate among its Internet Service Provider > (ISP)-based P2P systems as well as tracker-less (i.e. Non-ISP) P2P > networks. Radhika: Apologies if my answer was ambiguous. I had written: Tracker-less does not necessarily imply non-ISP any more than tracker-based implies explicit ISP support. IMHO, I believe that the text as written in the draft charter is sufficient and the conflation of the role of an ISP with the need for trackers may serve to confuse the issue further. I still believe this to be the case, and as such, ended up not modifying that part. > PS: We are glad that you included a clarification on "oracle," this > serves our purpose. Sure. Thanks for your time reviewing the charter and the feedback on it. Hope to see you in Dublin. Regards, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 21 13:30: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 7086A3A6A76; Mon, 21 Jul 2008 13:30: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 CA4773A6A76 for ; Mon, 21 Jul 2008 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 OalTnP6PrMn5 for ; Mon, 21 Jul 2008 13:30:55 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 9DE153A6A47 for ; Mon, 21 Jul 2008 13:30:53 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=NkELu8bPLW0H9WKeuaoTLmI+IaNBKX0f2blsp9CP1qSMZ/gl5Nma01gf 28bGN2B80A3mImBjHz2gw9JrIFny6A==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 183634329:10.224.36.65:21 Jul 2008 20:31:31 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.31,225,1215388800"; d="scan'208";a="183634329" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 21 Jul 2008 20:31:11 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 21 Jul 2008 16:31:11 -0400 To: "Vijay K. Gurbani" Message-ID: Date: Mon, 21 Jul 2008 16:31:11 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <4884E477.5020409@alcatel-lucent.com> References: <4884C313.70703@alcatel-lucent.com> <4884E477.5020409@alcatel-lucent.com> Content-Disposition: inline Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Updated 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 Gurbani: Still, we need provide a clarification, like "oracle" what we mean by "tracker." Otherwise, it will remain highly "incomplete" or ambiguous. Radhika ----- Original Message ----- From: "Vijay K. Gurbani" Date: Monday, July 21, 2008 15:33 Subject: Re: [p2pi] Updated charter To: "Roy, Radhika R Dr CTR USA USAMC" Cc: "p2pi@ietf.org" > Roy, Radhika R Dr CTR USA USAMC wrote: > > Gurbani: > > > > We thought that you accepted the comment on tracker-based system per > > your last email (July 15): > > > > OLD: The WG will consider tracker-based P2P systems (a la Bit > > Torrent) as well as tracker-less P2P networks. > > > > NEW: The WG will consider tracker-based P2P systems (a la Bit > > Torrent) that communicate among its Internet Service Provider > > (ISP)-based P2P systems as well as tracker-less (i.e. Non-ISP) P2P > > networks. > > Radhika: Apologies if my answer was ambiguous. I had written: > > Tracker-less does not necessarily imply non-ISP any more than > tracker-based implies explicit ISP support. IMHO, I believe that > the text as written in the draft charter is sufficient and > the conflation of the role of an ISP with the need for trackers > may serve to confuse the issue further. > > I still believe this to be the case, and as such, ended up not > modifying that part. > > > PS: We are glad that you included a clarification on "oracle," this > > serves our purpose. > > Sure. Thanks for your time reviewing the charter and the > feedback on it. Hope to see you in Dublin. > > Regards, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 21 13:37: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 647CF3A6978; Mon, 21 Jul 2008 13:37: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 E2CDC3A68C2 for ; Mon, 21 Jul 2008 13:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 h+Czj784MUkM for ; Mon, 21 Jul 2008 13:37:12 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 972813A67DD for ; Mon, 21 Jul 2008 13:37:12 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=qZhlJ6fk/MmQrohn+fPa7NVmKV2novB3AEGnlEG1fd0Q6lzjiCrmMlQ5 UfFIb8hdtNL65udxR8JTwFkX7llGAg==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 180264889:10.224.36.65:21 Jul 2008 20:37:51 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.31,225,1215388800"; d="scan'208";a="180264889" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 21 Jul 2008 20:37:51 +0000 Received: from [10.240.32.175] (Forwarded-For: 134.80.13.193, [10.240.32.175]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 21 Jul 2008 16:37:51 -0400 To: "Woundy, Richard" Message-ID: Date: Mon, 21 Jul 2008 16:37:51 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C1C1@PACDCEXCMB06.cable.comcast.com> References: <4884C313.70703@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F60107C1C1@PACDCEXCMB06.cable.comcast.com> Content-Disposition: inline Cc: p2pi@ietf.org Subject: Re: [p2pi] Updated 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 Rich: We still need to clarify what the "tracker" means from the technical point of view. Otherwise, we may create ambiguties in BoF and eventually in the WG. Radhika ----- Original Message ----- From: "Woundy, Richard" Date: Monday, July 21, 2008 15:17 Subject: RE: [p2pi] Updated charter To: "Roy, Radhika R Dr CTR USA USAMC" , "Vijay K. Gurbani" Cc: p2pi@ietf.org > Radhika, > > ISPs typically don't operate trackers, so I wouldn't refer to a > trackerless system as a "non-ISP" system. > > Here is a more conventional understanding of a trackerless system > copiedfrom http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29: > "Completedtorrent files are typically published on websites or > elsewhere, and > registered with a tracker. The tracker maintains lists of the clients > currently participating in the torrent. Alternatively, in a > trackerlesssystem (decentralized tracking) every peer acts as a > tracker." > Or am I missing something? > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of > Roy, Radhika R Dr CTR USA USAMC > Sent: Monday, July 21, 2008 2:13 PM > To: Vijay K. Gurbani > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Updated charter > > Gurbani: > > We thought that you accepted the comment on tracker-based system per > your last email (July 15): > > OLD: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > as well as tracker-less P2P networks. > > NEW: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > that communicate among its Internet Service Provider (ISP)-based > P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. > > BR/Radhika > > PS: We are glad that you included a clarification on "oracle," this > serves our purpose. > > ----- Original Message ----- > From: "Vijay K. Gurbani" > Date: Monday, July 21, 2008 13:11 > Subject: [p2pi] Updated charter > To: "p2pi@ietf.org" > > > Folks: Enrico and I have updated the charter to reflect the caching > > discussion we have had on the list over the past few days. > > > > The updated charter is available at > > http://alto.tilab.com/docs/charter.txt > > > > We've added the last bullet list -- reproduce here -- based > > on the list discussion: > > > > - A discovery mechanism for locating nearby hosts the querying node > > may not be aware of. In certain P2P networks, hosts operating > > caches may be able to fulfill the node's needs as well as keep > > the traffic > > between peers localized. In VoIP networks, nearby hosts operating > > relays may effectively be discovered to aid a VoIP client in > > establishing multimedia communications. It is anticipated that > > if existing resource discovery mechanisms are sufficient to suit > > this purpose, then the WG will produce one or more documents > > describing how these discovery mechanisms may be used to > > effectively find the peers. The discovery mechanism can be > > executed in the clients as well as in the oracle. To allow > > clients that prefer the oracle to provide such information, the > > WG will produce extensions to the oracle signaling protocol to > > enable the peer or client to transfer the desired properties > > to the oracle for subsequent lookups. > > > > Comments on it will be welcome. > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 14:37: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 83A353A6808; Mon, 21 Jul 2008 14:37: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 914343A6808 for ; Mon, 21 Jul 2008 14:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.030, 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 rUbF27Rixb6h for ; Mon, 21 Jul 2008 14:37:46 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 3C0E33A67F2 for ; Mon, 21 Jul 2008 14:37:46 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58012355; Mon, 21 Jul 2008 17:38:08 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 17:38:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 17:37:23 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C1C8@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [p2pi] Updated charter Thread-Index: AcjrcbSuD+AnIs/ST8uX0QcneDtwBAAB4Oaw References: <4884C313.70703@alcatel-lucent.com> <74CCBBDF76102846AFA7B29F3A98D3F60107C1C1@PACDCEXCMB06.cable.comcast.com> From: "Woundy, Richard" To: "Roy, Radhika R Dr CTR USA USAMC" X-OriginalArrivalTime: 21 Jul 2008 21:38:08.0329 (UTC) FILETIME=[10F81390:01C8EB7A] Cc: p2pi@ietf.org Subject: Re: [p2pi] Updated 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 > We still need to clarify what the "tracker" means from the technical point of view. Fair enough. -- Rich -----Original Message----- From: Roy, Radhika R Dr CTR USA USAMC [mailto:radhika.r.roy@us.army.mil] Sent: Monday, July 21, 2008 4:38 PM To: Woundy, Richard Cc: Vijay K. Gurbani; p2pi@ietf.org Subject: Re: RE: [p2pi] Updated charter Rich: We still need to clarify what the "tracker" means from the technical point of view. Otherwise, we may create ambiguties in BoF and eventually in the WG. Radhika ----- Original Message ----- From: "Woundy, Richard" Date: Monday, July 21, 2008 15:17 Subject: RE: [p2pi] Updated charter To: "Roy, Radhika R Dr CTR USA USAMC" , "Vijay K. Gurbani" Cc: p2pi@ietf.org > Radhika, > > ISPs typically don't operate trackers, so I wouldn't refer to a > trackerless system as a "non-ISP" system. > > Here is a more conventional understanding of a trackerless system > copiedfrom http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29: > "Completedtorrent files are typically published on websites or > elsewhere, and > registered with a tracker. The tracker maintains lists of the clients > currently participating in the torrent. Alternatively, in a > trackerlesssystem (decentralized tracking) every peer acts as a > tracker." > Or am I missing something? > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of > Roy, Radhika R Dr CTR USA USAMC > Sent: Monday, July 21, 2008 2:13 PM > To: Vijay K. Gurbani > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Updated charter > > Gurbani: > > We thought that you accepted the comment on tracker-based system per > your last email (July 15): > > OLD: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > as well as tracker-less P2P networks. > > NEW: > The WG will consider tracker-based P2P systems (a la Bit Torrent) > that communicate among its Internet Service Provider (ISP)-based > P2P systems as well as tracker-less (i.e. Non-ISP) P2P networks. > > BR/Radhika > > PS: We are glad that you included a clarification on "oracle," this > serves our purpose. > > ----- Original Message ----- > From: "Vijay K. Gurbani" > Date: Monday, July 21, 2008 13:11 > Subject: [p2pi] Updated charter > To: "p2pi@ietf.org" > > > Folks: Enrico and I have updated the charter to reflect the caching > > discussion we have had on the list over the past few days. > > > > The updated charter is available at > > http://alto.tilab.com/docs/charter.txt > > > > We've added the last bullet list -- reproduce here -- based > > on the list discussion: > > > > - A discovery mechanism for locating nearby hosts the querying node > > may not be aware of. In certain P2P networks, hosts operating > > caches may be able to fulfill the node's needs as well as keep > > the traffic > > between peers localized. In VoIP networks, nearby hosts operating > > relays may effectively be discovered to aid a VoIP client in > > establishing multimedia communications. It is anticipated that > > if existing resource discovery mechanisms are sufficient to suit > > this purpose, then the WG will produce one or more documents > > describing how these discovery mechanisms may be used to > > effectively find the peers. The discovery mechanism can be > > executed in the clients as well as in the oracle. To allow > > clients that prefer the oracle to provide such information, the > > WG will produce extensions to the oracle signaling protocol to > > enable the peer or client to transfer the desired properties > > to the oracle for subsequent lookups. > > > > Comments on it will be welcome. > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 14:54: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 DF3703A69AF; Mon, 21 Jul 2008 14:54: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 BB65F3A69B4 for ; Mon, 21 Jul 2008 14:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.027, 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 pToEStrNj1AZ for ; Mon, 21 Jul 2008 14:54:15 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 2E2B33A69A9 for ; Mon, 21 Jul 2008 14:54:14 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8770218; Mon, 21 Jul 2008 17:54:27 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 17:54:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 17:53:44 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C1CA@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <441209888.30961216650530155.JavaMail.root@dkny.pando.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Content Identifiers sent to ALTO server? Thread-Index: AcjrPjvVbdMwfRz6S2KhfAbcb0yA+AAMc4Ag References: <137868081.30911216649763195.JavaMail.root@dkny.pando.com> <441209888.30961216650530155.JavaMail.root@dkny.pando.com> From: "Woundy, Richard" To: "Laird Popkin" , "John Leslie" X-OriginalArrivalTime: 21 Jul 2008 21:54:27.0695 (UTC) FILETIME=[58B777F0:01C8EB7C] Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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 >ALTO guidance: Tracker (updated periodically, asynchronously) receives optimization rules from the ALTO server. Just to make sure I understand: in this scenario, the tracker would be the ALTO client. The ALTO client (tracker) could send ALTO requests with content IDs, and ALTO servers could respond with P2P caching servers that store that content. When peers request content from the tracker, the tracker can refer the peer to specific P2P caching servers, without additional ALTO requests. The ALTO server would be insulated from any peer's request for that content. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Laird Popkin Sent: Monday, July 21, 2008 10:29 AM To: John Leslie Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? I don't think that either of the scenarios that you list is particularly likely for p2p swarm file downloading. I'll explain why, they outline the model of ALTO that seems most valuable for that application. 1. If the client has a list of IP addresses, the list is short enough that it can test throughput with each of them all fairly quickly, so the value of ALTO is low in terms of optimizing p2p performance. This scenario makes sense for some other applications (e.g. finding a good network relay, or optimizing small swarm downloads). 2) I think that it's safe to assume that p2p networks will never send a list of all IP addresses associated with a particular content swarm to an ISP's ALTO server. This raises obvious business, privacy and legal issues, which are at best quite concerning. In addition, putting the ALTO protocol in the middle of a peer request creates unacceptable operational problems for the p2p network that would be far worse than any optimization that ALTO could provide. Let's compare a standard BitTorrent "tracker announce", a tracker announce with ALTO IP lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of 10,000 peers. standard: peer announces, Tracker responds from list in memory (one MTU each way, UDP). Fast, reliable in-memory operation. ALTO IP list: In this model, information sent into or out of ALTO is lists of IP addresses. Peer announces. Tracker sends request, with the peer address and a complete list of the 10,000 peers in the swarm, to the ALTO server. ALTO server computes optimal list and returns 50 peers. Tracker returns list to peer. Tracker does this (send swarm peer list, receive ALTO peer list) 2,000 times per second. This makes the p2p tracker slow and unreliable (by adding external communication to what is now an in-memory operation), and places a huge operational burden on the ISP's ALTO server. I suspect that ISPs would have problems with this as well, because it would effectly make their ALTO server a p2p tracker, with all that implies. ALTO guidance: Tracker (updated periodically, asynchronously) receives optimization rules from the ALTO server. Peer announces. Tracker picks optimal list from known swarm peers based on the ISP's rules, and returns 50 peers to announcing peer. This is slightly slower than a standard announce, but it's all in memory in the Tracker, and only imposes a low volume of ALTO communications. Communication is the same as the first case (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.) to update the optimization rules. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Laird Popkin" Cc: "Stas Khirman" , p2pi@ietf.org Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York Subject: Content Identifiers sent to ALTO server? Laird Popkin wrote: > > Note that content optimization can also (potentially) be > content-specific. For example, in P4P, the guidance to the p2p > networks can be 'tuned' to reflect the specific distribution of > content. This is (potentially) helpful when content is sufficiently static to flood the distribution information to all ALTO servers. This is not the general case, and might not even be the most common case in future scenarios. > Perhaps the way to phrase this is that the ALTO server MUST support > operation with no content identifiers, but ALTO clients MAY send > content identifiers? I think Stas was saying that even receiving and discarding content Identifiers could cause undesirable legal exposure to large ISPs. In any case, I agree it could. I see two very different use cases for what we're discussing here. 1. Client has a list of IP addresses, and wants to know which to try first; 2. Client doesn't have a list of IP addresses, but has a Content Identifier, and wants an ordered list of IP addresses to try. I frankly would much prefer to develop these separately. The second might well have reason to call upon the first; but the first never has any reason to make use of the second. Trying to combine both into a single protocol complicates things unnecessarily (even before the legal complications come into play). Also, the two cases deal in information best known by parties with vastly different interests in limiting distribution of that information -- up to and including a business decision to obscure or even falsify the information passed to certain other parties. The technical problems of combining both into a single protocol look easy enough, but yield no measurable benefit. The legal and information-protection problem are much more serious. -- 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 Mon Jul 21 15:01: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 D8C133A6847; Mon, 21 Jul 2008 15:01: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 ECF403A6847 for ; Mon, 21 Jul 2008 15:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.24 X-Spam-Level: X-Spam-Status: No, score=-10.24 tagged_above=-999 required=5 tests=[AWL=0.025, 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 muOe+bcJ1Pyn for ; Mon, 21 Jul 2008 15:01:47 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 8AAB43A6802 for ; Mon, 21 Jul 2008 15:01:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id DBBD3E10D51; Mon, 21 Jul 2008 18:02:18 -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 nJmZtCDLhUOO; Mon, 21 Jul 2008 18:02:16 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 2E51DE10D4E; Mon, 21 Jul 2008 18:02:16 -0400 (EDT) Date: Mon, 21 Jul 2008 18:02:16 -0400 (EDT) From: Laird Popkin To: Richard Woundy Message-ID: <53898025.35721216677736164.JavaMail.root@dkny.pando.com> In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C1CA@PACDCEXCMB06.cable.comcast.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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, exactly. That's the case (IMO) for both normal peers and p2p caches. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Woundy" To: "Laird Popkin" , "John Leslie" Cc: p2pi@ietf.org Sent: Monday, July 21, 2008 5:53:44 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Content Identifiers sent to ALTO server? >ALTO guidance: Tracker (updated periodically, asynchronously) receives optimization rules from the ALTO server. Just to make sure I understand: in this scenario, the tracker would be the ALTO client. The ALTO client (tracker) could send ALTO requests with content IDs, and ALTO servers could respond with P2P caching servers that store that content. When peers request content from the tracker, the tracker can refer the peer to specific P2P caching servers, without additional ALTO requests. The ALTO server would be insulated from any peer's request for that content. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Laird Popkin Sent: Monday, July 21, 2008 10:29 AM To: John Leslie Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? I don't think that either of the scenarios that you list is particularly likely for p2p swarm file downloading. I'll explain why, they outline the model of ALTO that seems most valuable for that application. 1. If the client has a list of IP addresses, the list is short enough that it can test throughput with each of them all fairly quickly, so the value of ALTO is low in terms of optimizing p2p performance. This scenario makes sense for some other applications (e.g. finding a good network relay, or optimizing small swarm downloads). 2) I think that it's safe to assume that p2p networks will never send a list of all IP addresses associated with a particular content swarm to an ISP's ALTO server. This raises obvious business, privacy and legal issues, which are at best quite concerning. In addition, putting the ALTO protocol in the middle of a peer request creates unacceptable operational problems for the p2p network that would be far worse than any optimization that ALTO could provide. Let's compare a standard BitTorrent "tracker announce", a tracker announce with ALTO IP lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of 10,000 peers. standard: peer announces, Tracker responds from list in memory (one MTU each way, UDP). Fast, reliable in-memory operation. ALTO IP list: In this model, information sent into or out of ALTO is lists of IP addresses. Peer announces. Tracker sends request, with the peer address and a complete list of the 10,000 peers in the swarm, to the ALTO server. ALTO server computes optimal list and returns 50 peers. Tracker returns list to peer. Tracker does this (send swarm peer list, receive ALTO peer list) 2,000 times per second. This makes the p2p tracker slow and unreliable (by adding external communication to what is now an in-memory operation), and places a huge operational burden on the ISP's ALTO server. I suspect that ISPs would have problems with this as well, because it would effectly make their ALTO server a p2p tracker, with all that implies. ALTO guidance: Tracker (updated periodically, asynchronously) receives optimization rules from the ALTO server. Peer announces. Tracker picks optimal list from known swarm peers based on the ISP's rules, and returns 50 peers to announcing peer. This is slightly slower than a standard announce, but it's all in memory in the Tracker, and only imposes a low volume of ALTO communications. Communication is the same as the first case (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.) to update the optimization rules. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Laird Popkin" Cc: "Stas Khirman" , p2pi@ietf.org Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York Subject: Content Identifiers sent to ALTO server? Laird Popkin wrote: > > Note that content optimization can also (potentially) be > content-specific. For example, in P4P, the guidance to the p2p > networks can be 'tuned' to reflect the specific distribution of > content. This is (potentially) helpful when content is sufficiently static to flood the distribution information to all ALTO servers. This is not the general case, and might not even be the most common case in future scenarios. > Perhaps the way to phrase this is that the ALTO server MUST support > operation with no content identifiers, but ALTO clients MAY send > content identifiers? I think Stas was saying that even receiving and discarding content Identifiers could cause undesirable legal exposure to large ISPs. In any case, I agree it could. I see two very different use cases for what we're discussing here. 1. Client has a list of IP addresses, and wants to know which to try first; 2. Client doesn't have a list of IP addresses, but has a Content Identifier, and wants an ordered list of IP addresses to try. I frankly would much prefer to develop these separately. The second might well have reason to call upon the first; but the first never has any reason to make use of the second. Trying to combine both into a single protocol complicates things unnecessarily (even before the legal complications come into play). Also, the two cases deal in information best known by parties with vastly different interests in limiting distribution of that information -- up to and including a business decision to obscure or even falsify the information passed to certain other parties. The technical problems of combining both into a single protocol look easy enough, but yield no measurable benefit. The legal and information-protection problem are much more serious. -- 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 Mon Jul 21 15:32: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 AAFFB3A6811; Mon, 21 Jul 2008 15:32: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 0E4883A6811 for ; Mon, 21 Jul 2008 15:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 Mp6vPbGK2D5H for ; Mon, 21 Jul 2008 15:32:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id C86B43A6802 for ; Mon, 21 Jul 2008 15:32:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id AA83733C2F; Mon, 21 Jul 2008 18:33:20 -0400 (EDT) Date: Mon, 21 Jul 2008 18:33:20 -0400 From: John Leslie To: Laird Popkin Message-ID: <20080721223320.GG64676@verdi> References: <137868081.30911216649763195.JavaMail.root@dkny.pando.com> <441209888.30961216650530155.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <441209888.30961216650530155.JavaMail.root@dkny.pando.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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: > >> I see two very different use cases for what we're discussing here. >> >> 1. Client has a list of IP addresses, and wants to know which to >> try first; >> >> 2. Client doesn't have a list of IP addresses, but has a Content >> Identifier, and wants an ordered list of IP addresses to try. > > I don't think that either of the scenarios that you list is particularly > likely for p2p swarm file downloading. I'm perfectly happy for "client" to mean the tracker itself, BTW. > I'll explain why, they outline the model of ALTO that seems most > valuable for that application. > > 1. If the client has a list of IP addresses, the list is short enough > that it can test throughput with each of them all fairly quickly, > so the value of ALTO is low in terms of optimizing p2p performance. There's no functional problem with such a list exceeding 100 IPs. Many ISPs consider 100 simultaneous TCP connections abusive. (Unless they actually overlap, I don't see how they can be tried "quickly".) > This scenario makes sense for some other applications (e.g. finding > a good network relay, or optimizing small swarm downloads). Exactly. We should not design something useful only for p2p swarm. > 2) I think that it's safe to assume that p2p networks will never send > a list of all IP addresses associated with a particular content > swarm to an ISP's ALTO server. This raises obvious business, > privacy and legal issues, which are at best quite concerning. Nonetheless, privacy is compromised as soon as they send it to a potential user. More likely, they would send an incomplete list, possibly adding non-swarm IPs to obscure things. > In addition, putting the ALTO protocol in the middle of a peer request > creates unacceptable operational problems for the p2p network that > would be far worse than any optimization that ALTO could provide. I don't follow you. I see neither "unacceptable operational problems" nor a lack of potential optimization to outweigh them. > Let's compare a standard BitTorrent "tracker announce", a tracker > announce with ALTO IP lookup" and "tracker announce with ALTO > guidance" for a peer in a swarm of 10,000 peers. Please do... > standard: peer announces, Tracker responds from list in memory (one > MTU each way, UDP). Fast, reliable in-memory operation. One Round-Trip-Time; but client must try the IPs in turn. Often it will go through several TCP connections on paths the ISP would prefer weren't used. > ALTO IP list: In this model, information sent into or out of ALTO > is lists of IP addresses. Peer announces. Tracker sends request, > with the peer address and a complete list of the 10,000 peers in > the swarm, to the ALTO server. I doubt they'd send all 10,000, but if they did we're talking no more than tens of milliseconds, still all from memory. > ALTO server computes optimal list and returns 50 peers. 50 seems enough for an end-user to actually try. > Tracker returns list to peer. Tracker does this (send swarm peer list, > receive ALTO peer list) 2,000 times per second. I _really_ doubt they'd send 10,000 IPs 2,000 times a second; but that's for them to optimize. (An obvious optimization is to determine the AS number of the end-user.) > This makes the p2p tracker slow and unreliable (by adding external > communication to what is now an in-memory operation), Any tracker that busy would no doubt cache the information useful for ordering the list, and serve from cache rather than wait for a response from the ALTO server if a similar IP pairing hadn't expired from the cache. > and places a huge operational burden on the ISP's ALTO server. ISPs _could_ manage such a load, but certainly would not choose to do so unless they saw a return on the investment. > I suspect that ISPs would have problems with this as well, because > it would effectly make their ALTO server a p2p tracker, with all that > implies. I don't follow... > ALTO guidance: Tracker (updated periodically, asynchronously) receives > optimization rules from the ALTO server. Certainly a reasonable design. > Peer announces. I don't follow... > Tracker picks optimal list from known swarm peers based on the ISP's > rules, and returns 50 peers to announcing peer. This is slightly slower > than a standard announce, but it's all in memory in the Tracker, > and only imposes a low volume of ALTO communications. > Communication is the same as the first case (one MTU each way, UDP), > plus one ALTO message every hour (or day, etc.) to update the > optimization rules. The devil is in the details... Obviously, there could be a simple rule, in the nature of always prefer ASs in this order. But that won't cover all situations, and risks causing the whole service to be ignored. A more useful rule would state that certain CIDR blocks can reach other CIDR blocks over a path with these characteristics. While this implies some computation on the part of the Tracker making the query, that can easily be cached by CIDR-block-pairs. So, you have made I case for returning CIDR length on ALTO replies. I agree that looks like a good idea. I didn't mention cacheing, because it seemed a local optimization. I still don't think it _needs_ to be in the spec, but it very likely deserves to be mentioned. (And please don't forget that ALTO will be used for more than just p2p swarms.) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 15:48:09 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 A37893A69B4; Mon, 21 Jul 2008 15:48:09 -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 D00E83A69B4 for ; Mon, 21 Jul 2008 15:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 lmMFFuQshRSW for ; Mon, 21 Jul 2008 15:48:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 69ECD3A692E for ; Mon, 21 Jul 2008 15:48:05 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KL4BN0NaU-0005h8; Mon, 21 Jul 2008 18:48:44 -0400 From: "Stas Khirman" To: "'Laird Popkin'" , "'John Leslie'" References: <137868081.30911216649763195.JavaMail.root@dkny.pando.com> <441209888.30961216650530155.JavaMail.root@dkny.pando.com> Date: Mon, 21 Jul 2008 15:48:34 -0700 Message-ID: <006701c8eb83$ee205a80$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjrPiC/DY7ZXdGEQiiZu7I3gtPK3QAQNedQ In-Reply-To: <441209888.30961216650530155.JavaMail.root@dkny.pando.com> X-Provags-ID: V01U2FsdGVkX1+M0ti7sSKWveRzs2qMrx50S5I6WJC6vvrgtBd HUtAoRXpDN0AeL4bLM5AvZpA9eU1QqL25Bx0/cuVA8pHS2roRD g/HOasTVtQNKggmVNcgJA== Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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: Monday, July 21, 2008 7:29 AM > To: John Leslie > Cc: Stas Khirman; p2pi@ietf.org > Subject: Re: Content Identifiers sent to ALTO server? > > I don't think that either of the scenarios that you list is particularly > likely for p2p swarm file downloading. I'll explain why, they outline the > model of ALTO that seems most valuable for that application. > > 1. If the client has a list of IP addresses, the list is short enough that > it can test throughput with each of them all fairly quickly, so the value > of ALTO is low in terms of optimizing p2p performance. This scenario makes > sense for some other applications (e.g. finding a good network relay, or > optimizing small swarm downloads). [Stas Khirman] Peer list is not necessary short - it is rather current BitTorrent popular trackers configurable restriction. In Gnutella you can get a few hundreds of peers on the first lookup. In eMule, it restricted (IMHO) by 300 IPs per server lookup ( you can request from multiple servers simultaneously). Plus, peers can arrive via PEX and DHT. BitTorrent specific limitation of 50-100 peers in the announce response is configurable and easy to change. Beside, majority of BitTorrent implementations can work without tracker at all - via DHT . > > 2) I think that it's safe to assume that p2p networks will never send a > list of all IP addresses associated with a particular content swarm to an > ISP's ALTO server. This raises obvious business, privacy and legal issues, > which are at best quite concerning. [Stas Khirman] If peer list is NOT associated with specific content, I see no reasons for business, privacy and legal concerns. Please elaborate if I wrong. > > In addition, putting the ALTO protocol in the middle of a peer request > creates unacceptable operational problems for the p2p network that would > be far worse than any optimization that ALTO could provide. Let's compare > a standard BitTorrent "tracker announce", a tracker announce with ALTO IP > lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of > 10,000 peers. > [Stas Khirman] If I understand correctly, you are describing P4P architecture where tracker cooperates with ISPs. It is certainly preferable model for P2P CDN where content distributed by the same entity that operate tracker (or associated third-party). This model also assumes that beside tracker, peer client has no other independent ways to discover new peers (like DHT and PEX) However, I don't see how this architecture may work in "open P2P" applications, which generate majority of traffic today. The main reasons are: - some P2Ps have no tracker at all - see Gnutella, Ares and other - All modern P2P clients able to discover new peers without direct tracker involvement. - Majority of popular open trackers operated by entities that will not cooperate with ISPs (see ThePirateBay) - Considering BitTorrent, there are only a few major application vendors who will probably cooperate with ALTO. Number of deployed trackers implementations and deployments - in 100s. It will take a lot of time until tracker owners cooperate with ALTO ( if ever) Probably, ALTO has to consider ( but not limit to) two major architectural models: - cooperative tracker (P4P architecture) - cooperative client ("oracle" architecture) > standard: peer announces, Tracker responds from list in memory (one MTU > each way, UDP). Fast, reliable in-memory operation. > > ALTO IP list: In this model, information sent into or out of ALTO is lists > of IP addresses. Peer announces. Tracker sends request, with the peer > address and a complete list of the 10,000 peers in the swarm, to the ALTO > server. ALTO server computes optimal list and returns 50 peers. Tracker > returns list to peer. Tracker does this (send swarm peer list, receive > ALTO peer list) 2,000 times per second. This makes the p2p tracker slow > and unreliable (by adding external communication to what is now an in- > memory operation), and places a huge operational burden on the ISP's ALTO > server. I suspect that ISPs would have problems with this as well, because > it would effectly make their ALTO server a p2p tracker, with all that > implies. > > ALTO guidance: Tracker (updated periodically, asynchronously) receives > optimization rules from the ALTO server. Peer announces. Tracker picks > optimal list from known swarm peers based on the ISP's rules, and returns > 50 peers to announcing peer. This is slightly slower than a standard > announce, but it's all in memory in the Tracker, and only imposes a low > volume of ALTO communications. Communication is the same as the first case > (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.) > to update the optimization rules. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "John Leslie" > To: "Laird Popkin" > Cc: "Stas Khirman" , p2pi@ietf.org > Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York > Subject: Content Identifiers sent to ALTO server? > > Laird Popkin wrote: > > > > Note that content optimization can also (potentially) be > > content-specific. For example, in P4P, the guidance to the p2p > > networks can be 'tuned' to reflect the specific distribution of > > content. > > This is (potentially) helpful when content is sufficiently static > to flood the distribution information to all ALTO servers. This is > not the general case, and might not even be the most common case in > future scenarios. > > > Perhaps the way to phrase this is that the ALTO server MUST support > > operation with no content identifiers, but ALTO clients MAY send > > content identifiers? > > I think Stas was saying that even receiving and discarding content > Identifiers could cause undesirable legal exposure to large ISPs. > In any case, I agree it could. > > I see two very different use cases for what we're discussing here. > > 1. Client has a list of IP addresses, and wants to know which to > try first; > > 2. Client doesn't have a list of IP addresses, but has a Content > Identifier, and wants an ordered list of IP addresses to try. > > I frankly would much prefer to develop these separately. The > second might well have reason to call upon the first; but the first > never has any reason to make use of the second. Trying to combine > both into a single protocol complicates things unnecessarily (even > before the legal complications come into play). > > Also, the two cases deal in information best known by parties > with vastly different interests in limiting distribution of that > information -- up to and including a business decision to obscure > or even falsify the information passed to certain other parties. > > The technical problems of combining both into a single protocol > look easy enough, but yield no measurable benefit. The legal and > information-protection problem are much more serious. > > -- > John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jul 21 17:35: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 770EA3A67E7; Mon, 21 Jul 2008 17:35: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 39F883A67E7 for ; Mon, 21 Jul 2008 17:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.024, 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 8ltuAPcQ7Tc7 for ; Mon, 21 Jul 2008 17:35:49 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 573593A63D3 for ; Mon, 21 Jul 2008 17:35:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D6C20E10D59; Mon, 21 Jul 2008 20:36:14 -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 KqXddc29LJD0; Mon, 21 Jul 2008 20:36:13 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id ED521E10D5E; Mon, 21 Jul 2008 20:36:13 -0400 (EDT) Date: Mon, 21 Jul 2008 20:36:13 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <775609371.36211216686973921.JavaMail.root@dkny.pando.com> In-Reply-To: <376051564.36191216686502245.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Content Identifiers sent to ALTO server? 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 There are misunderstandings of P4P (my fault - I've not explained it in much detail on this list). Perhaps we should discuss in front of a white board? Will you be at IETF Dublin, Stas? Comments below... (until we get to a whiteboard) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Laird Popkin" , "John Leslie" Cc: p2pi@ietf.org Sent: Monday, July 21, 2008 6:48:34 PM (GMT-0500) America/New_York Subject: RE: Content Identifiers sent to ALTO server? > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Monday, July 21, 2008 7:29 AM > To: John Leslie > Cc: Stas Khirman; p2pi@ietf.org > Subject: Re: Content Identifiers sent to ALTO server? > > I don't think that either of the scenarios that you list is particularly > likely for p2p swarm file downloading. I'll explain why, they outline the > model of ALTO that seems most valuable for that application. > > 1. If the client has a list of IP addresses, the list is short enough that > it can test throughput with each of them all fairly quickly, so the value > of ALTO is low in terms of optimizing p2p performance. This scenario makes > sense for some other applications (e.g. finding a good network relay, or > optimizing small swarm downloads). [Stas Khirman] Peer list is not necessary short - it is rather current BitTorrent popular trackers configurable restriction. In Gnutella you can get a few hundreds of peers on the first lookup. In eMule, it restricted (IMHO) by 300 IPs per server lookup ( you can request from multiple servers simultaneously). Plus, peers can arrive via PEX and DHT. BitTorrent specific limitation of 50-100 peers in the announce response is configurable and easy to change. Beside, majority of BitTorrent implementations can work without tracker at all - via DHT . [Laird] I mean 'short' in relative terms. All p2p system have p2p clients that know about a 'small' number of peers out of a 'large' population of potential peers, such that optimizing the selection of the 'small' number of peers out of the 'large' population can improve the p2p network's performance. It's also the case that if the 'small' number of new peers known to a given peer is sufficiently large, then there's also some value in optimizing the sequence of peer connections within the 'small list, though that's less of a win than optimizing the selection from the 'large' list. For example, consider a peer in a swarm with 10,000 peers. If the peer can find out about all 10,000 peers instantly, it still needs to connect to and exchange data with every peer in the swarm to measure throughput to pick the best data sources. If it can test one peer every second, it'll take 10,000 seconds to test them all to determine the best data source. An ALTO server can tell me which are the closest peers instantly, giving me a much better start point. That's not to say that the ALTO server can't be helpful in other ways. For example, it's also great if a peer that knows about 300 peers can have the ALTO server tell it which are the closest of the 300. But if those 300 are the closest out of the 10,000 that's even better, right?[/Laird] > 2) I think that it's safe to assume that p2p networks will never send a > list of all IP addresses associated with a particular content swarm to an > ISP's ALTO server. This raises obvious business, privacy and legal issues, > which are at best quite concerning. [Stas Khirman] If peer list is NOT associated with specific content, I see no reasons for business, privacy and legal concerns. Please elaborate if I wrong. [Laird] I think that we're in agreement as far as Pando goes, as we're pretty open with ISPs, but I'm not sure that assumption is true for other p2p networks. There's a lot of sensitivity in the p2p community around exposing too much information about their networks and usage, just as there's a lot of sensitivity in the ISP community around exposing too much information about their network. So perhaps I should rephrase my claim slightly: I think that it's safe to assume that not all p2p networks will agree to send a list of all IP addresses associated with a particular content swarm to an ISP's ALTO server.[/Laird] > In addition, putting the ALTO protocol in the middle of a peer request > creates unacceptable operational problems for the p2p network that would > be far worse than any optimization that ALTO could provide. Let's compare > a standard BitTorrent "tracker announce", a tracker announce with ALTO IP > lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of > 10,000 peers. > [Stas Khirman] If I understand correctly, you are describing P4P architecture where tracker cooperates with ISPs. It is certainly preferable model for P2P CDN where content distributed by the same entity that operate tracker (or associated third-party). This model also assumes that beside tracker, peer client has no other independent ways to discover new peers (like DHT and PEX) [Laird] That's not how P4P works. - P4P doesn't rely on P2P CDNs, or that the content is distributed by the same entity that operates the tracker. - P4P does not assume a tracker, or the absence of other peer discovery methods. P4P provides "good" starting peers, so that transfers are fast/cheap, but if additional peers are discovered over time, traffic will be optimized (for most p2p networks) so that if the new peers are better than the ones provided by ISP guidance, they'll be used instead. On average, however, the peers provided by ISP guidance turn out to be much better than random peers. [/Laird] However, I don't see how this architecture may work in "open P2P" applications, which generate majority of traffic today. The main reasons are: - some P2Ps have no tracker at all - see Gnutella, Ares and other [Laird] P4P doesn't rely on a tracker. It's easier to coordinate peer assignment in a tracker-based p2p network, so that's where the first P4P tests are being performed, but the same thing can (we think) be done with a trackerless p2p network. Since network intelligence is distributed in trackerless p2p networks, it's a bit more complex to figure out the proper integration, but I personally think that it'd be very interesting to distribute network guidance via DHT's, so that peers can serve as ALTO servers (of a sort) to optimize network traffic.[/Laird] - All modern P2P clients able to discover new peers without direct tracker involvement. [Laird] Of course. This is assumed in P4P. Ongoing peer discovery and traffic optimization will be good for the p2p network. If P4P provides good starting peers, that's good for the p2p network. If a peer starts with good, nearby peers, then later finds a bunch of 'random' peers, that's fine - if the good, nearby peers are faster, then the p2p network will continue to use them. If the new, further away peers are faster, we want to start using them. Luckily it's turning out that nearby peers are (on average) very good data sources, so P4P tests are showing great speedups.[/Laird] - Majority of popular open trackers operated by entities that will not cooperate with ISPs (see ThePirateBay) [Laird] There might be an issue here no matter how the data is exchanged. That is, there may be (IANAL) a liability for an ISP if they provide guidance to a 'bad' tracker, or to providing guidance to users who are using a 'bad' tracker.[/Laird] - Considering BitTorrent, there are only a few major application vendors who will probably cooperate with ALTO. Number of deployed trackers implementations and deployments - in 100s. It will take a lot of time until tracker owners cooperate with ALTO ( if ever) [Laird] ALTO is not the same thing as trackerless peer guidance, and P4P is not the same thing as tracker-based peer guidance. I'm hoping that we can find a way to express P4P (or whatever P4P evolves into over time) in ALTO.[/Laird] Probably, ALTO has to consider ( but not limit to) two major architectural models: - cooperative tracker (P4P architecture) - cooperative client ("oracle" architecture) [Laird] I agree that ALTO needs to support both tracker-based and trackerless p2p networks (and it's in the ALTO requirements...). To make sure that there isn't any confusion on this point, P4P isn't specifically tracker based, and ALTO isn't specifically client based. My hope is that the relationship between the two is that P4P is an approach to p2p network optimization that can be expressed using the ALTO protocol. [/Laird] > standard: peer announces, Tracker responds from list in memory (one MTU > each way, UDP). Fast, reliable in-memory operation. > > ALTO IP list: In this model, information sent into or out of ALTO is lists > of IP addresses. Peer announces. Tracker sends request, with the peer > address and a complete list of the 10,000 peers in the swarm, to the ALTO > server. ALTO server computes optimal list and returns 50 peers. Tracker > returns list to peer. Tracker does this (send swarm peer list, receive > ALTO peer list) 2,000 times per second. This makes the p2p tracker slow > and unreliable (by adding external communication to what is now an in- > memory operation), and places a huge operational burden on the ISP's ALTO > server. I suspect that ISPs would have problems with this as well, because > it would effectly make their ALTO server a p2p tracker, with all that > implies. > > ALTO guidance: Tracker (updated periodically, asynchronously) receives > optimization rules from the ALTO server. Peer announces. Tracker picks > optimal list from known swarm peers based on the ISP's rules, and returns > 50 peers to announcing peer. This is slightly slower than a standard > announce, but it's all in memory in the Tracker, and only imposes a low > volume of ALTO communications. Communication is the same as the first case > (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.) > to update the optimization rules. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "John Leslie" > To: "Laird Popkin" > Cc: "Stas Khirman" , p2pi@ietf.org > Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York > Subject: Content Identifiers sent to ALTO server? > > Laird Popkin wrote: > > > > Note that content optimization can also (potentially) be > > content-specific. For example, in P4P, the guidance to the p2p > > networks can be 'tuned' to reflect the specific distribution of > > content. > > This is (potentially) helpful when content is sufficiently static > to flood the distribution information to all ALTO servers. This is > not the general case, and might not even be the most common case in > future scenarios. > > > Perhaps the way to phrase this is that the ALTO server MUST support > > operation with no content identifiers, but ALTO clients MAY send > > content identifiers? > > I think Stas was saying that even receiving and discarding content > Identifiers could cause undesirable legal exposure to large ISPs. > In any case, I agree it could. > > I see two very different use cases for what we're discussing here. > > 1. Client has a list of IP addresses, and wants to know which to > try first; > > 2. Client doesn't have a list of IP addresses, but has a Content > Identifier, and wants an ordered list of IP addresses to try. > > I frankly would much prefer to develop these separately. The > second might well have reason to call upon the first; but the first > never has any reason to make use of the second. Trying to combine > both into a single protocol complicates things unnecessarily (even > before the legal complications come into play). > > Also, the two cases deal in information best known by parties > with vastly different interests in limiting distribution of that > information -- up to and including a business decision to obscure > or even falsify the information passed to certain other parties. > > The technical problems of combining both into a single protocol > look easy enough, but yield no measurable benefit. The legal and > information-protection problem are much more serious. > > -- > John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 07:28: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 4CBE63A6888; Tue, 22 Jul 2008 07:28: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 6D8F63A695D for ; Tue, 22 Jul 2008 07:28:41 -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 i0geoiiEkhrc for ; Tue, 22 Jul 2008 07:28:40 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by core3.amsl.com (Postfix) with ESMTP id 758803A677E for ; Tue, 22 Jul 2008 07:28:40 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so1320583wra.17 for ; Tue, 22 Jul 2008 07:29:19 -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:mime-version:content-type; bh=9o3Q44CS1Eb1rWyelruIBMjToQEGdA4NQj8sc9BLJnw=; b=XDntVNqx1dEo3Lo2YWsYnnTOpwa8O+nUwoKetztSmqCRkO4+31Ob73h/SOz28pF7sE 0MKcte07Rc1lln9gjReOJyyL+t2J/BNeAtihJ6oMqSmnVr961Kz7rZLQ4zZNlI2wcf8K Zx+Q3d8zvq0UCAnDK6PuVPT7HLY2Gy3hqutdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=EU/SCBssn5rWcVGHl7yz6JMz/pucTCQlA7zjsSMLUN8WlJ6AFqxxAdJTiDXsBym+Hx hM64N+MkA07Bhr7uz0hreIULEXx79IVghekKRNzwW7rMd7+2IDz7HsVKjWG3mauAtVn0 WIBOge+h1172TkX5BwDNZscIdBthZD3qqa4LY= Received: by 10.90.83.2 with SMTP id g2mr3040209agb.56.1216736958942; Tue, 22 Jul 2008 07:29:18 -0700 (PDT) Received: by 10.90.92.16 with HTTP; Tue, 22 Jul 2008 07:29:18 -0700 (PDT) Message-ID: <8bd755250807220729y87ee73ag2c2cd479da80f53c@mail.gmail.com> Date: Tue, 22 Jul 2008 22:29:18 +0800 From: "hishigh hishigh" To: p2pi@ietf.org MIME-Version: 1.0 Subject: [p2pi] New I-D:P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP) 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="===============2116845315==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2116845315== Content-Type: multipart/alternative; boundary="----=_Part_105778_15736323.1216736958925" ------=_Part_105778_15736323.1216736958925 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A new version of I-D, draft-zhang-alto-attp-01.txt has been posted to the IETF repository. http://www.ietf.org/internet-drafts/draft-zhang-alto-attp-01.txt Title: P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP) Creation_date: 2008-07-14 Abstract: Currently P2P applications have accounts for large cross-ISP traffic. This document proposes a method to reduce cross-ISP traffic by setting cooperative ISP-friendly trackers in the ISP's network.Through improving the random node selection mechanism in P2P tracker-based application, we can effectively reduce cross-ISP traffic as well as the cost of network equipments and network operation. ------=_Part_105778_15736323.1216736958925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A new version of I-D, draft-zhang-alto-attp-01.txt has been posted to the IETF repository.

http://www.ietf.org/internet-drafts/draft-zhang-alto-attp-01.txt
Title:           P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP)
Creation_date:   2008-07-14
Abstract:
Currently P2P applications have accounts for large cross-ISP traffic. 
This document proposes a method to reduce cross-ISP traffic by setting cooperative ISP-friendly trackers in the ISP's network.Through improving the random node selection mechanism in P2P tracker-based application, we can effectively reduce cross-ISP traffic as well as the cost of network equipments and network operation.
------=_Part_105778_15736323.1216736958925-- --===============2116845315== 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 --===============2116845315==-- From p2pi-bounces@ietf.org Tue Jul 22 08:19: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 967383A6993; Tue, 22 Jul 2008 08:19: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 4E41E3A6993 for ; Tue, 22 Jul 2008 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.555, 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 znnhohJJG5yp for ; Tue, 22 Jul 2008 08:19:28 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.246]) by core3.amsl.com (Postfix) with ESMTP id 1E6BD3A6987 for ; Tue, 22 Jul 2008 08:19:28 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so14168251agb.12 for ; Tue, 22 Jul 2008 08:20:05 -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:mime-version:content-type; bh=8KX2Ui1Fo3klxL3bGpNVUD+mPxuwVl6mAFVB5cpz5Ww=; b=Lj2EPOswQXc+3BQ/3QYW6y8DF2/GgnI9hys8gWtMqQlv72t6H5ZcX/3S/dfFZDW94c JxoCDhyLeNAkIvbclJR55SRPDUsux5PojNKl1SGjkdoqn0TdcnHqYXZiYC+0KfJKvem9 Pg/lDEmfMEerLN9+L6NI6vP+h88R3LGjSW+9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Hqv1l7uutBr3oNLoNwpJ8Bhq2c0Pi9BnFdTvyy76L0B7oNuKCGKr4Gj3pFaB68tziu QYmNYwKAQPF6ShegqF2Z8ZH2N0h4vCtgz8gRPOTCT5S3hmam/pJzxmGFwy/E4CZZaKdZ ZH4N7rVMgl/oO+CsGFQsyhUz9xHgeu8exdYmQ= Received: by 10.90.70.15 with SMTP id s15mr3106279aga.94.1216740005510; Tue, 22 Jul 2008 08:20:05 -0700 (PDT) Received: by 10.90.92.16 with HTTP; Tue, 22 Jul 2008 08:20:05 -0700 (PDT) Message-ID: <8bd755250807220820y47e0c0ecnf8c956e51809e6e3@mail.gmail.com> Date: Tue, 22 Jul 2008 23:20:05 +0800 From: "hishigh hishigh" To: p2pi@ietf.org MIME-Version: 1.0 Subject: [p2pi] New I-D:P2P Traffic Localization by Traceroute and 2-Means Classification 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="===============0740431222==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0740431222== Content-Type: multipart/alternative; boundary="----=_Part_106699_1770874.1216740005511" ------=_Part_106699_1770874.1216740005511 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A new version of I-D, draft-zhang-alto-tracerout-01.txt has been posted to the IETF repository. http://www.ietf.org/internet-drafts/draft-zhang-alto-tracerout-01.txt Title: P2P Traffic Localization by Traceroute and 2-Means Classification Creation_date: 2008-07-11 Abstract: Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2- Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries. ------=_Part_106699_1770874.1216740005511 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
A new version of I-D, draft-zhang-alto-tracerout-01.txt has been posted to the IETF repository.

http://www.ietf.org/internet-drafts/draft-zhang-alto-tracerout-01.txt
Title:           P2P Traffic Localization by Traceroute and 2-Means Classification 
Creation_date:   2008-07-11
Abstract:
Most P2P system performance suffers from the mismatch between the 
randomly constructed overlays topology and the underlying physical 
network topology, causing a large burden in the ISP and a long RTT 
time. This document describes how DHT overlay peers can interact with 
the routers by traceroute to get the path information, and execute 2-
Means Classification, thereafter peers leverage the DHT itself to 
build efficient "closer" cluster. This scheme only requires the 
infrastructure to enable traceroute queries.
------=_Part_106699_1770874.1216740005511-- --===============0740431222== 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 --===============0740431222==-- From p2pi-bounces@ietf.org Tue Jul 22 08:51: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 320843A6A2F; Tue, 22 Jul 2008 08:51: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 9C9B028C111 for ; Tue, 22 Jul 2008 08:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.242 X-Spam-Level: X-Spam-Status: No, score=-10.242 tagged_above=-999 required=5 tests=[AWL=0.023, 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 1lBViwVcOt60 for ; Tue, 22 Jul 2008 08:51:01 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 7BE9628C104 for ; Tue, 22 Jul 2008 08:51:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id A88C7E10AD9; Tue, 22 Jul 2008 11:51:41 -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 QWCwog2l0kuJ; Tue, 22 Jul 2008 11:51:32 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 46893E10AA0; Tue, 22 Jul 2008 11:51:32 -0400 (EDT) Date: Tue, 22 Jul 2008 11:51:32 -0400 (EDT) From: Laird Popkin To: Richard Woundy Message-ID: <2064930945.40491216741892237.JavaMail.root@dkny.pando.com> In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6019405FA@PACDCEXCMB06.cable.comcast.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 a good point. There are estimates that "legit" p2p content could rapidly grow to be much larger than "pirate" p2p content. For example, if every home on broadband watched one HD TV show a day, that would be more data than the internet moves now (or can move from any central location). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Woundy" To: "Stas Khirman" , "Laird Popkin" Cc: p2pi@ietf.org Sent: Saturday, July 19, 2008 12:38:31 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement >In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. Maybe the client could determine by out-of-band means (e.g. metadata) whether it makes sense to send the content ID in an ALTO request. There is an underlying assumption here that every P2P user is going to request at least some illicit content (copyright infringing or kiddie porn). What if P2P was primarily used for "legitimate" content distribution? How would that assumption influence our requirements? At the same time, I would caution against assuming that the lack of content identification in any ALTO request implies that the user is attempting something illegal. There are obviously many privacy concerns besides trying to evade one's legal system... -- Rich ________________________________ From: p2pi-bounces@ietf.org on behalf of Stas Khirman Sent: Sat 7/19/2008 1:13 AM To: 'Laird Popkin'; Woundy, Richard Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Friday, July 18, 2008 3:57 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > I agree with Richard - as long as content ID's are optional and > abstracted (e.g. content ID's are not Torrent ID's) I don't think there's > a privacy issue. [Stas Khirman] Laird and Richard, Thank you for clarifying this issue - I convinced that content id does not create additional problems in use case when ISP is using cache servers. Indeed, if any kind of caching implemented on ISP level, they already have privacy/DMCA questions resolved somehow. It also true for use case of P2P CDN that use P4P architecture (ALTO server polled by pTracker ). In those use cases, including content id in ALTO request makes no harm, and can be quite useful for cache location and [probably] other goals (differentiated QoS ?) However, I still worry about use case that seems to be more "popular" ( in term on number of users) : due variety of [legal] reasons, ISP does not install caching at all, but want to use ALTO-powered transport optimization for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P clients adopted ALTO). In this use case, inclusion of content id into ALTO request makes no sense at all but opens a Pandora box of potential liabilities. Making it optional with end-user manual configuration will not help - even if small part of users keep it ON, it will create a sufficient reason for DMCA-like request to filter P2P content. And it is not just hypothetical speculation - see for example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . Probably, "optionally" can be achieved if during ALTO server discovery stage ( DNS?) client receives some kind of "configuration" flag and will be mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have no idea, but assume that the better "DMCA-proof" solution is to separate "content-sensitive" functionalities (like cache discovery) from "content agnostic" ones. > > There are a number of use cases where metadata related to the content > could be useful in allowing the ALTO server to make decisions. For example, > an ISP might want to implement policies in their ALTO server such as: > > - Don't cache consumer generated content (requires being able to > differentiate between CGC and commercial content). > - Provide different guidance to different applications (requires knowledge > of p2p application). > - Provide guidance based on distribution of that content (requires ID of > that specific content). > > It's a good point that once content is cached the ISP knows a lot about > the content and its distribution. In particular, since it's participating > in the p2p network it knows the IP addresses of people exchanging the > content, whatever metadata is exposed about the content in the protocol > (e.g. size, number of files, names). And for p2p networks that don't > secure content on caches (Pando does, but some others do not) the ISP has > the content on the cache server and can inspect it directly. But this is > (IMO, IANAL) similar to the case of an HTTP cache or an email server - the > ISP is providing a service, and privacy of use of that service is > protected by policy, not by technology. > > Given all of that, ALTO can certainly be applied to content that isn't > cached, and it should preserve privacy for that content. :-) > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > >It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > I've been thinking about this since yesterday, and I'm not really sure I > agree with this statement. > > I definitely understand that there would likely be privacy concerns if > ALTO mandated content identification in its messages. Content identities > should be an optional parameter in the ALTO message exchange (if we can > agree that it should be kept at all). > > But I would think that having the content identity could help an ALTO > server make a better recommendation, at least for P2P caches. > > Consider the case when the ISP is operating an ALTO server as well as a > P2P cache. If there isn't an issue of violating customer privacy, why > would it be undesirable to reveal the content identity to the ALTO > server, when it is necessary to reveal the content identity to the P2P > caching server? > > In fact, the P2P caching server knows potentially more valuable > information than the content identity. ALTO would only know about > metadata for content, whereas the P2P cache would have a copy of the > actual content. > > To illustrate, suppose that some content's metadata (e.g. torrent) > indicates that the file is "Spiderman" and not much more. It is possible > that the file represents a DVD rip of a Spiderman movie. It is equally > possible that the file represents a digital home video of someone's > child wearing a Spiderman costume for Halloween. Examining the actual > content (as stored on the P2P cache) would help determine which scenario > is true. > > -- Rich > > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > Stas Khirman > Sent: Wednesday, July 16, 2008 5:55 PM > To: 'Laird Popkin' > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > I agree that keeping content identity out of cache location is a good > idea. > > [Stas Khirman] > Laird, > > It seems that we agree on the key point - content identity in ALTO > ["peer > selection"] request will be harmful. > > It will be very important to get confirmation/rejection of this > assumption > from ISP's representatives. > > > > That being said, cache location doesn't need to be content-specific, > > because one the p2p client connects to the caches, the caches can > > determine what they do on a content-specific basis. So ALTO could (for > > example) decide which cache servers to send to a user based on the > user's > > network location and protocol (e.g. Pando caches might run on > different > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > can > > return multiple cache servers (i.e. pools) the cache servers can > manage > > whether to cache specific content, or where to assign it, > transparently to > > ALTO, without ALTO having to know (for cache location) what content is > > assigned where. This is good for the caches, as it gives them maximum > > flexibility, without having to implement a complex state-change > mechanism > > between the cache servers and the ALTO server. > > > [Stas Khirman] > Lets review a few usage cases to decide if ALTO can locate optimal cache > without content identity. > > 1.) Cache implemented as a single virtual peer or as a set of peers with > the > same cached content. Certainly, no content knowledge needed to locate a > most > appropriate server. However, such architecture doesn't scale. > > 2.) Cache implemented as distributed set of servers where given content > may > be located in some subset of nodes. If ALTO return [ordered] list of all > known servers, it will be up to client application to poll them to > discover > which one has appropriate content. Sometimes it will work, but with > large > list it takes significant time, especially harmful for applications that > uses cache for bootstrapped playback. > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > to a > master cache (cache director). Upon client connection, master redirects > it > to a slave cache that has appropriate content. However, "master" do not > have > enough knowledge to pick "ALTO optimized" slave server from set of > appropriate ( I assume that popular content may be presented in multiple > cache locations). Master can resolve this issue with a second ALTO > lookup, > but it not different from separated "discovery" and "optimization" calls > as > I suggested. > > 4.) Cache service implemented by third party CDN ( I assume you referred > to > this specific case). In this case decision what cache to be used is > under > control on another party (CDN owner) who may have "optimization" policy > quite different then originating ISP (those diminishing value of ISP-own > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > ISP > operated CDN may use "selection" policy that increase its own profit, > but > not decrease cost of originating ISP. > > > > > _______________________________________________ > 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 Jul 22 09:00: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 9101A28C155; Tue, 22 Jul 2008 09:00: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 4EAD828B797 for ; Tue, 22 Jul 2008 09:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.022, 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 WQYBqREThXId for ; Tue, 22 Jul 2008 09:00:27 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id AD55928C15B for ; Tue, 22 Jul 2008 09:00:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 70B5CE10AA0; Tue, 22 Jul 2008 12:01:08 -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 oRYbJRV9-p1O; Tue, 22 Jul 2008 12:01:03 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 9BAA9E10AD9; Tue, 22 Jul 2008 12:01:03 -0400 (EDT) Date: Tue, 22 Jul 2008 12:01:03 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <1155737315.40611216742463611.JavaMail.root@dkny.pando.com> In-Reply-To: <007901c8e9f9$1e4a3f50$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: Richard Woundy , p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 While not required, the ALTO server could benefit from a consistent identifier of a swarm (and thus piece of content) in a number of ways. - Different treatment of different content (e.g. optimize some traffic, and not other traffic, or apply caches to some content and not other content). - Build up a 'state' of a swarm so that the ALTO server can respond more rapidly than if it has to compute each response for each request. I'll also point out that we shouldn't assume that peers (or trackers) send lists of IP's. They could (and in large swarms, should) send lists of network locations (e.g. IP prefixes, ASNs) with peer information (e.g. number of seeds and leeches) and receive back a weight set of network locations, which the p2p software would apply to specific client IP addresses. This allows for optimizations such as (for example) not needing to make an ALTO request for additional peers in the same network location, since they would all receive the same guidance. I also think that there's a level of detail about peer state that is managed by the p2p network and need not be sent to and processed by the ALTO server. For example, Pando collects extensive profiles of peers (e.g. firewalled) and uses that to optimize which peers are connected to each other. This profiling and associated logic is constantly evolving, so it does not make sense to try to standardize and and move it into ALTO servers. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Woundy" Sent: Saturday, July 19, 2008 7:42:29 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Saturday, July 19, 2008 6:04 AM > To: Stas Khirman > Cc: p2pi@ietf.org; Richard Woundy > Subject: Re: [p2pi] Charter and problem statement > > Note that content optimization can also (potentially) be content-specific. > For example, in P4P, the guidance to the p2p networks can be 'tuned' to > reflect the specific distribution of content. So for both peer selection > optimization and for cache location there are use cases that could utilize > some form of content identifier. > [Stas Khirman] Sorry, probably I missed your point - how content information can be used in peer selection (traffic optimization) ? Let's consider a use case when ALTO has no knowledge about additional peers (such as cache) to "enrich" list supplied by client for optimization. ALTO receives list of peers ( and their characteristics) from client and should send back ordered ( and probably filtered) list of the same peers. What kind of information to be used in this process? IMHO, ALTO needs to know peers characteristics (leeacher, seeder, firewalled, etc),network topology, utilization, some traffic business rules, but I fail to see how content information can be useful here at all.... _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 09:01: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 C64D43A6993; Tue, 22 Jul 2008 09:01: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 084D728B797 for ; Tue, 22 Jul 2008 09:01: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 dx-h4JlVTCvJ for ; Tue, 22 Jul 2008 09:01:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 4CBA73A6A56 for ; Tue, 22 Jul 2008 09:01:25 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KLKJM3iB0-0004j4; Tue, 22 Jul 2008 12:02:04 -0400 From: "Stas Khirman" To: "'Laird Popkin'" , "'Richard Woundy'" References: <74CCBBDF76102846AFA7B29F3A98D3F6019405FA@PACDCEXCMB06.cable.comcast.com> <2064930945.40491216741892237.JavaMail.root@dkny.pando.com> Date: Tue, 22 Jul 2008 09:01:59 -0700 Message-ID: <018801c8ec14$4864b640$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjsEtzq9OFl3qrZTUiHDimIVnnJ3wAAFs+g In-Reply-To: <2064930945.40491216741892237.JavaMail.root@dkny.pando.com> X-Provags-ID: V01U2FsdGVkX18dkXaE2ehYQNX+6QA0V+TF/f+zmGQtzEIE+oz tOXdiTtSs8fxte2FKjGTtQZfYepcQV+ajom3obQHYtChDSded3 OUkAPh3fFkMTw/etJi+EQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 will not be so optimistic.... Just a few numbers to consider: - From time of system deployment (2003?), Comcast sold 6 billions VoDs views. - iTune sold only sold 125 million TV shows and 7 million movies since its launch (2005?) - Mininova ( most popular BT portal) facilitated 3.3 billion torrents downloads ( about 80% - movies and TV shows) in 12 months (May 2007-May 2008) - ThePirateBay and IsoHunt have in total more daily visitors then Mininova (and so - facilitated downloads) > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Tuesday, July 22, 2008 8:52 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > This is a good point. There are estimates that "legit" p2p content could > rapidly grow to be much larger than "pirate" p2p content. For example, if > every home on broadband watched one HD TV show a day, that would be more > data than the internet moves now (or can move from any central location). > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Saturday, July 19, 2008 12:38:31 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >In this use case, inclusion of content id into ALTO request makes no > sense at all but opens a Pandora box of potential liabilities. Making it > optional with end-user manual configuration will not help - even if small > part of users keep it ON, it will create a sufficient reason for DMCA-like > request to filter P2P content. > > Maybe the client could determine by out-of-band means (e.g. metadata) > whether it makes sense to send the content ID in an ALTO request. > > There is an underlying assumption here that every P2P user is going to > request at least some illicit content (copyright infringing or kiddie > porn). What if P2P was primarily used for "legitimate" content > distribution? How would that assumption influence our requirements? > > At the same time, I would caution against assuming that the lack of > content identification in any ALTO request implies that the user is > attempting something illegal. There are obviously many privacy concerns > besides trying to evade one's legal system... > > -- Rich > > ________________________________ > > From: p2pi-bounces@ietf.org on behalf of Stas Khirman > Sent: Sat 7/19/2008 1:13 AM > To: 'Laird Popkin'; Woundy, Richard > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Friday, July 18, 2008 3:57 AM > > To: Richard Woundy > > Cc: p2pi@ietf.org; Stas Khirman > > Subject: Re: [p2pi] Charter and problem statement > > > > I agree with Richard - as long as content ID's are optional and > > abstracted (e.g. content ID's are not Torrent ID's) I don't think > there's > > a privacy issue. > > [Stas Khirman] > > Laird and Richard, > > Thank you for clarifying this issue - I convinced that content id does not > create additional problems in use case when ISP is using cache servers. > Indeed, if any kind of caching implemented on ISP level, they already have > privacy/DMCA questions resolved somehow. It also true for use case of P2P > CDN that use P4P architecture (ALTO server polled by pTracker ). In those > use cases, including content id in ALTO request makes no harm, and can be > quite useful for cache location and [probably] other goals (differentiated > QoS ?) > > However, I still worry about use case that seems to be more "popular" ( in > term on number of users) : due variety of [legal] reasons, ISP does not > install caching at all, but want to use ALTO-powered transport > optimization > for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P > clients adopted ALTO). > > In this use case, inclusion of content id into ALTO request makes no sense > at all but opens a Pandora box of potential liabilities. Making it > optional > with end-user manual configuration will not help - even if small part of > users keep it ON, it will create a sufficient reason for DMCA-like request > to filter P2P content. And it is not just hypothetical speculation - see > for > example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss > http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . > > Probably, "optionally" can be achieved if during ALTO server discovery > stage > ( DNS?) client receives some kind of "configuration" flag and will be > mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO > server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have > no > idea, but assume that the better "DMCA-proof" solution is to separate > "content-sensitive" functionalities (like cache discovery) from "content > agnostic" ones. > > > > > > There are a number of use cases where metadata related to the content > > could be useful in allowing the ALTO server to make decisions. For > example, > > an ISP might want to implement policies in their ALTO server such as: > > > > - Don't cache consumer generated content (requires being able to > > differentiate between CGC and commercial content). > > - Provide different guidance to different applications (requires > knowledge > > of p2p application). > > - Provide guidance based on distribution of that content (requires ID of > > that specific content). > > > > It's a good point that once content is cached the ISP knows a lot about > > the content and its distribution. In particular, since it's > participating > > in the p2p network it knows the IP addresses of people exchanging the > > content, whatever metadata is exposed about the content in the protocol > > (e.g. size, number of files, names). And for p2p networks that don't > > secure content on caches (Pando does, but some others do not) the ISP > has > > the content on the cache server and can inspect it directly. But this is > > (IMO, IANAL) similar to the case of an HTTP cache or an email server - > the > > ISP is providing a service, and privacy of use of that service is > > protected by policy, not by technology. > > > > Given all of that, ALTO can certainly be applied to content that isn't > > cached, and it should preserve privacy for that content. :-) > > > > - Laird Popkin, CTO, Pando Networks > > mobile: 646/465-0570 > > > > ----- Original Message ----- > > From: "Richard Woundy" > > To: "Stas Khirman" , "Laird Popkin" > > Cc: p2pi@ietf.org > > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > > Subject: RE: [p2pi] Charter and problem statement > > > > >It seems that we agree on the key point - content identity in ALTO > > ["peer > > selection"] request will be harmful. > > > > >It will be very important to get confirmation/rejection of this > > assumption > > from ISP's representatives. > > > > I've been thinking about this since yesterday, and I'm not really sure I > > agree with this statement. > > > > I definitely understand that there would likely be privacy concerns if > > ALTO mandated content identification in its messages. Content identities > > should be an optional parameter in the ALTO message exchange (if we can > > agree that it should be kept at all). > > > > But I would think that having the content identity could help an ALTO > > server make a better recommendation, at least for P2P caches. > > > > Consider the case when the ISP is operating an ALTO server as well as a > > P2P cache. If there isn't an issue of violating customer privacy, why > > would it be undesirable to reveal the content identity to the ALTO > > server, when it is necessary to reveal the content identity to the P2P > > caching server? > > > > In fact, the P2P caching server knows potentially more valuable > > information than the content identity. ALTO would only know about > > metadata for content, whereas the P2P cache would have a copy of the > > actual content. > > > > To illustrate, suppose that some content's metadata (e.g. torrent) > > indicates that the file is "Spiderman" and not much more. It is possible > > that the file represents a DVD rip of a Spiderman movie. It is equally > > possible that the file represents a digital home video of someone's > > child wearing a Spiderman costume for Halloween. Examining the actual > > content (as stored on the P2P cache) would help determine which scenario > > is true. > > > > -- Rich > > > > -----Original Message----- > > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > > Stas Khirman > > Sent: Wednesday, July 16, 2008 5:55 PM > > To: 'Laird Popkin' > > Cc: p2pi@ietf.org > > Subject: Re: [p2pi] Charter and problem statement > > > > > -----Original Message----- > > > From: Laird Popkin [mailto:laird@pando.com] > > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > > > I agree that keeping content identity out of cache location is a good > > idea. > > > > [Stas Khirman] > > Laird, > > > > It seems that we agree on the key point - content identity in ALTO > > ["peer > > selection"] request will be harmful. > > > > It will be very important to get confirmation/rejection of this > > assumption > > from ISP's representatives. > > > > > > > That being said, cache location doesn't need to be content-specific, > > > because one the p2p client connects to the caches, the caches can > > > determine what they do on a content-specific basis. So ALTO could (for > > > example) decide which cache servers to send to a user based on the > > user's > > > network location and protocol (e.g. Pando caches might run on > > different > > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > > can > > > return multiple cache servers (i.e. pools) the cache servers can > > manage > > > whether to cache specific content, or where to assign it, > > transparently to > > > ALTO, without ALTO having to know (for cache location) what content is > > > assigned where. This is good for the caches, as it gives them maximum > > > flexibility, without having to implement a complex state-change > > mechanism > > > between the cache servers and the ALTO server. > > > > > [Stas Khirman] > > Lets review a few usage cases to decide if ALTO can locate optimal cache > > without content identity. > > > > 1.) Cache implemented as a single virtual peer or as a set of peers with > > the > > same cached content. Certainly, no content knowledge needed to locate a > > most > > appropriate server. However, such architecture doesn't scale. > > > > 2.) Cache implemented as distributed set of servers where given content > > may > > be located in some subset of nodes. If ALTO return [ordered] list of all > > known servers, it will be up to client application to poll them to > > discover > > which one has appropriate content. Sometimes it will work, but with > > large > > list it takes significant time, especially harmful for applications that > > uses cache for bootstrapped playback. > > > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > > to a > > master cache (cache director). Upon client connection, master redirects > > it > > to a slave cache that has appropriate content. However, "master" do not > > have > > enough knowledge to pick "ALTO optimized" slave server from set of > > appropriate ( I assume that popular content may be presented in multiple > > cache locations). Master can resolve this issue with a second ALTO > > lookup, > > but it not different from separated "discovery" and "optimization" calls > > as > > I suggested. > > > > 4.) Cache service implemented by third party CDN ( I assume you referred > > to > > this specific case). In this case decision what cache to be used is > > under > > control on another party (CDN owner) who may have "optimization" policy > > quite different then originating ISP (those diminishing value of ISP-own > > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > > ISP > > operated CDN may use "selection" policy that increase its own profit, > > but > > not decrease cost of originating ISP. > > > > > > > > > > _______________________________________________ > > 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 Jul 22 09:04: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 D4E0D3A6993; Tue, 22 Jul 2008 09:04: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 D641728C155 for ; Tue, 22 Jul 2008 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.021, 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 7emARC5Q8V8q for ; Tue, 22 Jul 2008 09:04:29 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C3DD53A6993 for ; Tue, 22 Jul 2008 09:04:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 0B736E10AA0; Tue, 22 Jul 2008 12:05:10 -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 RMegNO8c-8M9; Tue, 22 Jul 2008 12:05:00 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 57ABBE10AF0; Tue, 22 Jul 2008 12:05:00 -0400 (EDT) Date: Tue, 22 Jul 2008 12:05:00 -0400 (EDT) From: Laird Popkin To: Stas Khirman Message-ID: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> In-Reply-To: <018801c8ec14$4864b640$a00d11ac@jnpr.net> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: Richard Woundy , p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Some content owners are optimistic that if they provide high quality content for free (ad supported) that they could not only grow the download volumes with people that don't currently download, but shift significant usage from piracy. I'm not saying that those estimates are guaranteed to be right, just that it's possible that they could be, and that ALTO should keep that in mind when designing the protocol. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stas Khirman" To: "Laird Popkin" , "Richard Woundy" Cc: p2pi@ietf.org Sent: Tuesday, July 22, 2008 12:01:59 PM (GMT-0500) America/New_York Subject: RE: [p2pi] Charter and problem statement I will not be so optimistic.... Just a few numbers to consider: - From time of system deployment (2003?), Comcast sold 6 billions VoDs views. - iTune sold only sold 125 million TV shows and 7 million movies since its launch (2005?) - Mininova ( most popular BT portal) facilitated 3.3 billion torrents downloads ( about 80% - movies and TV shows) in 12 months (May 2007-May 2008) - ThePirateBay and IsoHunt have in total more daily visitors then Mininova (and so - facilitated downloads) > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Tuesday, July 22, 2008 8:52 AM > To: Richard Woundy > Cc: p2pi@ietf.org; Stas Khirman > Subject: Re: [p2pi] Charter and problem statement > > This is a good point. There are estimates that "legit" p2p content could > rapidly grow to be much larger than "pirate" p2p content. For example, if > every home on broadband watched one HD TV show a day, that would be more > data than the internet moves now (or can move from any central location). > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Richard Woundy" > To: "Stas Khirman" , "Laird Popkin" > Cc: p2pi@ietf.org > Sent: Saturday, July 19, 2008 12:38:31 PM (GMT-0500) America/New_York > Subject: RE: [p2pi] Charter and problem statement > > >In this use case, inclusion of content id into ALTO request makes no > sense at all but opens a Pandora box of potential liabilities. Making it > optional with end-user manual configuration will not help - even if small > part of users keep it ON, it will create a sufficient reason for DMCA-like > request to filter P2P content. > > Maybe the client could determine by out-of-band means (e.g. metadata) > whether it makes sense to send the content ID in an ALTO request. > > There is an underlying assumption here that every P2P user is going to > request at least some illicit content (copyright infringing or kiddie > porn). What if P2P was primarily used for "legitimate" content > distribution? How would that assumption influence our requirements? > > At the same time, I would caution against assuming that the lack of > content identification in any ALTO request implies that the user is > attempting something illegal. There are obviously many privacy concerns > besides trying to evade one's legal system... > > -- Rich > > ________________________________ > > From: p2pi-bounces@ietf.org on behalf of Stas Khirman > Sent: Sat 7/19/2008 1:13 AM > To: 'Laird Popkin'; Woundy, Richard > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Charter and problem statement > > > > > -----Original Message----- > > From: Laird Popkin [mailto:laird@pando.com] > > Sent: Friday, July 18, 2008 3:57 AM > > To: Richard Woundy > > Cc: p2pi@ietf.org; Stas Khirman > > Subject: Re: [p2pi] Charter and problem statement > > > > I agree with Richard - as long as content ID's are optional and > > abstracted (e.g. content ID's are not Torrent ID's) I don't think > there's > > a privacy issue. > > [Stas Khirman] > > Laird and Richard, > > Thank you for clarifying this issue - I convinced that content id does not > create additional problems in use case when ISP is using cache servers. > Indeed, if any kind of caching implemented on ISP level, they already have > privacy/DMCA questions resolved somehow. It also true for use case of P2P > CDN that use P4P architecture (ALTO server polled by pTracker ). In those > use cases, including content id in ALTO request makes no harm, and can be > quite useful for cache location and [probably] other goals (differentiated > QoS ?) > > However, I still worry about use case that seems to be more "popular" ( in > term on number of users) : due variety of [legal] reasons, ISP does not > install caching at all, but want to use ALTO-powered transport > optimization > for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P > clients adopted ALTO). > > In this use case, inclusion of content id into ALTO request makes no sense > at all but opens a Pandora box of potential liabilities. Making it > optional > with end-user manual configuration will not help - even if small part of > users keep it ON, it will create a sufficient reason for DMCA-like request > to filter P2P content. And it is not just hypothetical speculation - see > for > example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss > http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . > > Probably, "optionally" can be achieved if during ALTO server discovery > stage > ( DNS?) client receives some kind of "configuration" flag and will be > mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO > server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have > no > idea, but assume that the better "DMCA-proof" solution is to separate > "content-sensitive" functionalities (like cache discovery) from "content > agnostic" ones. > > > > > > There are a number of use cases where metadata related to the content > > could be useful in allowing the ALTO server to make decisions. For > example, > > an ISP might want to implement policies in their ALTO server such as: > > > > - Don't cache consumer generated content (requires being able to > > differentiate between CGC and commercial content). > > - Provide different guidance to different applications (requires > knowledge > > of p2p application). > > - Provide guidance based on distribution of that content (requires ID of > > that specific content). > > > > It's a good point that once content is cached the ISP knows a lot about > > the content and its distribution. In particular, since it's > participating > > in the p2p network it knows the IP addresses of people exchanging the > > content, whatever metadata is exposed about the content in the protocol > > (e.g. size, number of files, names). And for p2p networks that don't > > secure content on caches (Pando does, but some others do not) the ISP > has > > the content on the cache server and can inspect it directly. But this is > > (IMO, IANAL) similar to the case of an HTTP cache or an email server - > the > > ISP is providing a service, and privacy of use of that service is > > protected by policy, not by technology. > > > > Given all of that, ALTO can certainly be applied to content that isn't > > cached, and it should preserve privacy for that content. :-) > > > > - Laird Popkin, CTO, Pando Networks > > mobile: 646/465-0570 > > > > ----- Original Message ----- > > From: "Richard Woundy" > > To: "Stas Khirman" , "Laird Popkin" > > Cc: p2pi@ietf.org > > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York > > Subject: RE: [p2pi] Charter and problem statement > > > > >It seems that we agree on the key point - content identity in ALTO > > ["peer > > selection"] request will be harmful. > > > > >It will be very important to get confirmation/rejection of this > > assumption > > from ISP's representatives. > > > > I've been thinking about this since yesterday, and I'm not really sure I > > agree with this statement. > > > > I definitely understand that there would likely be privacy concerns if > > ALTO mandated content identification in its messages. Content identities > > should be an optional parameter in the ALTO message exchange (if we can > > agree that it should be kept at all). > > > > But I would think that having the content identity could help an ALTO > > server make a better recommendation, at least for P2P caches. > > > > Consider the case when the ISP is operating an ALTO server as well as a > > P2P cache. If there isn't an issue of violating customer privacy, why > > would it be undesirable to reveal the content identity to the ALTO > > server, when it is necessary to reveal the content identity to the P2P > > caching server? > > > > In fact, the P2P caching server knows potentially more valuable > > information than the content identity. ALTO would only know about > > metadata for content, whereas the P2P cache would have a copy of the > > actual content. > > > > To illustrate, suppose that some content's metadata (e.g. torrent) > > indicates that the file is "Spiderman" and not much more. It is possible > > that the file represents a DVD rip of a Spiderman movie. It is equally > > possible that the file represents a digital home video of someone's > > child wearing a Spiderman costume for Halloween. Examining the actual > > content (as stored on the P2P cache) would help determine which scenario > > is true. > > > > -- Rich > > > > -----Original Message----- > > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > > Stas Khirman > > Sent: Wednesday, July 16, 2008 5:55 PM > > To: 'Laird Popkin' > > Cc: p2pi@ietf.org > > Subject: Re: [p2pi] Charter and problem statement > > > > > -----Original Message----- > > > From: Laird Popkin [mailto:laird@pando.com] > > > Sent: Wednesday, July 16, 2008 11:15 AM > > > > > > I agree that keeping content identity out of cache location is a good > > idea. > > > > [Stas Khirman] > > Laird, > > > > It seems that we agree on the key point - content identity in ALTO > > ["peer > > selection"] request will be harmful. > > > > It will be very important to get confirmation/rejection of this > > assumption > > from ISP's representatives. > > > > > > > That being said, cache location doesn't need to be content-specific, > > > because one the p2p client connects to the caches, the caches can > > > determine what they do on a content-specific basis. So ALTO could (for > > > example) decide which cache servers to send to a user based on the > > user's > > > network location and protocol (e.g. Pando caches might run on > > different > > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO > > can > > > return multiple cache servers (i.e. pools) the cache servers can > > manage > > > whether to cache specific content, or where to assign it, > > transparently to > > > ALTO, without ALTO having to know (for cache location) what content is > > > assigned where. This is good for the caches, as it gives them maximum > > > flexibility, without having to implement a complex state-change > > mechanism > > > between the cache servers and the ALTO server. > > > > > [Stas Khirman] > > Lets review a few usage cases to decide if ALTO can locate optimal cache > > without content identity. > > > > 1.) Cache implemented as a single virtual peer or as a set of peers with > > the > > same cached content. Certainly, no content knowledge needed to locate a > > most > > appropriate server. However, such architecture doesn't scale. > > > > 2.) Cache implemented as distributed set of servers where given content > > may > > be located in some subset of nodes. If ALTO return [ordered] list of all > > known servers, it will be up to client application to poll them to > > discover > > which one has appropriate content. Sometimes it will work, but with > > large > > list it takes significant time, especially harmful for applications that > > uses cache for bootstrapped playback. > > > > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer > > to a > > master cache (cache director). Upon client connection, master redirects > > it > > to a slave cache that has appropriate content. However, "master" do not > > have > > enough knowledge to pick "ALTO optimized" slave server from set of > > appropriate ( I assume that popular content may be presented in multiple > > cache locations). Master can resolve this issue with a second ALTO > > lookup, > > but it not different from separated "discovery" and "optimization" calls > > as > > I suggested. > > > > 4.) Cache service implemented by third party CDN ( I assume you referred > > to > > this specific case). In this case decision what cache to be used is > > under > > control on another party (CDN owner) who may have "optimization" policy > > quite different then originating ISP (those diminishing value of ISP-own > > ALTO service). Probably it is extreme speculation, but in theory, Tier-1 > > ISP > > operated CDN may use "selection" policy that increase its own profit, > > but > > not decrease cost of originating ISP. > > > > > > > > > > _______________________________________________ > > 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 Jul 22 09:23: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 9A22E3A6965; Tue, 22 Jul 2008 09:23: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 666393A68FB for ; Tue, 22 Jul 2008 09:23:20 -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 06R2LgSCZRxx for ; Tue, 22 Jul 2008 09:23:18 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id D69963A6881 for ; Tue, 22 Jul 2008 09:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:mime-version:to:cc:subject:references: in-reply-to:content-type:content-transfer-encoding; q=dns/txt; s= selucl; bh=2bPo/j6RCsjRJF5rsBJyfwXMMkA=; b=pG+hE2nrGf/9JWHmi8IPV 0EcnqxiWRCoByp2onjqdTINRTPikYCf2rJH9G5D8ekAItuMuVEOtFDxP4k2FmJYX M8w5to7EBa/JuWxKEpZofQ/HVMqQZFrQMxT4EKzIDpF2hoWT1whDct4fSkZuxwd0 O8NT4xtW2zxpJszP8D8R6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=GC2El 4AccfLMeWHjonouFPCbOlIcz3we3A7BzIRi3lO10nCUsbMnlDTEQQopZK0svI+qr 9TnqDmgxa/R9vA96+Dpjv4bz8pkxT+EpFx702PdO3iC2dbkcpmrijXXJ5xECqFgx 8IR27x2qQPwxlcVTfLkcXFSve4B+7ofKX9JrVA= Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 22 Jul 2008 18:23:37 +0200 (CEST) Message-ID: <48860954.1080706@uclouvain.be> Date: Tue, 22 Jul 2008 18:22:44 +0200 From: Damien Saucez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laird Popkin References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> In-Reply-To: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 0F8B5EB3CC.77495 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org, Richard Woundy Subject: Re: [p2pi] Charter and problem statement 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 Maybe it is better to discuss if ALTO has to determine legit. of content or not. IMHO, it is not a protocol design problem. Damien Saucez Laird Popkin wrote: >Some content owners are optimistic that if they provide high quality content for free (ad supported) that they could not only grow the download volumes with people that don't currently download, but shift significant usage from piracy. > >I'm not saying that those estimates are guaranteed to be right, just that it's possible that they could be, and that ALTO should keep that in mind when designing the protocol. > >- Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > >----- Original Message ----- >From: "Stas Khirman" >To: "Laird Popkin" , "Richard Woundy" >Cc: p2pi@ietf.org >Sent: Tuesday, July 22, 2008 12:01:59 PM (GMT-0500) America/New_York >Subject: RE: [p2pi] Charter and problem statement > >I will not be so optimistic.... > >Just a few numbers to consider: >- From time of system deployment (2003?), Comcast sold 6 billions VoDs >views. >- iTune sold only sold 125 million TV shows and 7 million movies since its >launch (2005?) >- Mininova ( most popular BT portal) facilitated 3.3 billion torrents >downloads ( about 80% - movies and TV shows) in 12 months (May 2007-May >2008) >- ThePirateBay and IsoHunt have in total more daily visitors then Mininova >(and so - facilitated downloads) > > > >>-----Original Message----- >>From: Laird Popkin [mailto:laird@pando.com] >>Sent: Tuesday, July 22, 2008 8:52 AM >>To: Richard Woundy >>Cc: p2pi@ietf.org; Stas Khirman >>Subject: Re: [p2pi] Charter and problem statement >> >>This is a good point. There are estimates that "legit" p2p content could >>rapidly grow to be much larger than "pirate" p2p content. For example, if >>every home on broadband watched one HD TV show a day, that would be more >>data than the internet moves now (or can move from any central location). >> >>- Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >>----- Original Message ----- >>From: "Richard Woundy" >>To: "Stas Khirman" , "Laird Popkin" >>Cc: p2pi@ietf.org >>Sent: Saturday, July 19, 2008 12:38:31 PM (GMT-0500) America/New_York >>Subject: RE: [p2pi] Charter and problem statement >> >> >> >>>In this use case, inclusion of content id into ALTO request makes no >>> >>> >>sense at all but opens a Pandora box of potential liabilities. Making it >>optional with end-user manual configuration will not help - even if small >>part of users keep it ON, it will create a sufficient reason for DMCA-like >>request to filter P2P content. >> >>Maybe the client could determine by out-of-band means (e.g. metadata) >>whether it makes sense to send the content ID in an ALTO request. >> >>There is an underlying assumption here that every P2P user is going to >>request at least some illicit content (copyright infringing or kiddie >>porn). What if P2P was primarily used for "legitimate" content >>distribution? How would that assumption influence our requirements? >> >>At the same time, I would caution against assuming that the lack of >>content identification in any ALTO request implies that the user is >>attempting something illegal. There are obviously many privacy concerns >>besides trying to evade one's legal system... >> >>-- Rich >> >>________________________________ >> >>From: p2pi-bounces@ietf.org on behalf of Stas Khirman >>Sent: Sat 7/19/2008 1:13 AM >>To: 'Laird Popkin'; Woundy, Richard >>Cc: p2pi@ietf.org >>Subject: Re: [p2pi] Charter and problem statement >> >> >> >> >> >>>-----Original Message----- >>>From: Laird Popkin [mailto:laird@pando.com] >>>Sent: Friday, July 18, 2008 3:57 AM >>>To: Richard Woundy >>>Cc: p2pi@ietf.org; Stas Khirman >>>Subject: Re: [p2pi] Charter and problem statement >>> >>>I agree with Richard - as long as content ID's are optional and >>>abstracted (e.g. content ID's are not Torrent ID's) I don't think >>> >>> >>there's >> >> >>>a privacy issue. >>> >>> >>[Stas Khirman] >> >>Laird and Richard, >> >>Thank you for clarifying this issue - I convinced that content id does not >>create additional problems in use case when ISP is using cache servers. >>Indeed, if any kind of caching implemented on ISP level, they already have >>privacy/DMCA questions resolved somehow. It also true for use case of P2P >>CDN that use P4P architecture (ALTO server polled by pTracker ). In those >>use cases, including content id in ALTO request makes no harm, and can be >>quite useful for cache location and [probably] other goals (differentiated >>QoS ?) >> >>However, I still worry about use case that seems to be more "popular" ( in >>term on number of users) : due variety of [legal] reasons, ISP does not >>install caching at all, but want to use ALTO-powered transport >>optimization >>for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P >>clients adopted ALTO). >> >>In this use case, inclusion of content id into ALTO request makes no sense >>at all but opens a Pandora box of potential liabilities. Making it >>optional >>with end-user manual configuration will not help - even if small part of >>users keep it ON, it will create a sufficient reason for DMCA-like request >>to filter P2P content. And it is not just hypothetical speculation - see >>for >>example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss >>http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ . >> >>Probably, "optionally" can be achieved if during ALTO server discovery >>stage >>( DNS?) client receives some kind of "configuration" flag and will be >>mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO >>server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have >>no >>idea, but assume that the better "DMCA-proof" solution is to separate >>"content-sensitive" functionalities (like cache discovery) from "content >>agnostic" ones. >> >> >> >> >>>There are a number of use cases where metadata related to the content >>>could be useful in allowing the ALTO server to make decisions. For >>> >>> >>example, >> >> >>>an ISP might want to implement policies in their ALTO server such as: >>> >>>- Don't cache consumer generated content (requires being able to >>>differentiate between CGC and commercial content). >>>- Provide different guidance to different applications (requires >>> >>> >>knowledge >> >> >>>of p2p application). >>>- Provide guidance based on distribution of that content (requires ID of >>>that specific content). >>> >>>It's a good point that once content is cached the ISP knows a lot about >>>the content and its distribution. In particular, since it's >>> >>> >>participating >> >> >>>in the p2p network it knows the IP addresses of people exchanging the >>>content, whatever metadata is exposed about the content in the protocol >>>(e.g. size, number of files, names). And for p2p networks that don't >>>secure content on caches (Pando does, but some others do not) the ISP >>> >>> >>has >> >> >>>the content on the cache server and can inspect it directly. But this is >>>(IMO, IANAL) similar to the case of an HTTP cache or an email server - >>> >>> >>the >> >> >>>ISP is providing a service, and privacy of use of that service is >>>protected by policy, not by technology. >>> >>>Given all of that, ALTO can certainly be applied to content that isn't >>>cached, and it should preserve privacy for that content. :-) >>> >>>- Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>>----- Original Message ----- >>>From: "Richard Woundy" >>>To: "Stas Khirman" , "Laird Popkin" >>>Cc: p2pi@ietf.org >>>Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York >>>Subject: RE: [p2pi] Charter and problem statement >>> >>> >>> >>>>It seems that we agree on the key point - content identity in ALTO >>>> >>>> >>>["peer >>>selection"] request will be harmful. >>> >>> >>> >>>>It will be very important to get confirmation/rejection of this >>>> >>>> >>>assumption >>>from ISP's representatives. >>> >>>I've been thinking about this since yesterday, and I'm not really sure I >>>agree with this statement. >>> >>>I definitely understand that there would likely be privacy concerns if >>>ALTO mandated content identification in its messages. Content identities >>>should be an optional parameter in the ALTO message exchange (if we can >>>agree that it should be kept at all). >>> >>>But I would think that having the content identity could help an ALTO >>>server make a better recommendation, at least for P2P caches. >>> >>>Consider the case when the ISP is operating an ALTO server as well as a >>>P2P cache. If there isn't an issue of violating customer privacy, why >>>would it be undesirable to reveal the content identity to the ALTO >>>server, when it is necessary to reveal the content identity to the P2P >>>caching server? >>> >>>In fact, the P2P caching server knows potentially more valuable >>>information than the content identity. ALTO would only know about >>>metadata for content, whereas the P2P cache would have a copy of the >>>actual content. >>> >>>To illustrate, suppose that some content's metadata (e.g. torrent) >>>indicates that the file is "Spiderman" and not much more. It is possible >>>that the file represents a DVD rip of a Spiderman movie. It is equally >>>possible that the file represents a digital home video of someone's >>>child wearing a Spiderman costume for Halloween. Examining the actual >>>content (as stored on the P2P cache) would help determine which scenario >>>is true. >>> >>>-- Rich >>> >>>-----Original Message----- >>>From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of >>>Stas Khirman >>>Sent: Wednesday, July 16, 2008 5:55 PM >>>To: 'Laird Popkin' >>>Cc: p2pi@ietf.org >>>Subject: Re: [p2pi] Charter and problem statement >>> >>> >>> >>>>-----Original Message----- >>>>From: Laird Popkin [mailto:laird@pando.com] >>>>Sent: Wednesday, July 16, 2008 11:15 AM >>>> >>>>I agree that keeping content identity out of cache location is a good >>>> >>>> >>>idea. >>> >>>[Stas Khirman] >>>Laird, >>> >>>It seems that we agree on the key point - content identity in ALTO >>>["peer >>>selection"] request will be harmful. >>> >>>It will be very important to get confirmation/rejection of this >>>assumption >>>from ISP's representatives. >>> >>> >>> >>> >>>>That being said, cache location doesn't need to be content-specific, >>>>because one the p2p client connects to the caches, the caches can >>>>determine what they do on a content-specific basis. So ALTO could (for >>>>example) decide which cache servers to send to a user based on the >>>> >>>> >>>user's >>> >>> >>>>network location and protocol (e.g. Pando caches might run on >>>> >>>> >>>different >>> >>> >>>>servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO >>>> >>>> >>>can >>> >>> >>>>return multiple cache servers (i.e. pools) the cache servers can >>>> >>>> >>>manage >>> >>> >>>>whether to cache specific content, or where to assign it, >>>> >>>> >>>transparently to >>> >>> >>>>ALTO, without ALTO having to know (for cache location) what content is >>>>assigned where. This is good for the caches, as it gives them maximum >>>>flexibility, without having to implement a complex state-change >>>> >>>> >>>mechanism >>> >>> >>>>between the cache servers and the ALTO server. >>>> >>>> >>>> >>>[Stas Khirman] >>>Lets review a few usage cases to decide if ALTO can locate optimal cache >>>without content identity. >>> >>>1.) Cache implemented as a single virtual peer or as a set of peers with >>>the >>>same cached content. Certainly, no content knowledge needed to locate a >>>most >>>appropriate server. However, such architecture doesn't scale. >>> >>>2.) Cache implemented as distributed set of servers where given content >>>may >>>be located in some subset of nodes. If ALTO return [ordered] list of all >>>known servers, it will be up to client application to poll them to >>>discover >>>which one has appropriate content. Sometimes it will work, but with >>>large >>>list it takes significant time, especially harmful for applications that >>>uses cache for bootstrapped playback. >>> >>>3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer >>>to a >>>master cache (cache director). Upon client connection, master redirects >>>it >>>to a slave cache that has appropriate content. However, "master" do not >>>have >>>enough knowledge to pick "ALTO optimized" slave server from set of >>>appropriate ( I assume that popular content may be presented in multiple >>>cache locations). Master can resolve this issue with a second ALTO >>>lookup, >>>but it not different from separated "discovery" and "optimization" calls >>>as >>>I suggested. >>> >>>4.) Cache service implemented by third party CDN ( I assume you referred >>>to >>>this specific case). In this case decision what cache to be used is >>>under >>>control on another party (CDN owner) who may have "optimization" policy >>>quite different then originating ISP (those diminishing value of ISP-own >>>ALTO service). Probably it is extreme speculation, but in theory, Tier-1 >>>ISP >>>operated CDN may use "selection" policy that increase its own profit, >>>but >>>not decrease cost of originating ISP. >>> >>> >>> >>> >>>_______________________________________________ >>>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 Tue Jul 22 09:28: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 06FEE3A6A7D; Tue, 22 Jul 2008 09:28: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 3D4003A6A7D for ; Tue, 22 Jul 2008 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 iN0d962xZLa8 for ; Tue, 22 Jul 2008 09:28:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 396D33A69EC for ; Tue, 22 Jul 2008 09:28:26 -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 m6MGT0ct008561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 11:29:02 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6MGSt73000880; Tue, 22 Jul 2008 11:28:55 -0500 (CDT) Message-ID: <48860ACC.4040308@alcatel-lucent.com> Date: Tue, 22 Jul 2008 11:29:00 -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: Damien Saucez References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> In-Reply-To: <48860954.1080706@uclouvain.be> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Damien Saucez wrote: > Maybe it is better to discuss if ALTO has to determine legit. of content > or not. IMHO, it is not a protocol design problem. Damien: ALTO will not -- and cannot -- determine the legitimacy of the content. This is in the draft charter (see last couple of lines of http://alto.tilab.com/docs/charter.txt), plus this was also discussed at the IETF/MIT workshop. I doubt the ADs will let us progress too far if we go down the path of enforcing content legitimacy. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 22 09:33: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 374D23A6820; Tue, 22 Jul 2008 09:33: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 BE36B3A6881 for ; Tue, 22 Jul 2008 09:33: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 bRycEFZ7dU+z for ; Tue, 22 Jul 2008 09:33:04 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id F07ED3A67FD for ; Tue, 22 Jul 2008 09:33: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 m6MGXel6020656; Tue, 22 Jul 2008 09:33:40 -0700 (PDT) Message-Id: <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> From: Nicholas Weaver To: "Vijay K. Gurbani" In-Reply-To: <48860ACC.4040308@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 22 Jul 2008 09:33:40 -0700 References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Charter and problem statement 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 Jul 22, 2008, at 9:29 AM, Vijay K. Gurbani wrote: > Damien Saucez wrote: >> Maybe it is better to discuss if ALTO has to determine legit. of >> content or not. IMHO, it is not a protocol design problem. > > Damien: ALTO will not -- and cannot -- determine the legitimacy of > the content. This is in the draft charter (see last couple of > lines of http://alto.tilab.com/docs/charter.txt), plus this was > also discussed at the IETF/MIT workshop. > > I doubt the ADs will let us progress too far if we go down the > path of enforcing content legitimacy. However, can ALTO be used as an oracle to find the peers distributing illegitimate content, once an illegitimate content identifier has been discovered by the legitimate content owner? Should this be considered a requirement in any direction (MUST enable? MUST prohibit?) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 09:49: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 562753A6965; Tue, 22 Jul 2008 09:49: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 010173A6965 for ; Tue, 22 Jul 2008 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 yDSv-H8WQQPI for ; Tue, 22 Jul 2008 09:49:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CA7263A693F for ; Tue, 22 Jul 2008 09:49:21 -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 m6MGnl5I025176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 11:49:47 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6MGnftZ023067; Tue, 22 Jul 2008 11:49:42 -0500 (CDT) Message-ID: <48860FA9.6060603@alcatel-lucent.com> Date: Tue, 22 Jul 2008 11:49:45 -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: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> In-Reply-To: <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Nicholas Weaver wrote: > However, can ALTO be used as an oracle to find the peers distributing > illegitimate content, once an illegitimate content identifier has been > discovered by the legitimate content owner? Nicholas: Insofar as ALTO is a service to rank IP addresses, it will not pay attention to content. Insofar as ALTO is a service to redirect peers to caches, it will pay attention to content, but that attention is rather weak right now (i.e., finding the cache that may contain the hash of a resource being searched for.) Insofar as ALTO is a service to find the nearest "best" resource (for some value of "best"), the content may be null (the canonical example is that of finding a VoIP relay.) In the end, I don't think it is the solutions that will constrain us as much as agreeing on the problem (i.e., the need for this type of policing.) > Should this be considered a requirement in any direction (MUST enable? > MUST prohibit?) My read based on the workshop is that we should not consider such policing. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 22 09:52: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 231583A6965; Tue, 22 Jul 2008 09:52: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 C89DB3A6918 for ; Tue, 22 Jul 2008 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 cpmywbKtipp4 for ; Tue, 22 Jul 2008 09:52:30 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9789F3A6822 for ; Tue, 22 Jul 2008 09:51:44 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 09:52:23 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:51:51 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:51:51 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 12:51:50 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 16:51:49 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 09:51:24 -0700 From: Reinaldo Penno To: Nicholas Weaver , "Vijay K. Gurbani" Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjsGyzNG292RFAvmE+3oYWzwgX+yA== In-Reply-To: <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 22 Jul 2008 16:51:50.0370 (UTC) FILETIME=[3C854C20:01C8EC1B] Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 Nicholas, If ALTO could be used to track illegitimate peers, then I'm not sure ALTO will help ISPs the way they expect. And that could jeopardize the future of ALTO. We are here today because of illegal filesharing, let's not forget that, not because of legal downloads, legal content viewing, etc. Although we foresee many legitimate uses for ALTO, the amount of illegal filesharing dwarfs any other legal use of P2P. I would suggest ALTO to stay away from any content related activities as a IETF WG. Thanks, Reinaldo On 7/22/08 9:33 AM, "Nicholas Weaver" wrote: > > On Jul 22, 2008, at 9:29 AM, Vijay K. Gurbani wrote: > >> Damien Saucez wrote: >>> Maybe it is better to discuss if ALTO has to determine legit. of >>> content or not. IMHO, it is not a protocol design problem. >> >> Damien: ALTO will not -- and cannot -- determine the legitimacy of >> the content. This is in the draft charter (see last couple of >> lines of http://alto.tilab.com/docs/charter.txt), plus this was >> also discussed at the IETF/MIT workshop. >> >> I doubt the ADs will let us progress too far if we go down the >> path of enforcing content legitimacy. > > However, can ALTO be used as an oracle to find the peers distributing > illegitimate content, once an illegitimate content identifier has been > discovered by the legitimate content owner? > > Should this be considered a requirement in any direction (MUST > enable? MUST prohibit?) > > _______________________________________________ > 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 Jul 22 10:03:53 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 3F7153A68CD; Tue, 22 Jul 2008 10:03:53 -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 57E803A68CD for ; Tue, 22 Jul 2008 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Z9SIwB9pRJuc for ; Tue, 22 Jul 2008 10:03:51 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 174363A6820 for ; Tue, 22 Jul 2008 10:03:50 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 19:04:30 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 19:04:30 +0200 Received: from [10.229.8.100] (10.229.8.100) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 22 Jul 2008 19:04:29 +0200 Message-ID: <48861305.5050805@telecomitalia.it> Date: Tue, 22 Jul 2008 19:04:05 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Nicholas Weaver References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> In-Reply-To: <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 22 Jul 2008 17:04:30.0117 (UTC) FILETIME=[015D7D50:01C8EC1D] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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="===============0800280804==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0800280804== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306040700080902010502" --------------ms000306040700080902010502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicholas Weaver wrote: > However, can ALTO be used as an oracle to find the peers distributing > illegitimate content, once an illegitimate content identifier has been > discovered by the legitimate content owner? > > Should this be considered a requirement in any direction (MUST > enable? MUST prohibit?) I think this is a reasonable question. Plagiarizing the requirements draft, my answer would be that it MUST allow users not to disclose the content being exchange. -- Ciao, Enrico --------------ms000306040700080902010502 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MjIxNzA0MDVaMCMG CSqGSIb3DQEJBDEWBBQlPD74hBz0EBWfGIuTiUoPLCfL/jBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAIDKqjXO3IMh rVxFKwbW5+X27ZzBB0hcCuL7YLp+aSAC1ujreq7HsEuL51yNtmj2tZu83g0L2nAeT8YcNDGE mYQdn9rUaoYJ9WoTcW/CXRGR5ZehdtTVNx2zzjpdVOIYfNWkRHpSOfeDEoEAWCsV/xD4wAdG 2vZiKBg7UIPfbvzudpwU0+zxMxfvKOnHPL5AiqMe/8KOFjyKLFljD1kW1mwNkjJ1rFIML1JY ojdKqw/94MDdv691xFSiSs05ZN9T9mWsL97MDFr0vfyPmouQg97f+Mn8jwV9GjAOOKFSY/wR Joko5cppPgMYKvsxqVszcmVCINFh4t5CDLlLoEBRpJcAAAAAAAA= --------------ms000306040700080902010502-- --===============0800280804== 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 --===============0800280804==-- From p2pi-bounces@ietf.org Tue Jul 22 10:49: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 4F9083A6A10; Tue, 22 Jul 2008 10:49: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 BAA7E3A69A7 for ; Tue, 22 Jul 2008 10:49:31 -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 EBGk1rJw4xGI for ; Tue, 22 Jul 2008 10:49:31 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E9B393A693E for ; Tue, 22 Jul 2008 10:49:30 -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 m6MHo9o0004796; Tue, 22 Jul 2008 10:50:09 -0700 (PDT) Message-Id: <39B0DD6F-21B0-4C82-8710-8B169F72CA4B@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Enrico Marocco In-Reply-To: <48861305.5050805@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 22 Jul 2008 10:50:09 -0700 References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> <48861305.5050805@telecomitalia.it> X-Mailer: Apple Mail (2.928.1) Cc: "p2pi@ietf.org" , Nicholas Weaver Subject: Re: [p2pi] Charter and problem statement 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 Jul 22, 2008, at 10:04 AM, Enrico Marocco wrote: > Nicholas Weaver wrote: >> However, can ALTO be used as an oracle to find the peers distributing >> illegitimate content, once an illegitimate content identifier has >> been >> discovered by the legitimate content owner? >> >> Should this be considered a requirement in any direction (MUST >> enable? MUST prohibit?) > > I think this is a reasonable question. Plagiarizing the requirements > draft, my answer would be that it MUST allow users not to disclose the > content being exchange. There may be an inherent conflict here, however: If the user doesn't disclose a content/group/swarm identifier, then other peers can't find the user who's interested in the same content identifier, which may reduce effectiveness considerably. If the user does disclose a content/group/swarm identifier, then other peers can find the user who's interested in the same content identifier, which may enable a large information leakage. If some ISP in cooperating with the MP/RIAA is running an ALTO server, even if the clients don't connect directly, the trackers which query it (or arbitrary peers, in a trackerless system) may be able to glean interesting information based on the incoming query stream. Additionally, the information leakage's danger can really depend on the nature of the content: For both pirated material and legal pornography, the results are at least embarrassing, if not legally dangerous. For legitimate, nonpornographic content, the results of an information leak are far less severe, but still could be significant. (EG, could ALTO be used for "Nielson for IP-TV?" Would this be good or bad?) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 10:54: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 8231E3A69C8; Tue, 22 Jul 2008 10:54: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 3F6A03A6820 for ; Tue, 22 Jul 2008 10:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 1roHgVY-PlOG for ; Tue, 22 Jul 2008 10:54:39 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id EF0ED3A68F0 for ; Tue, 22 Jul 2008 10:54:12 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 10:54:52 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:54:48 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:54:48 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:54:47 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 17:54:46 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 10:54:21 -0700 From: Reinaldo Penno To: Enrico Marocco , Nicholas Weaver Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjsI/gSjP4saywcIUaNvYfQ0msHLA== In-Reply-To: <48861305.5050805@telecomitalia.it> Mime-version: 1.0 X-OriginalArrivalTime: 22 Jul 2008 17:54:47.0345 (UTC) FILETIME=[07C5F210:01C8EC24] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 thread made the think that we need more security wording on the charter. I see ALTO maybe requiring a security document considerations of its own besides the security section on each document. There is clearly an expectation of privacy from the P2P client. There is clearly an expectation from the ISP that he is not aiding (conscientiously) illegal file sharing, amongst others. Thanks, Reinaldo On 7/22/08 10:04 AM, "Enrico Marocco" wrote: > Nicholas Weaver wrote: >> However, can ALTO be used as an oracle to find the peers distributing >> illegitimate content, once an illegitimate content identifier has been >> discovered by the legitimate content owner? >> >> Should this be considered a requirement in any direction (MUST >> enable? MUST prohibit?) > > I think this is a reasonable question. Plagiarizing the requirements > draft, my answer would be that it MUST allow users not to disclose the > content being exchange. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 11:01: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 B29683A6941; Tue, 22 Jul 2008 11:01: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 9C9B33A693E for ; Tue, 22 Jul 2008 11:01:58 -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 YcnPLjEponzV for ; Tue, 22 Jul 2008 11:01:57 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id C8CB43A682B for ; Tue, 22 Jul 2008 11:01:57 -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 m6MI2cx4006849; Tue, 22 Jul 2008 11:02:38 -0700 (PDT) Message-Id: <2E424A7F-206C-4167-B9E7-7EBCCE193303@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Reinaldo Penno In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 22 Jul 2008 11:02:38 -0700 References: X-Mailer: Apple Mail (2.928.1) Cc: "p2pi@ietf.org" , Nicholas Weaver Subject: Re: [p2pi] Charter and problem statement 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 Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote: > This thread made the think that we need more security wording on the > charter. > > I see ALTO maybe requiring a security document considerations of its > own > besides the security section on each document. > > There is clearly an expectation of privacy from the P2P client. > There is > clearly an expectation from the ISP that he is not aiding > (conscientiously) > illegal file sharing, amongst others. Actually, the expectation of privacy from a P2P client might be considered illusionary. The whole point of P2P is you need to be able to discover peers, so any attacker who is authorized to participate in the P2P network (eg, able to get a Content-identifier from the tracker and therefore authorization to participate in the swarm) should be able to map at least part of the P2P network and, with sybils, generate a complete map. Thus, for access to an ALTO server, the requirement should be "get NO more information than you could obtain otherwise as a participant in the P2P network", which is a huge amount, but generally safe. ("If you know the content/network/swarm ID, you can get the peer list, because you need to be authorized already to know this identifier"). The interesting question, however, is can an ALTO node, which ISN'T necessarily authorized to participate in a swarm, gain information on a swarm based on both queries to it, and also use any transactional information it gains to contact other ALTO servers to gain information about the swarm. EG, it gets a content identifier based on a request, and then queries other ALTO servers to find out who else is participating in this content identifier. In the end, it may be necessary to write requirements on information leaking that specifically fall one-way or the other, eg, "There is NO expectation of privacy because of X, Y, Z", or "Because of the client's expectation of privacy, when such is enabled, ALTO can't do A, B, C". _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 11:20: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 853053A6972; Tue, 22 Jul 2008 11:20: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 4EF493A6972 for ; Tue, 22 Jul 2008 11:20:21 -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 Y1Y-kvl83Oxz for ; Tue, 22 Jul 2008 11:20:20 -0700 (PDT) Received: from barb.cs.washington.edu (barb.cs.washington.edu [128.208.2.42]) by core3.amsl.com (Postfix) with ESMTP id 64D1D3A6941 for ; Tue, 22 Jul 2008 11:20:20 -0700 (PDT) X-Received: from dogmatix.dyn.cs.washington.edu (dogmatix.dyn.cs.washington.edu [128.208.7.96]) (authenticated bits=0) by barb.cs.washington.edu (8.14.1/8.14.1/1.10) with ESMTP id m6MIKar9002518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jul 2008 11:20:36 -0700 (envelope-from arvind@cs.washington.edu) Message-ID: <488624F4.4000208@cs.washington.edu> Date: Tue, 22 Jul 2008 11:20:36 -0700 From: Arvind Krishnamurthy User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <2E424A7F-206C-4167-B9E7-7EBCCE193303@ICSI.Berkeley.EDU> In-Reply-To: <2E424A7F-206C-4167-B9E7-7EBCCE193303@ICSI.Berkeley.EDU> Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 This is a rather interesting discussion. Just wanted to draw attention to the design proposed by p4p (another traffic localizing system in the spirit of ALTO). Note that a system might have to satisfy both: a) p2p user privacy and b) ISP privacy. So in this regard, p4p requires that the p2p swarm information and the ISP traffic/topology information are maintained by two different entities -- one owned by the p2p system and one owned by the ISP -- and that information flow between the two entities operate at somewhat coarse granularities. For instance, when the p2p system needs some ISP-specific information, such as traffic conditions between IPs x and y, it first maps them to their corresponding PoPs (say New York and Los Angeles), and then queries the ISP's server for the current conditions between the two PoPs. Similarly, when the ISP needs to export information on topology and ISP preferences, it publishes them as a full mesh, thereby somewhat limiting the ability to reverse-engineer ISP's objectives. This is of course just a first and simple attempt at limiting information leakage, and coming up with more principled privacy-preserving approaches would be an interesting research direction. > > On Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote: > >> This thread made the think that we need more security wording on the >> charter. >> >> I see ALTO maybe requiring a security document considerations of its own >> besides the security section on each document. >> >> There is clearly an expectation of privacy from the P2P client. There is >> clearly an expectation from the ISP that he is not aiding >> (conscientiously) >> illegal file sharing, amongst others. > > Actually, the expectation of privacy from a P2P client might be > considered illusionary. > > The whole point of P2P is you need to be able to discover peers, so > any attacker who is authorized to participate in the P2P network (eg, > able to get a Content-identifier from the tracker and therefore > authorization to participate in the swarm) should be able to map at > least part of the P2P network and, with sybils, generate a complete map. > > Thus, for access to an ALTO server, the requirement should be "get NO > more information than you could obtain otherwise as a participant in > the P2P network", which is a huge amount, but generally safe. ("If > you know the content/network/swarm ID, you can get the peer list, > because you need to be authorized already to know this identifier"). > > > The interesting question, however, is can an ALTO node, which ISN'T > necessarily authorized to participate in a swarm, gain information on > a swarm based on both queries to it, and also use any transactional > information it gains to contact other ALTO servers to gain information > about the swarm. > > EG, it gets a content identifier based on a request, and then queries > other ALTO servers to find out who else is participating in this > content identifier. > > > In the end, it may be necessary to write requirements on information > leaking that specifically fall one-way or the other, eg, "There is NO > expectation of privacy because of X, Y, Z", or "Because of the > client's expectation of privacy, when such is enabled, ALTO can't do > A, B, C". > > > _______________________________________________ > 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 Jul 22 11:21: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 DD3093A68E5; Tue, 22 Jul 2008 11:21: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 635273A69A4 for ; Tue, 22 Jul 2008 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.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 VUo-2wUy48tv for ; Tue, 22 Jul 2008 11:21:29 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 1EF8C3A68E5 for ; Tue, 22 Jul 2008 11:21:05 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 11:21:06 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 11:21:21 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 14:21:11 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 18:14:49 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 11:14:24 -0700 From: Reinaldo Penno To: Nicholas Weaver Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: AcjsJsUd1Y1QI1hWDUScktbSKKxXcg== In-Reply-To: <2E424A7F-206C-4167-B9E7-7EBCCE193303@ICSI.Berkeley.EDU> Mime-version: 1.0 X-OriginalArrivalTime: 22 Jul 2008 18:21:11.0804 (UTC) FILETIME=[B82F33C0:01C8EC27] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 Nicholas, Inline.. On 7/22/08 11:02 AM, "Nicholas Weaver" wrote: > > On Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote: > >> This thread made the think that we need more security wording on the >> charter. >> >> I see ALTO maybe requiring a security document considerations of its >> own >> besides the security section on each document. >> >> There is clearly an expectation of privacy from the P2P client. >> There is >> clearly an expectation from the ISP that he is not aiding >> (conscientiously) >> illegal file sharing, amongst others. > > Actually, the expectation of privacy from a P2P client might be > considered illusionary. > > The whole point of P2P is you need to be able to discover peers, so > any attacker who is authorized to participate in the P2P network (eg, > able to get a Content-identifier from the tracker and therefore > authorization to participate in the swarm) should be able to map at > least part of the P2P network and, with sybils, generate a complete map. > > Thus, for access to an ALTO server, the requirement should be "get NO > more information than you could obtain otherwise as a participant in > the P2P network", which is a huge amount, but generally safe. ("If > you know the content/network/swarm ID, you can get the peer list, > because you need to be authorized already to know this identifier"). I agree. I see two modes of operation. One is where no content-identifiers are exchanged. The client sends a list of IP address/network locations/etc and ask the ALTO server which are the best. The query could contain IP addresses/locations spawning many different torrents/files. All the client is interested are best peers for whatever file. The other is where the client sends a info-hash or something similar and ask which peers are available/best. In this case for the ALTO server to respond it needs to have a mapping of info-has/content id to peers. > > > The interesting question, however, is can an ALTO node, which ISN'T > necessarily authorized to participate in a swarm, gain information on > a swarm based on both queries to it, and also use any transactional > information it gains to contact other ALTO servers to gain information > about the swarm. > > EG, it gets a content identifier based on a request, and then queries > other ALTO servers to find out who else is participating in this > content identifier. > Today people can use the "scrape" method and get such info from Torrent trackers. That's why there are private trackers and others. But when this information is potentially moved to an ISP/Content provider the semantics and impact of such information changes. > > In the end, it may be necessary to write requirements on information > leaking that specifically fall one-way or the other, eg, "There is NO > expectation of privacy because of X, Y, Z", or "Because of the > client's expectation of privacy, when such is enabled, ALTO can't do > A, B, C". > I would agree such wording is necessary. > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 22 11:56: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 598E63A6A7F; Tue, 22 Jul 2008 11:56: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 ECD0B3A6827 for ; Tue, 22 Jul 2008 11:56:11 -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=[AWL=0.000, 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 RgFm0KvcSkPI for ; Tue, 22 Jul 2008 11:56:08 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 8A5AE3A6A41 for ; Tue, 22 Jul 2008 11:56:07 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (unknown [10.1.3.8]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 22 Jul 2008 20:56:14 +0200 (CEST) Received: from 88.197.224.221 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Tue, 22 Jul 2008 20:56:13 +0200 (CEST) Message-ID: In-Reply-To: <48860ACC.4040308@alcatel-lucent.com> References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> Date: Tue, 22 Jul 2008 20:56:13 +0200 (CEST) From: "Damien Saucez" To: "Vijay K. Gurbani" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Squirrel authenticated, X-MailScanner-ID: 95241E9780.950BF X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org Subject: Re: [p2pi] Charter and problem statement 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 > Damien Saucez wrote: >> Maybe it is better to discuss if ALTO has to determine legit. of content >> or not. IMHO, it is not a protocol design problem. > > Damien: ALTO will not -- and cannot -- determine the legitimacy of > the content. This is in the draft charter (see last couple of > lines of http://alto.tilab.com/docs/charter.txt), plus this was > also discussed at the IETF/MIT workshop. > Yes, it is exactly what I said: it is not a protocol design problem. > I doubt the ADs will let us progress too far if we go down the > path of enforcing content legitimacy. > > Thanks, > Damien Saucez > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 22 12:22: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 E2CE53A6965; Tue, 22 Jul 2008 12:22: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 A8F6F3A69EC for ; Tue, 22 Jul 2008 12:21:59 -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 cz1-NgyHytmG for ; Tue, 22 Jul 2008 12:21:58 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 5F8C03A6965 for ; Tue, 22 Jul 2008 12:21:58 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (unknown [10.1.3.8]) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 22 Jul 2008 21:22:32 +0200 (CEST) Received: from 88.197.224.221 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Tue, 22 Jul 2008 21:22:22 +0200 (CEST) Message-ID: In-Reply-To: <488624F4.4000208@cs.washington.edu> References: <2E424A7F-206C-4167-B9E7-7EBCCE193303@ICSI.Berkeley.EDU> <488624F4.4000208@cs.washington.edu> Date: Tue, 22 Jul 2008 21:22:22 +0200 (CEST) From: "Damien Saucez" To: "Arvind Krishnamurthy" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Squirrel authenticated, X-MailScanner-ID: 428B3F00D4.A405A X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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 Arvind, What you propose can be done with a solution able to work with any kind of "identifier/locator". If the protocol is not limited to a specific kind of entity identification, you can tackle the problem by creating a ranking hierarchy: a first engine ranks P2P IDs based on P2P-related criteria. To refine the ranking, IDs can be translated into IP addresses sets and, a second engine, ranks these sets based on ISP-related criteria. This can be done with IDIPS but we'll discuss technical solutions later. The way the engines perform the ranking is layer dependent but the information dissemination can remain the same (using something like address families?). The key point of this discussion is that the ALTO protocol must be able to deal with any kind of "identifier/locator" (at least optionally) as stated by Stefano. Damien Saucez > This is a rather interesting discussion. Just wanted to draw attention > to the design proposed by p4p (another traffic localizing system in the > spirit of ALTO). > > Note that a system might have to satisfy both: a) p2p user privacy and > b) ISP privacy. > > So in this regard, p4p requires that the p2p swarm information and the > ISP traffic/topology information are maintained by two different > entities -- one owned by the p2p system and one owned by the ISP -- and > that information flow between the two entities operate at somewhat > coarse granularities. > > For instance, when the p2p system needs some ISP-specific information, > such as traffic conditions between IPs x and y, it first maps them to > their corresponding PoPs (say New York and Los Angeles), and then > queries the ISP's server for the current conditions between the two PoPs. > > Similarly, when the ISP needs to export information on topology and ISP > preferences, it publishes them as a full mesh, thereby somewhat limiting > the ability to reverse-engineer ISP's objectives. > > This is of course just a first and simple attempt at limiting > information leakage, and coming up with more principled > privacy-preserving approaches would be an interesting research direction. > > >> >> On Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote: >> >>> This thread made the think that we need more security wording on the >>> charter. >>> >>> I see ALTO maybe requiring a security document considerations of its >>> own >>> besides the security section on each document. >>> >>> There is clearly an expectation of privacy from the P2P client. There >>> is >>> clearly an expectation from the ISP that he is not aiding >>> (conscientiously) >>> illegal file sharing, amongst others. >> >> Actually, the expectation of privacy from a P2P client might be >> considered illusionary. >> >> The whole point of P2P is you need to be able to discover peers, so >> any attacker who is authorized to participate in the P2P network (eg, >> able to get a Content-identifier from the tracker and therefore >> authorization to participate in the swarm) should be able to map at >> least part of the P2P network and, with sybils, generate a complete map. >> >> Thus, for access to an ALTO server, the requirement should be "get NO >> more information than you could obtain otherwise as a participant in >> the P2P network", which is a huge amount, but generally safe. ("If >> you know the content/network/swarm ID, you can get the peer list, >> because you need to be authorized already to know this identifier"). >> >> >> The interesting question, however, is can an ALTO node, which ISN'T >> necessarily authorized to participate in a swarm, gain information on >> a swarm based on both queries to it, and also use any transactional >> information it gains to contact other ALTO servers to gain information >> about the swarm. >> >> EG, it gets a content identifier based on a request, and then queries >> other ALTO servers to find out who else is participating in this >> content identifier. >> >> >> In the end, it may be necessary to write requirements on information >> leaking that specifically fall one-way or the other, eg, "There is NO >> expectation of privacy because of X, Y, Z", or "Because of the >> client's expectation of privacy, when such is enabled, ALTO can't do >> A, B, C". >> >> >> _______________________________________________ >> 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 Jul 22 14:23: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 D53C63A6A73; Tue, 22 Jul 2008 14:23: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 BAA5D3A6A73 for ; Tue, 22 Jul 2008 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 tTd7-1aBq7vs for ; Tue, 22 Jul 2008 14:23:45 -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 BBBE03A6A54 for ; Tue, 22 Jul 2008 14:23:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1709774rvf.49 for ; Tue, 22 Jul 2008 14:24:25 -0700 (PDT) Received: by 10.115.78.1 with SMTP id f1mr4191090wal.150.1216761865239; Tue, 22 Jul 2008 14:24:25 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id c26sm9172789waa.10.2008.07.22.14.24.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jul 2008 14:24:23 -0700 (PDT) Message-Id: <2304F46B-4F80-4C06-8374-D720D25F3CFF@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <4884C313.70703@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 22 Jul 2008 14:24:21 -0700 References: <4884C313.70703@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Updated 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 This looks good to me. Thank you for listening. On Jul 21, 2008, at 10:10 AM, Vijay K. Gurbani wrote: > Folks: Enrico and I have updated the charter to reflect the caching > discussion we have had on the list over the past few days. > > The updated charter is available at > http://alto.tilab.com/docs/charter.txt > > We've added the last bullet list -- reproduce here -- based > on the list discussion: > > - A discovery mechanism for locating nearby hosts the querying node > may not be aware of. In certain P2P networks, hosts operating caches > may be able to fulfill the node's needs as well as keep the traffic > between peers localized. In VoIP networks, nearby hosts operating > relays may effectively be discovered to aid a VoIP client in > establishing multimedia communications. It is anticipated that > if existing resource discovery mechanisms are sufficient to suit > this purpose, then the WG will produce one or more documents > describing how these discovery mechanisms may be used to > effectively find the peers. The discovery mechanism can be > executed in the clients as well as in the oracle. To allow > clients that prefer the oracle to provide such information, the > WG will produce extensions to the oracle signaling protocol to > enable the peer or client to transfer the desired properties > to the oracle for subsequent lookups. > > Comments on it will be welcome. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 23 01:09: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 7B9233A6ACB; Wed, 23 Jul 2008 01:09: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 EE3233A6ACD for ; Wed, 23 Jul 2008 01:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 MM2dOH+QhST2 for ; Wed, 23 Jul 2008 01:09:04 -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 61F183A696E for ; Wed, 23 Jul 2008 01:09:04 -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 m6N89a917992; Wed, 23 Jul 2008 10:09:36 +0200 (CEST) Received: from [144.254.189.96] (dhcp-rom2-144-254-189-96.cisco.com [144.254.189.96]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6N89LA05906; Wed, 23 Jul 2008 10:09:21 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 23 Jul 2008 10:09:18 +0200 From: stefano previdi To: Damien Saucez , Arvind Krishnamurthy Message-ID: Thread-Topic: [p2pi] Charter and problem statement Thread-Index: Acjsm2d3pkRf4FiOEd2SCgAX8vOM8g== In-Reply-To: Mime-version: 1.0 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Charter and problem statement 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: Damien Saucez > > Arvind, > > What you propose can be done with a solution able to work with any kind of > "identifier/locator". If the protocol is not limited to a specific kind of > entity identification, you can tackle the problem by creating a ranking > hierarchy: a first engine ranks P2P IDs based on P2P-related criteria. To > refine the ranking, IDs can be translated into IP addresses sets and, a > second engine, ranks these sets based on ISP-related criteria. This can be > done with IDIPS but we'll discuss technical solutions later. > > The way the engines perform the ranking is layer dependent but the > information dissemination can remain the same (using something like > address families?). > > The key point of this discussion is that the ALTO protocol must be able to > deal with any kind of "identifier/locator" (at least optionally) as stated > by Stefano. yes. As written in the requirements draft, IP addresses should be one option for the ALTO ranking system. Working with application identifiers is fine too but so far the only piece of standardized information we can rely on are IP addresses (from a protocol specification perspective I don't know how stable will be an application ID encoding format). Some concerns have been raised in terms of confidentiality that would need to be disclosed (if client has to send into an ALTO request a list of IP addresses) however, I believe SPs do already know how to figure out who's doing what. So, for me, IP addresses in ALTO req/res guarantee the transparency of the protocol behavior when faced to a diversity of applications. Thanks. s. > Damien Saucez > >> This is a rather interesting discussion. Just wanted to draw attention >> to the design proposed by p4p (another traffic localizing system in the >> spirit of ALTO). >> >> Note that a system might have to satisfy both: a) p2p user privacy and >> b) ISP privacy. >> >> So in this regard, p4p requires that the p2p swarm information and the >> ISP traffic/topology information are maintained by two different >> entities -- one owned by the p2p system and one owned by the ISP -- and >> that information flow between the two entities operate at somewhat >> coarse granularities. >> >> For instance, when the p2p system needs some ISP-specific information, >> such as traffic conditions between IPs x and y, it first maps them to >> their corresponding PoPs (say New York and Los Angeles), and then >> queries the ISP's server for the current conditions between the two PoPs. >> >> Similarly, when the ISP needs to export information on topology and ISP >> preferences, it publishes them as a full mesh, thereby somewhat limiting >> the ability to reverse-engineer ISP's objectives. >> >> This is of course just a first and simple attempt at limiting >> information leakage, and coming up with more principled >> privacy-preserving approaches would be an interesting research direction. >> >> >>> >>> On Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote: >>> >>>> This thread made the think that we need more security wording on the >>>> charter. >>>> >>>> I see ALTO maybe requiring a security document considerations of its >>>> own >>>> besides the security section on each document. >>>> >>>> There is clearly an expectation of privacy from the P2P client. There >>>> is >>>> clearly an expectation from the ISP that he is not aiding >>>> (conscientiously) >>>> illegal file sharing, amongst others. >>> >>> Actually, the expectation of privacy from a P2P client might be >>> considered illusionary. >>> >>> The whole point of P2P is you need to be able to discover peers, so >>> any attacker who is authorized to participate in the P2P network (eg, >>> able to get a Content-identifier from the tracker and therefore >>> authorization to participate in the swarm) should be able to map at >>> least part of the P2P network and, with sybils, generate a complete map. >>> >>> Thus, for access to an ALTO server, the requirement should be "get NO >>> more information than you could obtain otherwise as a participant in >>> the P2P network", which is a huge amount, but generally safe. ("If >>> you know the content/network/swarm ID, you can get the peer list, >>> because you need to be authorized already to know this identifier"). >>> >>> >>> The interesting question, however, is can an ALTO node, which ISN'T >>> necessarily authorized to participate in a swarm, gain information on >>> a swarm based on both queries to it, and also use any transactional >>> information it gains to contact other ALTO servers to gain information >>> about the swarm. >>> >>> EG, it gets a content identifier based on a request, and then queries >>> other ALTO servers to find out who else is participating in this >>> content identifier. >>> >>> >>> In the end, it may be necessary to write requirements on information >>> leaking that specifically fall one-way or the other, eg, "There is NO >>> expectation of privacy because of X, Y, Z", or "Because of the >>> client's expectation of privacy, when such is enabled, ALTO can't do >>> A, B, C". >>> >>> >>> _______________________________________________ >>> 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 Jul 23 10:23: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 C8FB63A682A; Wed, 23 Jul 2008 10:23: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 B15173A6900 for ; Wed, 23 Jul 2008 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 J8U2WTwyhFW6 for ; Wed, 23 Jul 2008 10:23:29 -0700 (PDT) Received: from otm-mgo01.iij.ad.jp (otm-mgo01.iij.ad.jp [210.138.20.175]) by core3.amsl.com (Postfix) with ESMTP id D09F03A6805 for ; Wed, 23 Jul 2008 10:23:28 -0700 (PDT) Received: OTM-MO(otm-mgo01) id m6NHOBEv094031; Thu, 24 Jul 2008 02:24:11 +0900 (JST) Received: OTM-MIX(otm-mix00) id m6NHOA8a034906; Thu, 24 Jul 2008 02:24:11 +0900 (JST) Received: from [192.168.86.2] (h002n086.iij.ad.jp [192.168.86.2]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp00) id m6NHOA6c039109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jul 2008 02:24:10 +0900 (JST) Message-ID: <4887693C.9070009@iijlab.net> Date: Thu, 24 Jul 2008 02:24:12 +0900 From: "Ray S. Atarashi" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: p2pi@ietf.org Subject: [p2pi] App & Net Interaction drafts 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, I submitted individual drafts about application and network interaction discussed at the Application Area Architecture Workshop held in February. Lisa suggested me to send links of our drafts to the p2pi ML. I've not mentioned P2P in the drafts, but I'm sure it is needed to interact between P2P application and network functions. These drafts are rough proposal, I'd happy if I could have comments and talk with you in Dublin. The Model for Net and App Interaction http://www.ietf.org/internet-drafts/draft-atarashi-netappmodel-00.txt The VLAN Model for Applications http://www.ietf.org/internet-drafts/draft-ninomiya-netappvlan-00.txt Best regards, Ray Atarashi ray@iijlab.net _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 24 07:55: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 58E9C28C138; Thu, 24 Jul 2008 07:55: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 EB38028C0D8 for ; Thu, 24 Jul 2008 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 aC03+j24v7EL for ; Thu, 24 Jul 2008 07:55:36 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id CDC773A6A49 for ; Thu, 24 Jul 2008 07:55:36 -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 m6OEuGZT016282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 09:56:16 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6OEuAmJ003715; Thu, 24 Jul 2008 09:56:11 -0500 (CDT) Message-ID: <4888980E.2090205@alcatel-lucent.com> Date: Thu, 24 Jul 2008 09:56:14 -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: Laird Popkin References: <775609371.36211216686973921.JavaMail.root@dkny.pando.com> In-Reply-To: <775609371.36211216686973921.JavaMail.root@dkny.pando.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: p2pi@ietf.org Subject: [p2pi] Chalk Talks (Was: [Re: Content Identifiers sent to ALTO server?]) 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 Laird Popkin wrote: > There are misunderstandings of P4P (my fault - I've not explained it > in much detail on this list). Perhaps we should discuss in front of a > white board? Will you be at IETF Dublin, Stas? Laird: That actually may not be a bad idea. How about if we do this: pending AD approval, we can organize a night session *outside* the ALTO BoF to discuss individual solutions like P4P, IDIPS, etc. What can we hope to accomplish from this? Well, the biggest bang for the buck, in your case, is that you can provide some distilled information from the P4P experience on what ALTO should and should not do. What information has been helpful for P4P that ALTO should try to incorporate and what information should be abstracted out. The other benefit is that all of us will get up to speed on the existing state of the art in these systems. So ... Enrico and I will talk to the ADs in Dublin and if they approve, we'll arrange for a night session on Wednesday. Further logistical details will be provided during the normal BoF session on Tuesday. Those besides Laird who are interested in presenting a specific solution should contact Enrico and me. Please remember that the intent of these talks will be what can we learn from them that may prove beneficial while designing ALTO. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Thu Jul 24 15:17: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 2ABAF3A6A2D; Thu, 24 Jul 2008 15:17: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 4124B3A6A2D for ; Thu, 24 Jul 2008 15:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 wT88yiTu9sFf for ; Thu, 24 Jul 2008 15:17:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 3938E3A697A for ; Thu, 24 Jul 2008 15:17:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2625408rvf.49 for ; Thu, 24 Jul 2008 15:17:12 -0700 (PDT) Received: by 10.141.114.15 with SMTP id r15mr486566rvm.164.1216937832008; Thu, 24 Jul 2008 15:17:12 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id b8sm14734816rvf.8.2008.07.24.15.17.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jul 2008 15:17:11 -0700 (PDT) Message-Id: <51A532C3-BC30-428E-AE82-70AFA74488C0@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <4888980E.2090205@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 24 Jul 2008 15:17:08 -0700 References: <775609371.36211216686973921.JavaMail.root@dkny.pando.com> <4888980E.2090205@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Chalk Talks (Was: [Re: Content Identifiers sent to ALTO server?]) 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 If this is an informal meeting outside of the ALTO BoF, it should not require anyone's approval. I don't know if freedom of assembly is constitutionally guaranteed in Ireland, but I'm willing to risk it. If it were the first ALTO WG session, then it'd up to the ADs and the WG chairs, but it's obviously too early for that. Why don't we set up a time and get together in the bar or an otherwise empty room? Thursday night is best for me, followed by Tuesday and Wednesday. Monday doesn't work (and is before the ALTO BoF anyway). -- Stas On Jul 24, 2008, at 7:56 AM, Vijay K. Gurbani wrote: > Laird Popkin wrote: >> There are misunderstandings of P4P (my fault - I've not explained it >> in much detail on this list). Perhaps we should discuss in front of a >> white board? Will you be at IETF Dublin, Stas? > > Laird: That actually may not be a bad idea. > > How about if we do this: pending AD approval, we can organize a > night session *outside* the ALTO BoF to discuss individual > solutions like P4P, IDIPS, etc. > > What can we hope to accomplish from this? Well, the biggest bang > for the buck, in your case, is that you can provide some distilled > information from the P4P experience on what ALTO should and should > not do. What information has been helpful for P4P that ALTO > should try to incorporate and what information should be > abstracted out. The other benefit is that all of us will get up > to speed on the existing state of the art in these systems. > > So ... Enrico and I will talk to the ADs in Dublin and if they > approve, we'll arrange for a night session on Wednesday. Further > logistical details will be provided during the normal BoF > session on Tuesday. > > Those besides Laird who are interested in presenting a specific > solution should contact Enrico and me. Please remember that the > intent of these talks will be what can we learn from them that > may prove beneficial while designing ALTO. > > Thank you. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 24 20:34: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 0BA9C3A6808; Thu, 24 Jul 2008 20:34: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 B14223A68DC for ; Thu, 24 Jul 2008 20:34: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 YOvh3GgKJoru for ; Thu, 24 Jul 2008 20:34:13 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id DE4D13A6808 for ; Thu, 24 Jul 2008 20:34:12 -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 m6P3Y6IE026737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 22:34:07 -0500 (CDT) Received: from [135.244.1.160] (vkg.lra.lucent.com [135.244.1.160]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6P3Y1sR015272; Thu, 24 Jul 2008 22:34:02 -0500 (CDT) Message-ID: <488949AC.5070809@alcatel-lucent.com> Date: Thu, 24 Jul 2008 22:34:04 -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: Stanislav Shalunov References: <775609371.36211216686973921.JavaMail.root@dkny.pando.com> <4888980E.2090205@alcatel-lucent.com> <51A532C3-BC30-428E-AE82-70AFA74488C0@shlang.com> In-Reply-To: <51A532C3-BC30-428E-AE82-70AFA74488C0@shlang.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: p2pi@ietf.org Subject: Re: [p2pi] Chalk Talks (Was: [Re: Content Identifiers sent to ALTO server?]) 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 Stanislav Shalunov wrote: > If this is an informal meeting outside of the ALTO BoF, it should not > require anyone's approval. Stanislav: You're probably right, but it does not hurt to socialize it with the ADs as I am not sure what the exact expectations are. > Why don't we set up a time and get together in the bar or an otherwise > empty room? Thursday night is best for me, followed by Tuesday and > Wednesday. Monday doesn't work (and is before the ALTO BoF anyway). I can't Thu night. Tue and Wed is okay. Probably an empty room is best in case someone wants to show slides or use a white- board. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 28 00:40: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 5DDC228C1CA; Mon, 28 Jul 2008 00:40: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 91B2E28C1CA for ; Mon, 28 Jul 2008 00:40: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=[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 ljePixWn3f41 for ; Mon, 28 Jul 2008 00:40:48 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6EEB528C1C7 for ; Mon, 28 Jul 2008 00:40:48 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4P00HN5HC9NP@usaga01-in.huawei.com> for p2pi@ietf.org; Mon, 28 Jul 2008 00:40:57 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4P00M9QHC79B@usaga01-in.huawei.com> for p2pi@ietf.org; Mon, 28 Jul 2008 00:40:57 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [130.129.55.167]) by szxmc03-in.huawei.com (mshttpd); Mon, 28 Jul 2008 15:40:43 +0800 Date: Mon, 28 Jul 2008 15:40:43 +0800 From: songhaibin 64081 In-reply-to: <48860FA9.6060603@alcatel-lucent.com> To: "Vijay K. Gurbani" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <1918254994.40701216742700319.JavaMail.root@dkny.pando.com> <48860954.1080706@uclouvain.be> <48860ACC.4040308@alcatel-lucent.com> <9AB1AFC2-F29D-482B-AC98-89536A25A7CD@icsi.berkeley.edu> <48860FA9.6060603@alcatel-lucent.com> Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Charter and problem statement 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 the legality of the contents should not be considered here. -Song Haibin > Nicholas Weaver wrote: > > However, can ALTO be used as an oracle to find the peers > distributing > > illegitimate content, once an illegitimate content identifier > has been > > discovered by the legitimate content owner? > > Nicholas: Insofar as ALTO is a service to rank IP addresses, > it will not pay attention to content. Insofar as ALTO is a > service to redirect peers to caches, it will pay attention to > content, but that attention is rather weak right now (i.e., > finding the cache that may contain the hash of a resource being > searched for.) Insofar as ALTO is a service to find the > nearest "best" resource (for some value of "best"), the content > may be null (the canonical example is that of finding a VoIP > relay.) > > In the end, I don't think it is the solutions that will > constrain us as much as agreeing on the problem (i.e., the need > for this type of policing.) > > > Should this be considered a requirement in any direction (MUST > enable? > > MUST prohibit?) > > My read based on the workshop is that we should not consider such > policing. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Mon Jul 28 03: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 522813A69DD; Mon, 28 Jul 2008 03:08: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 3F4843A69B3 for ; Mon, 28 Jul 2008 03:08:03 -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 HmawswjM6ePX for ; Mon, 28 Jul 2008 03:08:02 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id BA5DA3A69B1 for ; Mon, 28 Jul 2008 03:07:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1217239686; x=1217326086; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=rTysGI8HW8bFzN1UNX+jzgwj5A/xWqtY0/yr/QD4d1kJYcV2XKDBr2pCw3lQZCnjaCTvPHqVK15S5z H0bS6P7A== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.9728491; Mon, 28 Jul 2008 06:07:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 06:07:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Chalk Talks (Was: [Re: Content Identifiers sent to ALTO server?]) Thread-Index: AcjuB1iqw524VLUwQBu6Lkp2D5Yb9QCknUJ/ From: "Peterson, Jon" To: , Cc: p2pi@ietf.org Subject: Re: [p2pi] Chalk Talks (Was: [Re: Content Identifiers sent to ALTO server?]) 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="===============1585564435==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1585564435== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F099.CDA98B4B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F099.CDA98B4B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQpQZXJzb25hbGx5LCBJJ2QgcHJlZmVyIHRoYXQgd2Uga2VlcCBjb25zaWRlcmF0aW9uIG9mIEFM VE8gZm9yIHRoaXMgd2VlayBjb25maW5lZCB0byB0aGUgQm9GLiBUaGUgY29uc2Vuc3VzIHdlIHJl YWxseSBuZWVkIHRvIGdldCB0aGlzIHdlZWsgaXMgYSBjb25zZW5zdXMgaW4gdGhlIEFMVE8gcm9v bSwgYW5kIEkgZmVhciB0aGF0IGFueSBhbW91bnQgb2YgdHV0b3JpYWwgYW5kIGNvbnNlbnN1cyBi dWlsZGluZyBtaWdodCB1bHRpbWF0ZWx5IHByb3ZlIHJlZHVuZGFudC4NCg0KVGhhdCBtdWNoIHNh aWQsIHRoZSBBRHMgb2J2aW91c2x5IHdpbGwgbm90IGltcGlnbiBvbiB0aGUgcmlnaHQgdG8gZnJl ZSBhc3NlbWJseS4gQmVhciBpbiBtaW5kIHRoYXQgaXQgbWlnaHQgYWxzbyBwcm92ZSBkaWZmaWN1 bHQgdG8gc29sdmUgZm9yIHNjaGVkdWxpbmcgYXQgdGhpcyBwb2ludC4NCg0KSm9uIFBldGVyc29u DQpOZXVTdGFyLCBJbmMuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog cDJwaS1ib3VuY2VzQGlldGYub3JnIDxwMnBpLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogU3Rhbmlz bGF2IFNoYWx1bm92IDxzaGFsdW5vdkBzaGxhbmcuY29tPg0KQ2M6IHAycGlAaWV0Zi5vcmcgPHAy cGlAaWV0Zi5vcmc+DQpTZW50OiBUaHUgSnVsIDI0IDIzOjM0OjA0IDIwMDgNClN1YmplY3Q6IFJl OiBbcDJwaV0gQ2hhbGsgVGFsa3MgKFdhczogW1JlOiBDb250ZW50IElkZW50aWZpZXJzIHNlbnQg dG8gQUxUTyBzZXJ2ZXI/XSkNCg0KU3RhbmlzbGF2IFNoYWx1bm92IHdyb3RlOg0KPiBJZiB0aGlz IGlzIGFuIGluZm9ybWFsIG1lZXRpbmcgb3V0c2lkZSBvZiB0aGUgQUxUTyBCb0YsIGl0IHNob3Vs ZCBub3QgDQo+IHJlcXVpcmUgYW55b25lJ3MgYXBwcm92YWwuICANCg0KU3RhbmlzbGF2OiBZb3Un cmUgcHJvYmFibHkgcmlnaHQsIGJ1dCBpdCBkb2VzIG5vdCBodXJ0IHRvIHNvY2lhbGl6ZQ0KaXQg d2l0aCB0aGUgQURzIGFzIEkgYW0gbm90IHN1cmUgd2hhdCB0aGUgZXhhY3QgZXhwZWN0YXRpb25z IGFyZS4NCg0KPiBXaHkgZG9uJ3Qgd2Ugc2V0IHVwIGEgdGltZSBhbmQgZ2V0IHRvZ2V0aGVyIGlu IHRoZSBiYXIgb3IgYW4gb3RoZXJ3aXNlIA0KPiBlbXB0eSByb29tPyAgVGh1cnNkYXkgbmlnaHQg aXMgYmVzdCBmb3IgbWUsIGZvbGxvd2VkIGJ5IFR1ZXNkYXkgYW5kIA0KPiBXZWRuZXNkYXkuICBN b25kYXkgZG9lc24ndCB3b3JrIChhbmQgaXMgYmVmb3JlIHRoZSBBTFRPIEJvRiBhbnl3YXkpLg0K DQpJIGNhbid0IFRodSBuaWdodC4gIFR1ZSBhbmQgV2VkIGlzIG9rYXkuICBQcm9iYWJseSBhbiBl bXB0eQ0Kcm9vbSBpcyBiZXN0IGluIGNhc2Ugc29tZW9uZSB3YW50cyB0byBzaG93IHNsaWRlcyBv ciB1c2UgYSB3aGl0ZS0NCmJvYXJkLg0KDQpUaGFua3MsDQoNCi0gdmlqYXkNCi0tIA0KVmlqYXkg Sy4gR3VyYmFuaSwgQmVsbCBMYWJvcmF0b3JpZXMsIEFsY2F0ZWwtTHVjZW50DQoyNzAxIEx1Y2Vu dCBMYW5lLCBSbS4gOUYtNTQ2LCBMaXNsZSwgSWxsaW5vaXMgNjA1MzIgKFVTQSkNCkVtYWlsOiB2 a2dAe2FsY2F0ZWwtbHVjZW50LmNvbSxiZWxsLWxhYnMuY29tLGFjbS5vcmd9DQpXV1c6ICAgaHR0 cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vYmVsbC1sYWJzDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcDJwaSBtYWlsaW5nIGxpc3QNCnAycGlAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwaQ0K ------_=_NextPart_001_01C8F099.CDA98B4B Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBbcDJwaV0g Q2hhbGsgVGFsa3MgKFdhczogW1JlOiBDb250ZW50IElkZW50aWZpZXJzIHNlbnQgdG8gQUxUTyBz ZXJ2ZXI/XSk8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRl eHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+UGVyc29uYWxseSwg SSdkIHByZWZlciB0aGF0IHdlIGtlZXAgY29uc2lkZXJhdGlvbiBvZiBBTFRPIGZvciB0aGlzIHdl ZWsgY29uZmluZWQgdG8gdGhlIEJvRi4gVGhlIGNvbnNlbnN1cyB3ZSByZWFsbHkgbmVlZCB0byBn ZXQgdGhpcyB3ZWVrIGlzIGEgY29uc2Vuc3VzIGluIHRoZSBBTFRPIHJvb20sIGFuZCBJIGZlYXIg dGhhdCBhbnkgYW1vdW50IG9mIHR1dG9yaWFsIGFuZCBjb25zZW5zdXMgYnVpbGRpbmcgbWlnaHQg dWx0aW1hdGVseSBwcm92ZSByZWR1bmRhbnQuPEJSPg0KPEJSPg0KVGhhdCBtdWNoIHNhaWQsIHRo ZSBBRHMgb2J2aW91c2x5IHdpbGwgbm90IGltcGlnbiBvbiB0aGUgcmlnaHQgdG8gZnJlZSBhc3Nl bWJseS4gQmVhciBpbiBtaW5kIHRoYXQgaXQgbWlnaHQgYWxzbyBwcm92ZSBkaWZmaWN1bHQgdG8g c29sdmUgZm9yIHNjaGVkdWxpbmcgYXQgdGhpcyBwb2ludC48QlI+DQo8QlI+DQpKb24gUGV0ZXJz b248QlI+DQpOZXVTdGFyLCBJbmMuPEJSPg0KPEJSPg0KPEJSPg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLTxCUj4NCkZyb206IHAycGktYm91bmNlc0BpZXRmLm9yZyAmbHQ7cDJwaS1ib3Vu Y2VzQGlldGYub3JnJmd0OzxCUj4NClRvOiBTdGFuaXNsYXYgU2hhbHVub3YgJmx0O3NoYWx1bm92 QHNobGFuZy5jb20mZ3Q7PEJSPg0KQ2M6IHAycGlAaWV0Zi5vcmcgJmx0O3AycGlAaWV0Zi5vcmcm Z3Q7PEJSPg0KU2VudDogVGh1IEp1bCAyNCAyMzozNDowNCAyMDA4PEJSPg0KU3ViamVjdDogUmU6 IFtwMnBpXSBDaGFsayBUYWxrcyAoV2FzOiBbUmU6IENvbnRlbnQgSWRlbnRpZmllcnMgc2VudCB0 byBBTFRPIHNlcnZlcj9dKTxCUj4NCjxCUj4NClN0YW5pc2xhdiBTaGFsdW5vdiB3cm90ZTo8QlI+ DQomZ3Q7IElmIHRoaXMgaXMgYW4gaW5mb3JtYWwgbWVldGluZyBvdXRzaWRlIG9mIHRoZSBBTFRP IEJvRiwgaXQgc2hvdWxkIG5vdDxCUj4NCiZndDsgcmVxdWlyZSBhbnlvbmUncyBhcHByb3ZhbC4m bmJzcDs8QlI+DQo8QlI+DQpTdGFuaXNsYXY6IFlvdSdyZSBwcm9iYWJseSByaWdodCwgYnV0IGl0 IGRvZXMgbm90IGh1cnQgdG8gc29jaWFsaXplPEJSPg0KaXQgd2l0aCB0aGUgQURzIGFzIEkgYW0g bm90IHN1cmUgd2hhdCB0aGUgZXhhY3QgZXhwZWN0YXRpb25zIGFyZS48QlI+DQo8QlI+DQomZ3Q7 IFdoeSBkb24ndCB3ZSBzZXQgdXAgYSB0aW1lIGFuZCBnZXQgdG9nZXRoZXIgaW4gdGhlIGJhciBv ciBhbiBvdGhlcndpc2U8QlI+DQomZ3Q7IGVtcHR5IHJvb20/Jm5ic3A7IFRodXJzZGF5IG5pZ2h0 IGlzIGJlc3QgZm9yIG1lLCBmb2xsb3dlZCBieSBUdWVzZGF5IGFuZDxCUj4NCiZndDsgV2VkbmVz ZGF5LiZuYnNwOyBNb25kYXkgZG9lc24ndCB3b3JrIChhbmQgaXMgYmVmb3JlIHRoZSBBTFRPIEJv RiBhbnl3YXkpLjxCUj4NCjxCUj4NCkkgY2FuJ3QgVGh1IG5pZ2h0LiZuYnNwOyBUdWUgYW5kIFdl ZCBpcyBva2F5LiZuYnNwOyBQcm9iYWJseSBhbiBlbXB0eTxCUj4NCnJvb20gaXMgYmVzdCBpbiBj YXNlIHNvbWVvbmUgd2FudHMgdG8gc2hvdyBzbGlkZXMgb3IgdXNlIGEgd2hpdGUtPEJSPg0KYm9h cmQuPEJSPg0KPEJSPg0KVGhhbmtzLDxCUj4NCjxCUj4NCi0gdmlqYXk8QlI+DQotLTxCUj4NClZp amF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2VudDxCUj4NCjI3 MDEgTHVjZW50IExhbmUsIFJtLiA5Ri01NDYsIExpc2xlLCBJbGxpbm9pcyA2MDUzMiAoVVNBKTxC Uj4NCkVtYWlsOiB2a2dAe2FsY2F0ZWwtbHVjZW50LmNvbSxiZWxsLWxhYnMuY29tLGFjbS5vcmd9 PEJSPg0KV1dXOiZuYnNwOyZuYnNwOyA8QSBIUkVGPSJodHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50 LmNvbS9iZWxsLWxhYnMiPmh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL2JlbGwtbGFiczwv QT48QlI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxC Uj4NCnAycGkgbWFpbGluZyBsaXN0PEJSPg0KcDJwaUBpZXRmLm9yZzxCUj4NCjxBIEhSRUY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwaSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBpPC9BPjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9C T0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C8F099.CDA98B4B-- --===============1585564435== 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 --===============1585564435==-- From p2pi-bounces@ietf.org Tue Jul 29 04:47: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 C19D03A6A93; Tue, 29 Jul 2008 04:47: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 8FC953A684B for ; Tue, 29 Jul 2008 04:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 uaBrlSZszvJa for ; Tue, 29 Jul 2008 04:47:46 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D77543A68EB for ; Tue, 29 Jul 2008 04:47:43 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 12:47:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:47:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: why i hummed no Thread-Index: AcjxcO92E9Hp4QFcT+SEiuESjhDsng== From: To: X-OriginalArrivalTime: 29 Jul 2008 11:47:54.0360 (UTC) FILETIME=[EFE73F80:01C8F170] Subject: [p2pi] why i hummed no 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 Chairs asked for feedback from the no's , so here is mine I think the general problem space - peer to peer (overlay) networks making routing choices that have bad effects on the lower layers is a very big and important problem I think it is very important that we understand what solutions we should be working towards very well as I would hate to see bright and motivated people wasting time working on the wrong things, as this could divert effort from better solutions my concern is that an oracle approach might not be terribly helpful neither the p2p ap or the network have any reason to trust each other and the goals they are trying to achieve are likely to be different - how do i know you are telling me the highest bandwidth not the lowest cost choice? the information recieved could be used in ways to harm the network - deliberatly choosing the non-preferred routes the information might influenece the p2p application, but if the actual bandwidth (or lowest delay or lowest jitter etc etc) available from a non-preferred peer is higher than that then the non-preferred peer will be used, therefore analysis is required to try and quantify the likely benefit of such a scheme. there needs to be good corrolation between the oracle output and the p2p needs. To really do the path choice thing sensibly in my mind requires dynamic information which can not be obtained from an oracle. Indeed from a provider perspective, this dynamic infomation could be more/as important also - I would want to direct you to lightly loaded links as directing you to a cheap, short high bandwidth but congested link is likely to do me more harm as well I would like to see these issues considered better before rushing into solution space Louise _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 05:34:23 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 A273C28C1F7; Tue, 29 Jul 2008 05:34: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 2D67F28C1A4 for ; Tue, 29 Jul 2008 05: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 fRTul-wXxX4s for ; Tue, 29 Jul 2008 05:34:21 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id E085828C17C for ; Tue, 29 Jul 2008 05:34:20 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (unknown [10.1.3.2]) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 29 Jul 2008 14:34:21 +0200 (CEST) Received: from 130.129.18.205 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Tue, 29 Jul 2008 14:34:15 +0200 (CEST) Message-ID: In-Reply-To: References: Date: Tue, 29 Jul 2008 14:34:15 +0200 (CEST) From: "Damien Saucez" To: louise.burness@bt.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Squirrel authenticated, X-MailScanner-ID: CDE36F050D.CAF77 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 Louise, Thanks for your feedback. comments are inline. > Chairs asked for feedback from the no's , so here is mine > > I think the general problem space - peer to peer (overlay) networks making > routing choices that have bad effects on the lower layers is a very big > and important problem > > I think it is very important that we understand what solutions we should > be working towards very well as I would hate to see bright and motivated > people wasting time working on the wrong things, as this could divert > effort from better solutions > > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each other and > the goals they are trying to achieve are likely to be different - how do i > know you are telling me the highest bandwidth not the lowest cost choice? > of course, this is why it should be optional. It is not a good point for the provider to give inaccurate information. Indeed, eventually, the client will remark that performances are better (with some application level feedback) while not using the oracle and will decide to stop using the oracle -> goto step 0! > the information recieved could be used in ways to harm the network - > deliberatly choosing the non-preferred routes > That is true, and must be added in the requirements. But systematically using a bad path is already possible thanks to looking glasses, measurements and other useful tools. > the information might influenece the p2p application, but if the actual > bandwidth (or lowest delay or lowest jitter etc etc) available from a > non-preferred peer is higher than that then the non-preferred peer will be > used, therefore analysis is required to try and quantify the likely > benefit of such a scheme. there needs to be good corrolation between the > oracle output and the p2p needs. > IMHO, the main point for the WG is to standardize a way to communicate, the optimization will depends on the implementation. And it could even open a new market with different third parties offering oracle systems (?). > To really do the path choice thing sensibly in my mind requires dynamic > information which can not be obtained from an oracle. Why dynamic information are not possible with an oracle? We did dynamic path selection with IDIPS/LISP and it works fine. > Indeed from a > provider perspective, this dynamic infomation could be more/as important > also - I would want to direct you to lightly loaded links as directing you > to a cheap, short high bandwidth but congested link is likely to do me > more harm as well > sure, the information is important for both so why not combine them in a black box a-la oracle? Seems not stupid for me to have client sending information to the oracle and the operator doing the same to the oracle. The oracle just combine information from different sources and provide this information later to who needs it (note: the oracle must take care of not being a source of information leakage between the different worlds for economical and privacy reasons). > I would like to see these issues considered better before rushing into > solution space > Except the security point you mentioned, the points have already been studied, you can find a lot of good papers talking about that. > Louise > > Cheers, Damien Saucez > > _______________________________________________ > 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 Jul 29 05:38: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 EB68328C17A; Tue, 29 Jul 2008 05:38: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 1A1D528C1A4 for ; Tue, 29 Jul 2008 05:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DOtOJ0+mr5IZ for ; Tue, 29 Jul 2008 05:38:32 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D55A428C171 for ; Tue, 29 Jul 2008 05:38:31 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 13:38:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:38:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: why i hummed no Thread-Index: AcjxcO92E9Hp4QFcT+SEiuESjhDsngAA64bi References: From: To: X-OriginalArrivalTime: 29 Jul 2008 12:38:43.0308 (UTC) FILETIME=[0937CAC0:01C8F178] Subject: Re: [p2pi] why i hummed no 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 too was one of those who "vehemently hummed" no at the BoF. Several people (including some ADs) seemed to seek to characterise those of us that hummed no as not believing that there was any sort of problem to be worked on. I feel it is important to highlight that this is NOT because I believe there is no problem to be addressed here. Nor is it because I think the IETF is not able to do work in this space. My main objection is rather that the draft charter for this BoF could be (possibly unfairly) paraphrased as "wouldn't it be nice to have an entity in the network that we could ask lots of random questions...". As Louise said below there are all sorts of potential problems with this approach. Not least the fact thaat the optimisation from the point of view of the network operator is likely to be VERY different from that of the end-user. Furthermore it seems that P2P apps such as BitTorrent are already producing near-optimal results from the point of view of the end-user and it is definitely not clear that an oracle could improve on these. The overall sense I picked up from this BoF was that a group of people had already decided that the best solution was an oracle and this BoF was menat to just ratify that decision. Having said all that I do want to encourage people to work on solutions to the "P2P problem" (note the " "...). I think much of this work could perhaps be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy" feel to a lot of the stuff we saw presented). Once we have a really clear idea of the potential use cases for an oracle, an idea of how you can incentivise both user and ISP in such a way that any information can be trusted and if the information is only that which changes relatively slowly (e.g topology, price and nature of any interconnects) then it might be worth coming back to try again. Toby Moncaster ________________________________ From: p2pi-bounces@ietf.org on behalf of louise.burness@bt.com Sent: Tue 29/07/2008 12:47 To: p2pi@ietf.org Subject: [p2pi] why i hummed no Chairs asked for feedback from the no's , so here is mine I think the general problem space - peer to peer (overlay) networks making routing choices that have bad effects on the lower layers is a very big and important problem I think it is very important that we understand what solutions we should be working towards very well as I would hate to see bright and motivated people wasting time working on the wrong things, as this could divert effort from better solutions my concern is that an oracle approach might not be terribly helpful neither the p2p ap or the network have any reason to trust each other and the goals they are trying to achieve are likely to be different - how do i know you are telling me the highest bandwidth not the lowest cost choice? the information recieved could be used in ways to harm the network - deliberatly choosing the non-preferred routes the information might influenece the p2p application, but if the actual bandwidth (or lowest delay or lowest jitter etc etc) available from a non-preferred peer is higher than that then the non-preferred peer will be used, therefore analysis is required to try and quantify the likely benefit of such a scheme. there needs to be good corrolation between the oracle output and the p2p needs. To really do the path choice thing sensibly in my mind requires dynamic information which can not be obtained from an oracle. Indeed from a provider perspective, this dynamic infomation could be more/as important also - I would want to direct you to lightly loaded links as directing you to a cheap, short high bandwidth but congested link is likely to do me more harm as well I would like to see these issues considered better before rushing into solution space Louise _______________________________________________ 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 Jul 29 05:51: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 D881C28C1C2; Tue, 29 Jul 2008 05:51: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 6C31E28C1C2 for ; Tue, 29 Jul 2008 05:51:57 -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 95-XenwspVtR for ; Tue, 29 Jul 2008 05:51:56 -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 9BD9F28C16A for ; Tue, 29 Jul 2008 05:51:56 -0700 (PDT) Received: from [130.129.18.222] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KNogR-0003aj-9E; Tue, 29 Jul 2008 05:52:07 -0700 Message-Id: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> From: Philip Levis To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 13:52:04 +0100 References: X-Mailer: Apple Mail (2.926) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 On Jul 29, 2008, at 1:38 PM, wrote: > Furthermore it seems that P2P apps such as BitTorrent are already = > producing near-optimal results from the point of view of the end- = > user and it is definitely not clear that an oracle could improve on = > these. This is decidedly untrue. Ono, one of the mentioned approaches that = uses topology information to choose peers, achieves a 31-207% = improvement in download rates.[1] Phil [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: A = practical approach to reducing cross-ISP traffic in P2P systems, To = appear in 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 Jul 29 05:52: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 1CFC528C26D; Tue, 29 Jul 2008 05:52: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 7BF3E28C26D for ; Tue, 29 Jul 2008 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 exQBrXHifB88 for ; Tue, 29 Jul 2008 05:52:39 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id DAAE528C165 for ; Tue, 29 Jul 2008 05:52:38 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1438222ywj.49 for ; Tue, 29 Jul 2008 05:52:49 -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=v6qVdnPUW1uyp10RyrmJ4CfVZM6ThundPVKkai+bzX0=; b=IEOBYuYBAOQrvs5XYeg5XVVF5tf3fAMruMgorEPCMLaYWG8sBzuaLuYmI9qTAKIGMJ K+Zo3/JrjRIgxdHHj0vyQQoqXygvamTzSzFHxfC16di/cHe4zNUfTTfhRD/T2RxK74SI S/YElQSWgqb29rOTamOxLJ/tggH+7n4u1stlk= 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=LDRPoz5lwfu6CPd9tcmbNsytKo2KwRH4JOUDG8CEIAke14C5g2z/Az5rVOc9yOE4iS Fms1yfZSjcpPO5gIBuuZvjqLjtAGBlF3GjFIeXoM3z+Ez81MO6b9QmDUglJLEgBsONmK axFGplIT9PD6z1xGtWMdfnHz8m8I9uqsQ++2Q= Received: by 10.114.46.11 with SMTP id t11mr6443828wat.211.1217335968945; Tue, 29 Jul 2008 05:52:48 -0700 (PDT) Received: by 10.151.85.12 with HTTP; Tue, 29 Jul 2008 05:52:48 -0700 (PDT) Message-ID: <241bc2150807290552peebbea9lb0067b2a9133a989@mail.gmail.com> Date: Tue, 29 Jul 2008 05:52:48 -0700 From: "=?ISO-8859-2?Q?Ula=BA_C._Kozat?=" To: toby.moncaster@bt.com In-Reply-To: MIME-Version: 1.0 References: Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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="===============0339401964==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0339401964== Content-Type: multipart/alternative; boundary="----=_Part_34736_7971416.1217335968916" ------=_Part_34736_7971416.1217335968916 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline One place where Oracle would do better than P2P apps is wide-area wireless IP networks where probing and measuring between peers might be quite expensive in terms of power and bandwidth, yet operators already have a good idea of what are available inside their networks. Ulas On Tue, Jul 29, 2008 at 5:38 AM, wrote: > I too was one of those who "vehemently hummed" no at the BoF. Several > people (including some ADs) seemed to seek to characterise those of us that > hummed no as not believing that there was any sort of problem to be worked > on. > > I feel it is important to highlight that this is NOT because I believe > there is no problem to be addressed here. Nor is it because I think the IETF > is not able to do work in this space. My main objection is rather that the > draft charter for this BoF could be (possibly unfairly) paraphrased as > "wouldn't it be nice to have an entity in the network that we could ask lots > of random questions...". > > As Louise said below there are all sorts of potential problems with this > approach. Not least the fact thaat the optimisation from the point of view > of the network operator is likely to be VERY different from that of the > end-user. Furthermore it seems that P2P apps such as BitTorrent are already > producing near-optimal results from the point of view of the end-user and it > is definitely not clear that an oracle could improve on these. > > The overall sense I picked up from this BoF was that a group of people had > already decided that the best solution was an oracle and this BoF was menat > to just ratify that decision. > > Having said all that I do want to encourage people to work on solutions to > the "P2P problem" (note the " "...). I think much of this work could perhaps > be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy" > feel to a lot of the stuff we saw presented). Once we have a really clear > idea of the potential use cases for an oracle, an idea of how you can > incentivise both user and ISP in such a way that any information can be > trusted and if the information is only that which changes relatively slowly > (e.g topology, price and nature of any interconnects) then it might be worth > coming back to try again. > > Toby Moncaster > > ________________________________ > > From: p2pi-bounces@ietf.org on behalf of louise.burness@bt.com > Sent: Tue 29/07/2008 12:47 > To: p2pi@ietf.org > Subject: [p2pi] why i hummed no > > > > Chairs asked for feedback from the no's , so here is mine > > I think the general problem space - peer to peer (overlay) networks making > routing choices that have bad effects on the lower layers is a very big and > important problem > > I think it is very important that we understand what solutions we should be > working towards very well as I would hate to see bright and motivated people > wasting time working on the wrong things, as this could divert effort from > better solutions > > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each other and > the goals they are trying to achieve are likely to be different - how do i > know you are telling me the highest bandwidth not the lowest cost choice? > > the information recieved could be used in ways to harm the network - > deliberatly choosing the non-preferred routes > > the information might influenece the p2p application, but if the actual > bandwidth (or lowest delay or lowest jitter etc etc) available from a > non-preferred peer is higher than that then the non-preferred peer will be > used, therefore analysis is required to try and quantify the likely benefit > of such a scheme. there needs to be good corrolation between the oracle > output and the p2p needs. > > To really do the path choice thing sensibly in my mind requires dynamic > information which can not be obtained from an oracle. Indeed from a provider > perspective, this dynamic infomation could be more/as important also - I > would want to direct you to lightly loaded links as directing you to a > cheap, short high bandwidth but congested link is likely to do me more harm > as well > > I would like to see these issues considered better before rushing into > solution space > > Louise > > > > _______________________________________________ > 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_34736_7971416.1217335968916 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
One place where Oracle would do better than P2P apps is wide-area wireless IP networks where probing and measuring between peers might be quite expensive in terms of power and bandwidth, yet operators already have a good idea of what are available inside their networks.

Ulas

On Tue, Jul 29, 2008 at 5:38 AM, <toby.moncaster@bt.com> wrote:
I too was one of those who "vehemently hummed" no at the BoF. Several people (including some ADs) seemed to seek to characterise those of us that hummed no as not believing that there was any sort of problem to be worked on.

I feel it is important to highlight that this is NOT because I believe there is no problem to be addressed here. Nor is it because I think the IETF is not able to do work in this space. My main objection is rather that the draft charter for this BoF could be (possibly unfairly) paraphrased as "wouldn't it be nice to have an entity in the network that we could ask lots of random questions...".

As Louise said below there are all sorts of potential problems with this approach. Not least the fact thaat the optimisation from the point of view of the network operator is likely to be VERY different from that of the end-user. Furthermore it seems that P2P apps such as BitTorrent are already producing near-optimal results from the point of view of the end-user and it is definitely not clear that an oracle could improve on these.

The overall sense I picked up from this BoF was that a group of people had already decided that the best solution was an oracle and this BoF was menat to just ratify that decision.

Having said all that I do want to encourage people to work on solutions to the "P2P problem" (note the " "...). I think much of this work could perhaps be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy" feel to a lot of the stuff we saw presented). Once we have a really clear idea of the potential use cases for an oracle, an idea of how you can incentivise both user and ISP in such a way that any information can be trusted and if the information is only that which changes relatively slowly (e.g topology, price and nature of any interconnects) then it might be worth coming back to try again.

Toby Moncaster

________________________________

From: p2pi-bounces@ietf.org on behalf of louise.burness@bt.com
Sent: Tue 29/07/2008 12:47
To: p2pi@ietf.org
Subject: [p2pi] why i hummed no



Chairs asked for feedback from the no's , so here is mine

I think the general problem space - peer to peer (overlay) networks making routing choices that have bad effects on the lower layers is a very big and important problem

I think it is very important that we understand what solutions we should be working towards very well as I would hate to see bright and motivated people wasting time working on the wrong things, as this could divert effort from better solutions

my concern is that an oracle approach might not be terribly helpful

neither the p2p ap or the network have any reason to trust each other and the goals they are trying to achieve are likely to be different - how do i know you are telling me the highest bandwidth not the lowest cost choice?

the information recieved could be used in ways to harm the network - deliberatly choosing the non-preferred routes

the information might influenece the p2p application, but if the actual bandwidth (or lowest delay or lowest jitter etc etc) available from a non-preferred peer is higher than that then the non-preferred peer will be used, therefore analysis is required to try and quantify the likely benefit of such a scheme. there needs to be good corrolation between the oracle output and the p2p needs.

To really do the path choice thing sensibly in my mind requires dynamic information which can not be obtained from an oracle. Indeed from a provider perspective, this dynamic infomation could be more/as important also - I would want to direct you to lightly loaded links as directing you to a cheap, short high bandwidth but congested link is likely to do me more harm as well

I would like to see these issues considered better before rushing into solution space

Louise



_______________________________________________
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_34736_7971416.1217335968916-- --===============0339401964== 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 --===============0339401964==-- From p2pi-bounces@ietf.org Tue Jul 29 06:12: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 12CB53A6923; Tue, 29 Jul 2008 06:12: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 823413A68EB for ; Tue, 29 Jul 2008 06:12:24 -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 zg4zkdFxeS8H for ; Tue, 29 Jul 2008 06:12:23 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id EB89A3A684B for ; Tue, 29 Jul 2008 06:12:22 -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 m6TDCUgJ020740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 08:12:30 -0500 (CDT) Received: from [135.244.37.93] (vkg.lra.lucent.com [135.244.37.93]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6TDCLaG006367; Tue, 29 Jul 2008 08:12:25 -0500 (CDT) Message-ID: <488F173A.7040507@alcatel-lucent.com> Date: Tue, 29 Jul 2008 08:12:26 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: louise.burness@bt.com References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 louise.burness@bt.com wrote: > Chairs asked for feedback from the no's , so here is mine Louise: Thank your for the time and feedback. More inline. > I think the general problem space - peer to peer (overlay) networks > making routing choices that have bad effects on the lower layers is a > very big and important problem OK. > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each other > and the goals they are trying to achieve are likely to be different - > how do i know you are telling me the highest bandwidth not the lowest > cost choice? That is a valid concern, but arguably can be solved by the application not trusting the network's guidance if over a sustained period of time such a guidance does not yield any measurable benefits. > the information recieved could be used in ways to harm the network - > deliberatly choosing the non-preferred routes If an application deliberately chooses non-preferred routes even in the face of guidance from an ALTO service, then the network is no worse off than the same application making random choices biased towards non-preferred routes when an ALTO service is not present. > the information might influenece the p2p application, but if the > actual bandwidth (or lowest delay or lowest jitter etc etc) available > from a non-preferred peer is higher than that then the non-preferred > peer will be used, therefore analysis is required to try and quantify > the likely benefit of such a scheme. there needs to be good > corrolation between the oracle output and the p2p needs. I believe that over time, if the application finds that the ALTO service is not delivering the goods, it will simply stop using it. The ALTO service has always been defined as optional (the problem-statement discusses this as well.) > To really do the path choice thing sensibly in my mind requires > dynamic information which can not be obtained from an oracle. Fair enough. This point was also made by others, including Lars. But before going down further, what exact dynamic information did you have in mind? During various list discussions it has been pointed out that using information that changes on microscopic timescales will not be part of a ALTO anyway. > I would like to see these issues considered better before rushing > into solution space Sure. Thanks for your consideration. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 29 06:15: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 C26373A6B58; Tue, 29 Jul 2008 06:15: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 84FFE3A6923 for ; Tue, 29 Jul 2008 06:15:32 -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 t9YIASJhpBzd for ; Tue, 29 Jul 2008 06:15:31 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 5D3363A67B7 for ; Tue, 29 Jul 2008 06:15:31 -0700 (PDT) Received: from beethoven.local ([::ffff:130.129.19.116]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 29 Jul 2008 09:15:36 -0400 id 015A4732.488F17F9.00000EFC Message-ID: <488F17EF.4000608@thinkingcat.com> Date: Tue, 29 Jul 2008 09:15:27 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: p2pi@ietf.org References: In-Reply-To: Subject: Re: [p2pi] why i hummed no 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 I did not hum no during the session, but I have to say I was thinking the same thing as expressed by Toby & Louise: people understand there is a problem here, but don't necessarily agree with the work being proposed to solve it. Of course, the immediately following thought is: if one doesn't think this is the right, IETF-sized chunk to chop off and solve, what is the better alternative? Leslie. toby.moncaster@bt.com wrote: > I too was one of those who "vehemently hummed" no at the BoF. Several people (including some ADs) seemed to seek to characterise those of us that hummed no as not believing that there was any sort of problem to be worked on. > > I feel it is important to highlight that this is NOT because I believe there is no problem to be addressed here. Nor is it because I think the IETF is not able to do work in this space. My main objection is rather that the draft charter for this BoF could be (possibly unfairly) paraphrased as "wouldn't it be nice to have an entity in the network that we could ask lots of random questions...". > > As Louise said below there are all sorts of potential problems with this approach. Not least the fact thaat the optimisation from the point of view of the network operator is likely to be VERY different from that of the end-user. Furthermore it seems that P2P apps such as BitTorrent are already producing near-optimal results from the point of view of the end-user and it is definitely not clear that an oracle could improve on these. > > The overall sense I picked up from this BoF was that a group of people had already decided that the best solution was an oracle and this BoF was menat to just ratify that decision. > > Having said all that I do want to encourage people to work on solutions to the "P2P problem" (note the " "...). I think much of this work could perhaps be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy" feel to a lot of the stuff we saw presented). Once we have a really clear idea of the potential use cases for an oracle, an idea of how you can incentivise both user and ISP in such a way that any information can be trusted and if the information is only that which changes relatively slowly (e.g topology, price and nature of any interconnects) then it might be worth coming back to try again. > > Toby Moncaster > > ________________________________ > > From: p2pi-bounces@ietf.org on behalf of louise.burness@bt.com > Sent: Tue 29/07/2008 12:47 > To: p2pi@ietf.org > Subject: [p2pi] why i hummed no > > > > Chairs asked for feedback from the no's , so here is mine > > I think the general problem space - peer to peer (overlay) networks making routing choices that have bad effects on the lower layers is a very big and important problem > > I think it is very important that we understand what solutions we should be working towards very well as I would hate to see bright and motivated people wasting time working on the wrong things, as this could divert effort from better solutions > > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each other and the goals they are trying to achieve are likely to be different - how do i know you are telling me the highest bandwidth not the lowest cost choice? > > the information recieved could be used in ways to harm the network - deliberatly choosing the non-preferred routes > > the information might influenece the p2p application, but if the actual bandwidth (or lowest delay or lowest jitter etc etc) available from a non-preferred peer is higher than that then the non-preferred peer will be used, therefore analysis is required to try and quantify the likely benefit of such a scheme. there needs to be good corrolation between the oracle output and the p2p needs. > > To really do the path choice thing sensibly in my mind requires dynamic information which can not be obtained from an oracle. Indeed from a provider perspective, this dynamic infomation could be more/as important also - I would want to direct you to lightly loaded links as directing you to a cheap, short high bandwidth but congested link is likely to do me more harm as well > > I would like to see these issues considered better before rushing into solution space > > Louise > > > > _______________________________________________ > 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 > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 06:20:09 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 4951728C2AE; Tue, 29 Jul 2008 06:20:09 -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 E64D528C2BD for ; Tue, 29 Jul 2008 06:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 QwrhtqdKaCt7 for ; Tue, 29 Jul 2008 06:20:06 -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 3CE7128C143 for ; Tue, 29 Jul 2008 06:20:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="58902153" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 13:20:18 +0000 Received: from [130.129.22.215] ([10.21.113.56]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m6TCvIef014358; Tue, 29 Jul 2008 05:57:19 -0700 Message-Id: <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> From: David R Oran To: "Vijay K. Gurbani" In-Reply-To: <488F173A.7040507@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 09:20:16 -0400 References: <488F173A.7040507@alcatel-lucent.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3914; t=1217336240; x=1218200240; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20why=20i=20hummed=20no |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=3+vvPqDSFoPPE27i8jQFyU/MEKDeHaH7Oq7Cp4bTzuk=; b=Of09XXcQEugYC5UKMWrXpqFogw5NgArZKjIF7yAg1qr8a38Dv+mqD7rXfh axkrJeWYDGeDlKAHDaXP8AJhxdXl0ynNjiV4yQLyaaYyUVRou7/7flf7Vdaa waWNlFng6b; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 Small point embedded, banging a bit more on the point I made at the mic about discovery... On Jul 29, 2008, at 9:12 AM, Vijay K. Gurbani wrote: > louise.burness@bt.com wrote: >> Chairs asked for feedback from the no's , so here is mine > > Louise: Thank your for the time and feedback. More inline. > >> I think the general problem space - peer to peer (overlay) networks >> making routing choices that have bad effects on the lower layers is a >> very big and important problem > > OK. > >> my concern is that an oracle approach might not be terribly helpful >> neither the p2p ap or the network have any reason to trust each other >> and the goals they are trying to achieve are likely to be different - >> how do i know you are telling me the highest bandwidth not the lowest >> cost choice? > > That is a valid concern, but arguably can be solved by the > application not trusting the network's guidance if over a sustained > period of time such a guidance does not yield any measurable > benefits. > >> the information recieved could be used in ways to harm the network - >> deliberatly choosing the non-preferred routes > > If an application deliberately chooses non-preferred routes even > in the face of guidance from an ALTO service, then the network > is no worse off than the same application making random choices > biased towards non-preferred routes when an ALTO service is > not present. > This is true as long as the peer/cache/service discovery functions don't migrate into the ALTO service/server domain. Once you start depending on the ALTO server to find peers, caches, etc., they become critical infrastructure for effective operation of the P2P system. this may be OK for ALTO servers that are under the same administrative authority as the P2P application itself, but not ok when the ALTO servers have "tussle" with the application/resource owners. It may be useful to build some kind of explicit domain-based partitioning of these things into the ALTO architecture, so that a client can ascertain when there is mutual trust among the three (possibly more?) interested parties: the application/resource provider, the communication capacity provider(s), and the client. >> the information might influenece the p2p application, but if the >> actual bandwidth (or lowest delay or lowest jitter etc etc) available >> from a non-preferred peer is higher than that then the non-preferred >> peer will be used, therefore analysis is required to try and quantify >> the likely benefit of such a scheme. there needs to be good >> corrolation between the oracle output and the p2p needs. > > I believe that over time, if the application finds that the ALTO > service is not delivering the goods, it will simply stop using > it. The ALTO service has always been defined as optional (the > problem-statement discusses this as well.) > >> To really do the path choice thing sensibly in my mind requires >> dynamic information which can not be obtained from an oracle. > > Fair enough. This point was also made by others, including Lars. > But before going down further, what exact dynamic information > did you have in mind? During various list discussions it has > been pointed out that using information that changes on microscopic > timescales will not be part of a ALTO anyway. > >> I would like to see these issues considered better before rushing >> into solution space > > Sure. Thanks for your consideration. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 29 06:29: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 C43D028C2A7; Tue, 29 Jul 2008 06:29: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 42C033A6B7B for ; Tue, 29 Jul 2008 06:29: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 4PV75D81MreF for ; Tue, 29 Jul 2008 06:29:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D9B0F28C2D5 for ; Tue, 29 Jul 2008 06:29:34 -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 m6TDTcsp010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 08:29:38 -0500 (CDT) Received: from [135.244.37.93] (vkg.lra.lucent.com [135.244.37.93]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6TDTWA5023643; Tue, 29 Jul 2008 08:29:33 -0500 (CDT) Message-ID: <488F1B41.3090001@alcatel-lucent.com> Date: Tue, 29 Jul 2008 08:29:37 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 toby.moncaster@bt.com wrote: > I feel it is important to highlight that this is NOT because I > believe there is no problem to be addressed here. Nor is it because I > think the IETF is not able to do work in this space. Toby: Thank you for your feedback. > My main objection is rather that the draft charter for this BoF could > be (possibly unfairly) paraphrased as "wouldn't it be nice to have an > entity in the network that we could ask lots of random > questions...". That was not the intent of the charter. It is clear that we have to work some more on it. > Furthermore it seems that P2P apps such as BitTorrent are already > producing near-optimal results from the point of view of the end-user > and it is definitely not clear that an oracle could improve on these. > I don't think that is the case, though. Ulas pointed out the work on Ono and I have seen other work on BitTorrent deriving benefit from topological information. > The overall sense I picked up from this BoF was that a group of > people had already decided that the best solution was an oracle and > this BoF was menat to just ratify that decision. Maybe the term "oracle" is not the right connotative word here. It seems to hold a lot of context for people. We deliberately wanted to stay out of discussing solutions and simply agree on the problem statement first. But perhaps the charter did not quite reflect that. Clearly, we need to do some more work here. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 29 06:39: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 0C2AE28C310; Tue, 29 Jul 2008 06:39: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 EC5C428C310 for ; Tue, 29 Jul 2008 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkyPefLpLtqn for ; Tue, 29 Jul 2008 06:39:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4322528C2E4 for ; Tue, 29 Jul 2008 06:39:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208,217";a="15704832" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2008 13:39:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TDdSid003156; Tue, 29 Jul 2008 15:39:28 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6TDdROH008093; Tue, 29 Jul 2008 13:39:28 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 15:39:27 +0200 Received: from [172.16.255.224] ([10.61.98.129]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 15:39:27 +0200 In-Reply-To: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> References: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <42EBC231-A1CE-4FEE-831D-833CCEC1FBFD@cisco.com> From: Bruce Davie Date: Tue, 29 Jul 2008 09:39:13 -0400 To: Philip Levis X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 29 Jul 2008 13:39:27.0250 (UTC) FILETIME=[852D3720:01C8F180] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9075; t=1217338768; x=1218202768; c=relaxed/simple; s=amsdkim1002; 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]=20why=20i=20hummed=20no |Sender:=20; bh=a0ZU9Aa2ceFvYqL+dKP+d3OW4LserRwKRZiI5AYmQS8=; b=BuXF3wKM3wen2vF4jMrpRbud0KkK5blBSzjX5uE1bVdABPCASCpt+hly38 difUQZtHS2OvuHO7ETJY13q4NhgyIN4a4cVGoTInuNKrBqLs4vJIqd2ZX52G +9Xnp+7udN; Authentication-Results: ams-dkim-1; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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="===============2077398918==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2077398918== Content-Type: multipart/alternative; boundary=Apple-Mail-41-660868795 --Apple-Mail-41-660868795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed I really think we need to have people looking at experimental data =20 rather than using their intuition as to whether an Oracle might or =20 might not help. The paper cited below is one good example of data =20 that support the hypothesis that an Oracle *could* improve the =20 overall situation. Another reference is this one: Improving Traffic Locality in BitTorrent via Biased Neighbor Selection Bindal, R.; Pei Cao; Chan, W.; Medved, J.; Suwala, G.; Bates, T.; =20 Zhang, A. 26th IEEE International Conference on Distributed Computing Systems, =20 2006. I'm sure the folks at Pando can point to some of their experimental =20 data that also shows an Oracle can work effectively. Note also that as long as the oracle makes performance *no worse* for =20= the end user, while also improving the efficiency of network =20 utilization for the SP, it would still be worth deploying the =20 oracles. And as others have said, as long as they are optional, the =20 SP will have a strong incentive to deploy oracles that improve end-=20 user performance as well as the efficiency or cost of the SPs network. Also note that the point of the WG, if chartered, would be to =20 standardize an *interface* for talking to an oracle, which would =20 allow plenty of room for future algorithms to make oracles work =20 better. But let's not pretend that this is a totally wide open =20 research problem - the research has been going on for many years. With vendors already producing oracles, it seems very timely for the =20 IETF to standardize the interface by which clients talk to oracles, =20 while allowing for innovation in how exactly the oracles work. Bruce Davie On Jul 29, 2008, at 8:52 AM, Philip Levis wrote: > > On Jul 29, 2008, at 1:38 PM, wrote: > >> Furthermore it seems that P2P apps such as BitTorrent are already =20= >> producing near-optimal results from the point of view of the end-=20 >> user and it is definitely not clear that an oracle could improve =20 >> on these. > > This is decidedly untrue. Ono, one of the mentioned approaches that =20= > uses topology information to choose peers, achieves a 31-207% =20 > improvement in download rates.[1] > > Phil > > [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: =20= > A practical approach to reducing cross-ISP traffic in P2P systems, =20 > To appear in Proc. of ACM SIGCOMM 2008, August 2008. > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi --Apple-Mail-41-660868795 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I really think we need to have people looking at experimental data = rather than using their intuition as to whether an Oracle might or might = not help. The paper cited below is one good example of data that support = the hypothesis that an Oracle *could* improve the overall situation. = Another reference is this one:

Improving Traffic Locality in BitTorrent via Biased = Neighbor Selection
Bindal, = R.; Pei Cao; Chan, W.; Medved, J.; Suwala, G.; Bates, T.; Zhang, = A.
26th IEEE International = Conference on=A0Distributed Computing Systems, 2006.=A0

I'm sure the = folks at Pando can point to some of their experimental data that also = shows an Oracle can work effectively.
Note also that as long as the = oracle makes performance *no worse* for the end user, while also = improving the efficiency of network utilization for the SP, it would = still be worth deploying the oracles. And as others have said, as long = as they are optional, the SP will have a strong incentive to deploy = oracles that improve end-user performance as well as the efficiency or = cost of the SPs network.
Also note that the point of the = WG, if chartered, would be to standardize an *interface* for talking to = an oracle, which would allow plenty of room for future algorithms to = make oracles work better. But let's not pretend that this is a totally = wide open research problem - the research has been going on for many = years.=A0

With vendors already producing oracles, it seems = very timely for the IETF to standardize the interface by which clients = talk to oracles, while allowing for innovation in how exactly the = oracles work.

Bruce Davie

On Jul 29, 2008, at 1:38 PM, <toby.moncaster@bt.com> = wrote:

=
=A0Furthermore it seems that P2P = apps such as BitTorrent are already producing near-optimal results from = the point of view of the end-user and it is definitely not clear that an = oracle could improve on these.

This is = decidedly untrue. Ono, one of the mentioned approaches that uses = topology information to choose peers, achieves a 31-207% improvement in = download rates.[1]
Phil

[1] = David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: A = practical approach to reducing cross-ISP traffic in P2P systems, To = appear in Proc. of ACM SIGCOMM 2008, August 2008.
p2pi mailing list
=

= --Apple-Mail-41-660868795-- --===============2077398918== 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 --===============2077398918==-- From p2pi-bounces@ietf.org Tue Jul 29 07:03:53 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 AC28928C1C2; Tue, 29 Jul 2008 07:03:53 -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 103BF28C1C2 for ; Tue, 29 Jul 2008 07:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 kmSBEjR2458L for ; Tue, 29 Jul 2008 07:03:48 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C036828C10A for ; Tue, 29 Jul 2008 07:03:47 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id CD7F2198711 for ; Tue, 29 Jul 2008 17:03:57 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 6F5E61986E3 for ; Tue, 29 Jul 2008 17:03:57 +0300 (EEST) Message-ID: <488F2350.5040903@piuha.net> Date: Tue, 29 Jul 2008 15:04:00 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: p2pi@ietf.org References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> In-Reply-To: <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [p2pi] why i hummed no 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 Disclaimer: I have been in other meetings all day and I don't know what was presented and discussed in your meeting. I have not seen a charter proposal. However, the issue that Louise raised is something that I have also brought up in other contexts. I see the oracle approach being suggested and worked on in several places. I think it is a valid approach, but people need to understand that its not a panacea. In particular, it is very hard for me to imagine that any one point in the network has up-to-the-millisecond accurate information about congestion. As described in the P2PI workshop, the P2P applications have a number of factors that they have to consider when picking a peer. These include health of the pool that contains the information, diversity, various incentives related to trading pieces of files, etc. As a result, the oracle answer can only be ONE factor to consider, not the deciding factor. Perhaps a tie-breaker among otherwise equivalent peer choices. And any decision needs to be followed up by realtime tracking as the application observes bandwidth and congestion situation with the chosen peers. A chosen peer may have to be abandoned and a new one chosen. Also, I like the transport mechanisms (TANA) more than oracle approach, because there is a significant difference in deployability. Things you can do on your own in the applications are faster to deploy than something that requires support in the applications and networks (see also draft-arkko-p2pi-incentives). I was not in the room to hum either way. But for the record, I think it makes a sense for the IETF to develop a standard for an oracle functionality -- but for a very specific information, and with explicit guidance about how such functionality should and should not be used. I think this is needed not just for P2P but for other bandwidth hungry applications (video, surveillance, etc.). I think this is a good time for us to develop a toolbox to help future applications in this space, and an oracle can be one tool in that box. Just do not attempt to do too much, or claim too broad applicability. Jari _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 07:08: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 9B9BE28C31E; Tue, 29 Jul 2008 07:08: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 A250C28C30B for ; Tue, 29 Jul 2008 07:08:20 -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 6cuv1yEBOdmO for ; Tue, 29 Jul 2008 07:08:19 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 014D728C31E for ; Tue, 29 Jul 2008 07:08:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id AF4C4E10B08; Tue, 29 Jul 2008 10:08: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 Aws6Z9oqMw3x; Tue, 29 Jul 2008 10:07:52 -0400 (EDT) Received: from dhcp-130-129-55-97.meeting.ietf.org (unknown [130.129.55.97]) by dkny.pando.com (Postfix) with ESMTP id A5E37E10B1F; Tue, 29 Jul 2008 10:07:51 -0400 (EDT) Message-Id: From: Laird Popkin To: Philip Levis In-Reply-To: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 10:07:50 -0400 References: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 To second this, P4P's traffic localization results in dramatic = improvements in performance. For example, Verizon reported over 3x = speedups in download speed for FIOS customers. The p2p networks do a very good job of optimizing performance over = time. The issue is that it can take a very long time (e.g. hours) to = discover and converge on the optimal set of peer data sources, while = good network guidance can give a very good starting point, resulting = in much better performance much sooner. - LP On Jul 29, 2008, at 8:52 AM, Philip Levis wrote: > > On Jul 29, 2008, at 1:38 PM, wrote: > >> Furthermore it seems that P2P apps such as BitTorrent are already = >> producing near-optimal results from the point of view of the end- = >> user and it is definitely not clear that an oracle could improve on = >> these. > > This is decidedly untrue. Ono, one of the mentioned approaches that = > uses topology information to choose peers, achieves a 31-207% = > improvement in download rates.[1] > > Phil > > [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: = > A practical approach to reducing cross-ISP traffic in P2P systems, = > To appear in Proc. of ACM SIGCOMM 2008, August 2008. > _______________________________________________ > 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 Jul 29 07:30: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 C987828C283; Tue, 29 Jul 2008 07:30: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 68E6E28C1C2 for ; Tue, 29 Jul 2008 07:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.784 X-Spam-Level: * X-Spam-Status: No, score=1.784 tagged_above=-999 required=5 tests=[AWL=-2.912, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 rSjciDgOyCkR for ; Tue, 29 Jul 2008 07:30:38 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A8CB028C283 for ; Tue, 29 Jul 2008 07:30:38 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4R0042EUZE1B@usaga01-in.huawei.com> for p2pi@ietf.org; Tue, 29 Jul 2008 07:30:51 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4R00HWHUZDNT@usaga01-in.huawei.com> for p2pi@ietf.org; Tue, 29 Jul 2008 07:30:50 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [130.129.55.167]) by szxmc03-in.huawei.com (mshttpd); Tue, 29 Jul 2008 22:30:36 +0800 Date: Tue, 29 Jul 2008 22:30:36 +0800 From: songhaibin 64081 In-reply-to: To: Laird Popkin Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> Cc: p2pi@ietf.org Subject: [p2pi] =?gb2312?b?u9i4tCA6UmU6ICB3aHkgaSBodW1tZWQgbm8=?= 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="gb2312" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Clllcy4gUHJvYmluZyBhcmUgbm90IGFsd2F5cyB0cnVlLiBPcGVyYXRvciBrbm93IGl0cyBuZXR3 b3JrIGV4YWN0bHkuCgotU29uZyBIYWliaW4KCgpMYWlyZCBQb3BraW4gPGxhaXJkQHBhbmRvLmNv bT4gd3JvdGU6Cgo+IFRvIHNlY29uZCB0aGlzLCBQNFAncyB0cmFmZmljIGxvY2FsaXphdGlvbiBy ZXN1bHRzIGluIGRyYW1hdGljICAKPiBpbXByb3ZlbWVudHMgaW4gcGVyZm9ybWFuY2UuIEZvciBl eGFtcGxlLCBWZXJpem9uIHJlcG9ydGVkIG92ZXIgM3ggCj4gCj4gc3BlZWR1cHMgaW4gZG93bmxv YWQgc3BlZWQgZm9yIEZJT1MgY3VzdG9tZXJzLgo+IAo+IFRoZSBwMnAgbmV0d29ya3MgZG8gYSB2 ZXJ5IGdvb2Qgam9iIG9mIG9wdGltaXppbmcgcGVyZm9ybWFuY2Ugb3ZlciAKPiAKPiB0aW1lLiBU aGUgaXNzdWUgaXMgdGhhdCBpdCBjYW4gdGFrZSBhIHZlcnkgbG9uZyB0aW1lIChlLmcuIGhvdXJz KSAKPiB0byAgCj4gZGlzY292ZXIgYW5kIGNvbnZlcmdlIG9uIHRoZSBvcHRpbWFsIHNldCBvZiBw ZWVyIGRhdGEgc291cmNlcywgCj4gd2hpbGUgIAo+IGdvb2QgbmV0d29yayBndWlkYW5jZSBjYW4g Z2l2ZSBhIHZlcnkgZ29vZCBzdGFydGluZyBwb2ludCwgCj4gcmVzdWx0aW5nICAKPiBpbiBtdWNo IGJldHRlciBwZXJmb3JtYW5jZSBtdWNoIHNvb25lci4KPiAKPiAtIExQCj4gCj4gT24gSnVsIDI5 LCAyMDA4LCBhdCA4OjUyIEFNLCBQaGlsaXAgTGV2aXMgd3JvdGU6Cj4gCj4gPgo+ID4gT24gSnVs IDI5LCAyMDA4LCBhdCAxOjM4IFBNLCA8dG9ieS5tb25jYXN0ZXJAYnQuY29tPiB3cm90ZToKPiA+ Cj4gPj4gRnVydGhlcm1vcmUgaXQgc2VlbXMgdGhhdCBQMlAgYXBwcyBzdWNoIGFzIEJpdFRvcnJl bnQgYXJlIAo+IGFscmVhZHkgIAo+ID4+IHByb2R1Y2luZyBuZWFyLW9wdGltYWwgcmVzdWx0cyBm cm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSAKPiBlbmQtIAo+ID4+IHVzZXIgYW5kIGl0IGlz IGRlZmluaXRlbHkgbm90IGNsZWFyIHRoYXQgYW4gb3JhY2xlIGNvdWxkIAo+IGltcHJvdmUgb24g IAo+ID4+IHRoZXNlLgo+ID4KPiA+IFRoaXMgaXMgZGVjaWRlZGx5IHVudHJ1ZS4gT25vLCBvbmUg b2YgdGhlIG1lbnRpb25lZCBhcHByb2FjaGVzIAo+IHRoYXQgIAo+ID4gdXNlcyB0b3BvbG9neSBp bmZvcm1hdGlvbiB0byBjaG9vc2UgcGVlcnMsIGFjaGlldmVzIGEgMzEtMjA3JSAgCj4gPiBpbXBy b3ZlbWVudCBpbiBkb3dubG9hZCByYXRlcy5bMV0KPiA+Cj4gPiBQaGlsCj4gPgo+ID4gWzFdIERh dmlkIFIuIENob2ZmbmVzIGFuZCBGYWJpqKJuIEUuIEJ1c3RhbWFudGUuIFRhbWluZyB0aGUgCj4g VG9ycmVudDogIAo+ID4gQSBwcmFjdGljYWwgYXBwcm9hY2ggdG8gcmVkdWNpbmcgY3Jvc3MtSVNQ IHRyYWZmaWMgaW4gUDJQIAo+IHN5c3RlbXMsICAKPiA+IFRvIGFwcGVhciBpbiBQcm9jLiBvZiBB Q00gU0lHQ09NTSAyMDA4LCBBdWd1c3QgMjAwOC4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBwMnBpIG1haWxpbmcgbGlzdAo+ID4gcDJwaUBp ZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBpCj4g Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBwMnBp IG1haWxpbmcgbGlzdAo+IHAycGlAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3AycGkKPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KcDJwaSBtYWlsaW5nIGxpc3QKcDJwaUBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycGkK From p2pi-bounces@ietf.org Tue Jul 29 07:42: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 A913728C33C; Tue, 29 Jul 2008 07:42: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 4849A28C33B for ; Tue, 29 Jul 2008 07:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=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 uWEP1ewjJCYl for ; Tue, 29 Jul 2008 07:42:25 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 8236328C155 for ; Tue, 29 Jul 2008 07:42:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 07C68E10B1B; Tue, 29 Jul 2008 10:42:38 -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 ZwMji7K1bEzw; Tue, 29 Jul 2008 10:42:29 -0400 (EDT) Received: from [130.129.55.97] (unknown [130.129.55.97]) by dkny.pando.com (Postfix) with ESMTP id EA0D5E10AFD; Tue, 29 Jul 2008 10:42:28 -0400 (EDT) Message-Id: From: Laird Popkin To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 10:42:27 -0400 References: X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 Addressing the concern that the ISP and the P2P network's agendas might not align, which is certainly a risk, there is an belief that in general the "closest" peers in the network sense are also the "best" peers for the p2p network. This isn't true in every case, but it's true enough on average that we're seeing in testing (in the P4P Working Group) that localizing traffic yields benefits for both the ISP (e.g. 50% transit reductions) and the P2P network (e.g. up to 3x speedups). Of course, there are cases where closest peers aren't best peers, but as long as closer=better most of the time, localizing data transfers is good. One thing to keep in mind is that from the p2p network perspective, the "network guidance" is optional, helpful information to improve network performance, working in addition to whatever else the p2p networks already do. If an ISP publishes harmful guidance in order to hurt p2p networks, p2p networks will figure it out and ignore that ISP's guidance. If an ISP chooses not to provide any guidance, they'll perform as they do now. In terms of static vs. dynamic guidance, I think that both are valuable, but IMO it's easier to focus on relatively static guidance first. There's a lot to be gained even with a very simple, relatively static guidance such as knowledge of network interconnects within and between ISPs. Also, keep in mind that once the oracle affects which peers are connected to each other, the oracle is done, and the p2p networks manage the actual data transfers, responding to the real-time statistics such as actual throughput, congestion, etc. That being said, integrating real-time link statistics might be very interesting. For example, if there's a link outage between two cities, the oracle could stop telling peers on either city to talk to people in the other city. There's also an interesting (IMO) area of optimization where the guidance can be time-based, so the oracle can be used to shape p2p traffic differently during the day time and nigh ttime, etc. - LP On Jul 29, 2008, at 7:47 AM, wrote: > Chairs asked for feedback from the no's , so here is mine > > I think the general problem space - peer to peer (overlay) networks > making routing choices that have bad effects on the lower layers is > a very big and important problem > > I think it is very important that we understand what solutions we > should be working towards very well as I would hate to see bright > and motivated people wasting time working on the wrong things, as > this could divert effort from better solutions > > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each > other and the goals they are trying to achieve are likely to be > different - how do i know you are telling me the highest bandwidth > not the lowest cost choice? > > the information recieved could be used in ways to harm the network - > deliberatly choosing the non-preferred routes > > the information might influenece the p2p application, but if the > actual bandwidth (or lowest delay or lowest jitter etc etc) > available from a non-preferred peer is higher than that then the non- > preferred peer will be used, therefore analysis is required to try > and quantify the likely benefit of such a scheme. there needs to be > good corrolation between the oracle output and the p2p needs. > > To really do the path choice thing sensibly in my mind requires > dynamic information which can not be obtained from an oracle. Indeed > from a provider perspective, this dynamic infomation could be more/ > as important also - I would want to direct you to lightly loaded > links as directing you to a cheap, short high bandwidth but > congested link is likely to do me more harm as well > > I would like to see these issues considered better before rushing > into solution space > > Louise > > > > _______________________________________________ > 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 Jul 29 08:02: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 6668C3A6BA9; Tue, 29 Jul 2008 08:02: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 1B8B63A6B82 for ; Tue, 29 Jul 2008 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 VhdY11-l7TAg for ; Tue, 29 Jul 2008 08:02: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 D46153A6B9C for ; Tue, 29 Jul 2008 08:02:54 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 16:03:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 16:03:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjxefDxfHFXp6/RRMyXox/DKu5SHAAEMhbg References: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> From: To: , X-OriginalArrivalTime: 29 Jul 2008 15:03:03.0554 (UTC) FILETIME=[33207620:01C8F18C] Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 = ________________________________ From: p2pi-bounces@ietf.org on behalf of Philip Levis Sent: Tue 29/07/2008 13:52 To: Moncaster,T,Toby,CXR9 R Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no On Jul 29, 2008, at 1:38 PM, wrote: > Furthermore it seems that P2P apps such as BitTorrent are already = > producing near-optimal results from the point of view of the end- > user and it is definitely not clear that an oracle could improve on = > these. This is decidedly untrue. Ono, one of the mentioned approaches that = uses topology information to choose peers, achieves a 31-207% = improvement in download rates.[1] ta (based on very quick reading - i think it deserves more) it achieves this i= mprovement over a scheme that uses a random selection of peers What we need to see is if network provided information can give an improvem= ent over what p2p systems can achieve all by themselves without nec assumin= g they use a random selection. for example I have heard that some p2p syste= ms look at the IP address and try to determine nearness. - we should knw t= he difference between best of both breeds Phil [1] David R. Choffnes and Fabi=E1n E. Bustamante. Taming the Torrent: A = practical approach to reducing cross-ISP traffic in P2P systems, To = appear in Proc. of ACM SIGCOMM 2008, August 2008. _______________________________________________ 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 Jul 29 08:08: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 30F5F3A6875; Tue, 29 Jul 2008 08:08: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 021A53A6875 for ; Tue, 29 Jul 2008 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, J_CHICKENPOX_72=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 2CnFyzsMs3hd for ; Tue, 29 Jul 2008 08:08:46 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 952B63A67EF for ; Tue, 29 Jul 2008 08:08:45 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 16:08:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 16:03:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjxiV+EPmNie+4uRrmDXORSWRMCeQAAvTTI References: From: To: X-OriginalArrivalTime: 29 Jul 2008 15:08:54.0451 (UTC) FILETIME=[04471830:01C8F18D] Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 OK I just realised that perhaps i also may have a different idea of what/where the real problem is yip, reducing overall traffic distance will reduce congestion, and keeping within an ISP can control inter-connect costs, but if as a network provider the congestion bottlenecks are near the access then having such a scheme that improves nearness won't help my network resource management problem - the p2p system might work better but the network operators (and their non-p-2-p customers) could still be complaining? Near the access= roughly at the shared dslam, which was what was postulated within the tsvarea meeting just after the bof ________________________________ From: Laird Popkin [mailto:laird@pando.com] Sent: Tue 29/07/2008 15:42 To: Burness,AL,Louise,CXR9 R Cc: Laird Popkin; p2pi@ietf.org Subject: Re: [p2pi] why i hummed no Addressing the concern that the ISP and the P2P network's agendas might not align, which is certainly a risk, there is an belief that in general the "closest" peers in the network sense are also the "best" peers for the p2p network. This isn't true in every case, but it's true enough on average that we're seeing in testing (in the P4P Working Group) that localizing traffic yields benefits for both the ISP (e.g. 50% transit reductions) and the P2P network (e.g. up to 3x speedups). Of course, there are cases where closest peers aren't best peers, but as long as closer=better most of the time, localizing data transfers is good. One thing to keep in mind is that from the p2p network perspective, the "network guidance" is optional, helpful information to improve network performance, working in addition to whatever else the p2p networks already do. If an ISP publishes harmful guidance in order to hurt p2p networks, p2p networks will figure it out and ignore that ISP's guidance. If an ISP chooses not to provide any guidance, they'll perform as they do now. In terms of static vs. dynamic guidance, I think that both are valuable, but IMO it's easier to focus on relatively static guidance first. There's a lot to be gained even with a very simple, relatively static guidance such as knowledge of network interconnects within and between ISPs. Also, keep in mind that once the oracle affects which peers are connected to each other, the oracle is done, and the p2p networks manage the actual data transfers, responding to the real-time statistics such as actual throughput, congestion, etc. That being said, integrating real-time link statistics might be very interesting. For example, if there's a link outage between two cities, the oracle could stop telling peers on either city to talk to people in the other city. There's also an interesting (IMO) area of optimization where the guidance can be time-based, so the oracle can be used to shape p2p traffic differently during the day time and nigh ttime, etc. - LP On Jul 29, 2008, at 7:47 AM, wrote: > Chairs asked for feedback from the no's , so here is mine > > I think the general problem space - peer to peer (overlay) networks > making routing choices that have bad effects on the lower layers is > a very big and important problem > > I think it is very important that we understand what solutions we > should be working towards very well as I would hate to see bright > and motivated people wasting time working on the wrong things, as > this could divert effort from better solutions > > my concern is that an oracle approach might not be terribly helpful > > neither the p2p ap or the network have any reason to trust each > other and the goals they are trying to achieve are likely to be > different - how do i know you are telling me the highest bandwidth > not the lowest cost choice? > > the information recieved could be used in ways to harm the network - > deliberatly choosing the non-preferred routes > > the information might influenece the p2p application, but if the > actual bandwidth (or lowest delay or lowest jitter etc etc) > available from a non-preferred peer is higher than that then the non- > preferred peer will be used, therefore analysis is required to try > and quantify the likely benefit of such a scheme. there needs to be > good corrolation between the oracle output and the p2p needs. > > To really do the path choice thing sensibly in my mind requires > dynamic information which can not be obtained from an oracle. Indeed > from a provider perspective, this dynamic infomation could be more/ > as important also - I would want to direct you to lightly loaded > links as directing you to a cheap, short high bandwidth but > congested link is likely to do me more harm as well > > I would like to see these issues considered better before rushing > into solution space > > Louise > > > > _______________________________________________ > 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 Jul 29 08:40: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 9CA8B28C33F; Tue, 29 Jul 2008 08:40: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 A439328C344 for ; Tue, 29 Jul 2008 08:40:30 -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 fmAP84d2XsRz for ; Tue, 29 Jul 2008 08:40:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 93F8728C32A for ; Tue, 29 Jul 2008 08:40:29 -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 m6TFec2x024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 10:40:38 -0500 (CDT) Received: from [135.244.38.154] (vkg.lra.lucent.com [135.244.38.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6TFeVWX000616; Tue, 29 Jul 2008 10:40:33 -0500 (CDT) Message-ID: <488F39F4.4070502@alcatel-lucent.com> Date: Tue, 29 Jul 2008 10:40:36 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: louise.burness@bt.com References: <7DD9FE6E-9380-4755-BDF3-EF4598D66D61@cs.stanford.edu> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 louise.burness@bt.com wrote: > (based on very quick reading - i think it deserves more) it achieves > this improvement over a scheme that uses a random selection of peers Sure. A portion of their data includes a random selection of nodes, including those supporting Ono and those that do not. But... > What we need to see is if network provided information can give an > improvement over what p2p systems can achieve all by themselves > without nec assuming they use a random selection. for example I have > heard that some p2p systems look at the IP address and try to > determine nearness. - we should knw the difference between best of > both breeds ... they also run an experiment where they provide data on Ono- only peers (see Figure 7.) These peers outperform the randomly selected nodes by a very wide margin. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 29 08:50: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 457E228C34C; Tue, 29 Jul 2008 08:50: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 F2D7028C358 for ; Tue, 29 Jul 2008 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.515 X-Spam-Level: X-Spam-Status: No, score=-9.515 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nCzZ5soeTwK for ; Tue, 29 Jul 2008 08:50:40 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 3AC5028C34C for ; Tue, 29 Jul 2008 08:50:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id AE8D8E10AFD; Tue, 29 Jul 2008 11:50:29 -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 nPPnoU6QitZS; Tue, 29 Jul 2008 11:50:16 -0400 (EDT) Received: from dhcp-130-129-55-97.meeting.ietf.org (unknown [130.129.55.97]) by dkny.pando.com (Postfix) with ESMTP id 10111E10B27; Tue, 29 Jul 2008 11:50:14 -0400 (EDT) Message-Id: <6A3D78D0-CCDE-45C2-9B32-413F21C80212@pando.com> From: Laird Popkin To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 11:50:12 -0400 References: X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 This is correct - localizing transit reduces transit consumption (i.e. links within and between ISPs), but doesn't change (much) the "last mile" consumption because ultimately the same users are uploading and downloading the same content. Caching is (IMO) a part of the picture, because any data that is delivered by a cache server is data that users didn't have to upload. - LP On Jul 29, 2008, at 11:03 AM, wrote: > OK I just realised that perhaps i also may have a different idea of > what/where the real problem is > > yip, reducing overall traffic distance will reduce congestion, and > keeping within an ISP can control inter-connect costs, but if as a > network provider the congestion bottlenecks are near the access then > having such a scheme that improves nearness won't help my network > resource management problem - the p2p system might work better but > the network operators (and their non-p-2-p customers) could still be > complaining? > > Near the access= roughly at the shared dslam, which was what was > postulated within the tsvarea meeting just after the bof > > ________________________________ > > From: Laird Popkin [mailto:laird@pando.com] > Sent: Tue 29/07/2008 15:42 > To: Burness,AL,Louise,CXR9 R > Cc: Laird Popkin; p2pi@ietf.org > Subject: Re: [p2pi] why i hummed no > > > > Addressing the concern that the ISP and the P2P network's agendas > might not align, which is certainly a risk, there is an belief that in > general the "closest" peers in the network sense are also the "best" > peers for the p2p network. This isn't true in every case, but it's > true enough on average that we're seeing in testing (in the P4P > Working Group) that localizing traffic yields benefits for both the > ISP (e.g. 50% transit reductions) and the P2P network (e.g. up to 3x > speedups). Of course, there are cases where closest peers aren't best > peers, but as long as closer=better most of the time, localizing data > transfers is good. > > One thing to keep in mind is that from the p2p network perspective, > the "network guidance" is optional, helpful information to improve > network performance, working in addition to whatever else the p2p > networks already do. > > If an ISP publishes harmful guidance in order to hurt p2p networks, > p2p networks will figure it out and ignore that ISP's guidance. If an > ISP chooses not to provide any guidance, they'll perform as they do > now. > > In terms of static vs. dynamic guidance, I think that both are > valuable, but IMO it's easier to focus on relatively static guidance > first. There's a lot to be gained even with a very simple, relatively > static guidance such as knowledge of network interconnects within and > between ISPs. Also, keep in mind that once the oracle affects which > peers are connected to each other, the oracle is done, and the p2p > networks manage the actual data transfers, responding to the real-time > statistics such as actual throughput, congestion, etc. > > That being said, integrating real-time link statistics might be very > interesting. For example, if there's a link outage between two cities, > the oracle could stop telling peers on either city to talk to people > in the other city. There's also an interesting (IMO) area of > optimization where the guidance can be time-based, so the oracle can > be used to shape p2p traffic differently during the day time and nigh > ttime, etc. > > - LP > > On Jul 29, 2008, at 7:47 AM, wrote: > >> Chairs asked for feedback from the no's , so here is mine >> >> I think the general problem space - peer to peer (overlay) networks >> making routing choices that have bad effects on the lower layers is >> a very big and important problem >> >> I think it is very important that we understand what solutions we >> should be working towards very well as I would hate to see bright >> and motivated people wasting time working on the wrong things, as >> this could divert effort from better solutions >> >> my concern is that an oracle approach might not be terribly helpful >> >> neither the p2p ap or the network have any reason to trust each >> other and the goals they are trying to achieve are likely to be >> different - how do i know you are telling me the highest bandwidth >> not the lowest cost choice? >> >> the information recieved could be used in ways to harm the network - >> deliberatly choosing the non-preferred routes >> >> the information might influenece the p2p application, but if the >> actual bandwidth (or lowest delay or lowest jitter etc etc) >> available from a non-preferred peer is higher than that then the non- >> preferred peer will be used, therefore analysis is required to try >> and quantify the likely benefit of such a scheme. there needs to be >> good corrolation between the oracle output and the p2p needs. >> >> To really do the path choice thing sensibly in my mind requires >> dynamic information which can not be obtained from an oracle. Indeed >> from a provider perspective, this dynamic infomation could be more/ >> as important also - I would want to direct you to lightly loaded >> links as directing you to a cheap, short high bandwidth but >> congested link is likely to do me more harm as well >> >> I would like to see these issues considered better before rushing >> into solution space >> >> Louise >> >> >> >> _______________________________________________ >> 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 Jul 29 09:11: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 138FF3A6BC8; Tue, 29 Jul 2008 09:11: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 D0A803A69D6 for ; Tue, 29 Jul 2008 09:11:24 -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 zWD1utScp4iq for ; Tue, 29 Jul 2008 09:11:18 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 94BCC3A6BC0 for ; Tue, 29 Jul 2008 09:11:17 -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 m6TGArZA000315; Tue, 29 Jul 2008 09:11:18 -0700 (PDT) Message-Id: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> From: Nicholas Weaver To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 09:10:53 -0700 References: X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Nicholas Weaver Subject: [p2pi] Some thoughts on why I would hum no 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 Note: I was not at the BOF, but do have some thoughts based on the current discussion: On Jul 29, 2008, at 8:03 AM, wrote: > OK I just realised that perhaps i also may have a different idea of > what/where the real problem is > > yip, reducing overall traffic distance will reduce congestion, and > keeping within an ISP can control inter-connect costs, but if as a > network provider the congestion bottlenecks are near the access then > having such a scheme that improves nearness won't help my network > resource management problem - the p2p system might work better but > the network operators (and their non-p-2-p customers) could still be > complaining? > > Near the access= roughly at the shared dslam, which was what was > postulated within the tsvarea meeting just after the bof In this case, the oracle controlled by the ISP can still help: Namely, I wonder how much the succesful performance of BitTorrent etc rest on leeching of university and other related hosts where you don't have congestion on the uplink. Thus by diverting even your customers away from peering with other internal customers, the ISP benefits as they reduce their real network cost in this case, shifting traffic onto the less congested downlink. The problem comes in that each ISP wants to be as much of a leech as possible: Your customer wants the file, so you need to provide the download for them. You are an ISP, thats what you do. But the UPLOAD is NOT benefiting your customer, only other ISPs' customers. In fact, if you have congestion in the uplink direction, the UPLOAD is penalizing your other customers. Hmm, "Help other people's customers while hurting my own?" I know what my reaction to that would be. Thus even localization is not necessarily in the benefit of the ISP, depending on where the congestion is: you want to ANTI-localize if its the CMTS/DSLAM where congestion is occuring: stick someone else with that bandwidth cost, because at this time, it may cost you MORE to serve the data internally rather than externally. This suggests the limits of ALTO if the ISP is controlling the oracle (rather than a third party like Akamai in the "Taming the Torrent" paper): You get the tragedy of the commons occurring if the ISP's uplink costs are, at this moment, higher than other ISPs' costs, and so effectively you change the leeching problem from the user level to the ISP level, but magnify it because now there is a lot more bits/ money at stake when you aggregate things. Great: lets instead of just arranging a conflict between the ISP and content provider, create inter-ISP conflicts as well. Rather, the idea system for the ISP would be to "Leech and cache": Limit/eliminate the upload from the end user altogether, and have a large local cache for the download. This is why I think that focusing on ALL P2P is, IMO, a mistake: the focus should be on CACHEABLE bulk data: where the ISP can cache the traffic to serve other customers in their network, without worrying about getting sued by the MPRIAA. Caches don't have to be reliable in a P2P system (if they go down, you lose performance, unlike an inline HTTP cache) but when present can be a huge potential win for both the customer AND the ISP. For bulk data P2P, without a cache, each customer needs to, on average over everybody, download N bytes and upload N bytes. I'm sure we can all agree that this is grossly inefficient, especially for popular files. Yet with a cache, each customer needs to download N bytes, but each customer uploads 0, and the ISP as an aggregate only needs to download N and upload N bytes across its connection, which is a huge win, both for performance (the customer is almost always getting the cached data, no congestion on the last mile uplink, no congestion on the general uplink) and for cost. And its relatively easy to do. Use ALTO or a similar program to direct local clients to that cache. Or, heck, there's probably a way to play DNS games: Lookup "hashcode.p2pcache.com" returns the IPs for nodes which have this data and are local: ISPs can redirect to their own oracle, or go to the central oracle if they don't support it. The problem I have, however, is this quickly looks very similar to a CDN. Because it is, just a CDN that's decentralized and can be more available as a public resource. This is why, overall, I'm highly skeptical of commercial P2P distribution for bulk data: the better the system can work in terms of minimizing TOTAL system costs (rather than just minimizing content- provider costs while shifting and magnifying ISP's costs), the more it looks like Akamai! And each trick you do to improve performance (eg, (ab)use DNS so you don't need a separate oracle protocol, reduce the uplink usage to 0 by only communicating data from caches rather than user end nodes, have the content provider pay for the cache to get it deployed, etc etc etc), the more it becomes a conventional CDN. And this is why, if anything, I think the answer should be "No separate protocol": Overload DNS if you want an oracle for topology discovery, just like "Taming the Torrents" does. Forget ALTO. Forget P4P. Just pick an unregistered name, have a centralized oracle, and (optionally) have an RFC extension to DNS for responses which allow the local server to override or redelegate to the ISP's local oracle. You get a system you can deploy today WITHOUT ISP cooperation, and that as ISPs want to cooperate, you can refine the results more. Lacking ISP cooperation is probably a GOOD thing for commercial P2P, as you avoid the tragedy of the commons effect. And for the pirated content, let Pirate Bay run the oracle. Yes, such an oracle has a single point of failure for legal attack. Thats hardly a bug in my opinion. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 09:32: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 A6AF23A681E; Tue, 29 Jul 2008 09:32: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 6BFD73A681E for ; Tue, 29 Jul 2008 09:32:30 -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 pQJvbkbekSW1 for ; Tue, 29 Jul 2008 09:32:29 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 72AA63A6883 for ; Tue, 29 Jul 2008 09:32:29 -0700 (PDT) Received: from E03MVX1-UKDY.domain1.systemhost.net ([193.113.30.52]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 17:32:38 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 17:32:37 +0100 Message-ID: In-Reply-To: <488F1B41.3090001@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjxfzwBHNpt3aknRP23uD55zP7BGwAF/bcw From: To: , X-OriginalArrivalTime: 29 Jul 2008 16:32:38.0735 (UTC) FILETIME=[B6FBFDF0:01C8F198] Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Vijay K. Gurbani > Sent: 29 July 2008 14:30 > > toby.moncaster@bt.com wrote: > > My main objection is rather that the draft charter for this > BoF could > > be (possibly unfairly) paraphrased as "wouldn't it be nice > to have an > > entity in the network that we could ask lots of random > > questions...". > > That was not the intent of the charter. It is clear that we > have to work some more on it. I had the same sense of the meeting as Toby and felt that it was a pity the opportunity seemed to have been missed to charter work on what is clearly accepted to be an important problem (notwithstanding Jon's assertion that 'we'll be back'). I think to move forward it is necessary to narrow the scope of what sort of questions an oracle can be expected to answer (coarse-grained topology and nothing else?) and make that explicit in the charter. Leaving that scoping for a WG to figure out will encourage lots of debate post-WG formation and will hinder concrete progress, IMHO. Mat _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 10:55: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 94CC63A6ADF; Tue, 29 Jul 2008 10:55: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 2DC503A6AE9 for ; Tue, 29 Jul 2008 10:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H70CiSjA215 for ; Tue, 29 Jul 2008 10:55:33 -0700 (PDT) Received: from tpamail2.verizon.com (tpamail2.verizon.com [192.76.82.136]) by core3.amsl.com (Postfix) with ESMTP id D1BBB3A68B2 for ; Tue, 29 Jul 2008 10:55:32 -0700 (PDT) Received: from smtptpa3.verizon.com (smtptpa3.verizon.com [138.83.71.176]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id m6THtVYp018371; Tue, 29 Jul 2008 13:55:31 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id m6THtVMx002383; Tue, 29 Jul 2008 13:55:31 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id 3C8ED528004; Tue, 29 Jul 2008 13:55:31 -0400 (EDT) X-AuditID: 8a53433a-abbddbb000000647-74-488f5993673a Received: from smtpftw3.verizon.com (unknown [138.83.140.92]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id 120274E4004; Tue, 29 Jul 2008 13:55:31 -0400 (EDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m6THtGbH027219; Tue, 29 Jul 2008 13:55:30 -0400 (EDT) Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 13:55:19 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Jul 2008 13:54:54 -0400 Message-ID: <2FC4EE4E1850E64A94DD4E64DC1C8867057566@FHDP1CCMXCV01.us.one.verizon.com> In-Reply-To: <6A3D78D0-CCDE-45C2-9B32-413F21C80212@pando.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjxkuaiMB0R75qRRtWhYHgoCyswXAADuVAw References: <6A3D78D0-CCDE-45C2-9B32-413F21C80212@pando.com> From: To: , X-OriginalArrivalTime: 29 Jul 2008 17:55:19.0986 (UTC) FILETIME=[441ED120:01C8F1A4] X-Brightmail-Tracker: AAAAAA== Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 That's a good point to make. Much of this work is to reduce the overall impacts of P2P traffic on the ISP networks while also increasing the end user performance. It won't be possible to eliminate all impacts of P2P as we're still delivering the same content to the end user. There's no silver bullet and individual ISPs will have different preferences and needs. This is all a bit like BGP is today. In the early days, BGP was almost entirely trust based. In response to accidents such as full table leaks or de-aggregation, a number of safeguards were created over time. Most of those are more about best practices than standards. I believe the same will ultimately apply in this context. We'll have a hard standard for the technology and best practices for handling behavioral anomalies. Doug --- Doug Pasko PMTS - Principal Member of Technical Staff Verizon Network and Technology VC12W413 One Verizon Way, Basking Ridge, NJ 07920 Office: 908-559-1472 Cell: 703-930-7581 -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Laird Popkin Sent: Tuesday, July 29, 2008 11:50 AM To: louise.burness@bt.com Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no This is correct - localizing transit reduces transit consumption (i.e. links within and between ISPs), but doesn't change (much) the "last mile" consumption because ultimately the same users are uploading and downloading the same content. Caching is (IMO) a part of the picture, because any data that is delivered by a cache server is data that users didn't have to upload. - LP On Jul 29, 2008, at 11:03 AM, wrote: > OK I just realised that perhaps i also may have a different idea of > what/where the real problem is > > yip, reducing overall traffic distance will reduce congestion, and > keeping within an ISP can control inter-connect costs, but if as a > network provider the congestion bottlenecks are near the access then > having such a scheme that improves nearness won't help my network > resource management problem - the p2p system might work better but > the network operators (and their non-p-2-p customers) could still be > complaining? > > Near the access= roughly at the shared dslam, which was what was > postulated within the tsvarea meeting just after the bof > > ________________________________ > > From: Laird Popkin [mailto:laird@pando.com] > Sent: Tue 29/07/2008 15:42 > To: Burness,AL,Louise,CXR9 R > Cc: Laird Popkin; p2pi@ietf.org > Subject: Re: [p2pi] why i hummed no > > > > Addressing the concern that the ISP and the P2P network's agendas > might not align, which is certainly a risk, there is an belief that in > general the "closest" peers in the network sense are also the "best" > peers for the p2p network. This isn't true in every case, but it's > true enough on average that we're seeing in testing (in the P4P > Working Group) that localizing traffic yields benefits for both the > ISP (e.g. 50% transit reductions) and the P2P network (e.g. up to 3x > speedups). Of course, there are cases where closest peers aren't best > peers, but as long as closer=better most of the time, localizing data > transfers is good. > > One thing to keep in mind is that from the p2p network perspective, > the "network guidance" is optional, helpful information to improve > network performance, working in addition to whatever else the p2p > networks already do. > > If an ISP publishes harmful guidance in order to hurt p2p networks, > p2p networks will figure it out and ignore that ISP's guidance. If an > ISP chooses not to provide any guidance, they'll perform as they do > now. > > In terms of static vs. dynamic guidance, I think that both are > valuable, but IMO it's easier to focus on relatively static guidance > first. There's a lot to be gained even with a very simple, relatively > static guidance such as knowledge of network interconnects within and > between ISPs. Also, keep in mind that once the oracle affects which > peers are connected to each other, the oracle is done, and the p2p > networks manage the actual data transfers, responding to the real-time > statistics such as actual throughput, congestion, etc. > > That being said, integrating real-time link statistics might be very > interesting. For example, if there's a link outage between two cities, > the oracle could stop telling peers on either city to talk to people > in the other city. There's also an interesting (IMO) area of > optimization where the guidance can be time-based, so the oracle can > be used to shape p2p traffic differently during the day time and nigh > ttime, etc. > > - LP > > On Jul 29, 2008, at 7:47 AM, wrote: > >> Chairs asked for feedback from the no's , so here is mine >> >> I think the general problem space - peer to peer (overlay) networks >> making routing choices that have bad effects on the lower layers is >> a very big and important problem >> >> I think it is very important that we understand what solutions we >> should be working towards very well as I would hate to see bright >> and motivated people wasting time working on the wrong things, as >> this could divert effort from better solutions >> >> my concern is that an oracle approach might not be terribly helpful >> >> neither the p2p ap or the network have any reason to trust each >> other and the goals they are trying to achieve are likely to be >> different - how do i know you are telling me the highest bandwidth >> not the lowest cost choice? >> >> the information recieved could be used in ways to harm the network - >> deliberatly choosing the non-preferred routes >> >> the information might influenece the p2p application, but if the >> actual bandwidth (or lowest delay or lowest jitter etc etc) >> available from a non-preferred peer is higher than that then the non- >> preferred peer will be used, therefore analysis is required to try >> and quantify the likely benefit of such a scheme. there needs to be >> good corrolation between the oracle output and the p2p needs. >> >> To really do the path choice thing sensibly in my mind requires >> dynamic information which can not be obtained from an oracle. Indeed >> from a provider perspective, this dynamic infomation could be more/ >> as important also - I would want to direct you to lightly loaded >> links as directing you to a cheap, short high bandwidth but >> congested link is likely to do me more harm as well >> >> I would like to see these issues considered better before rushing >> into solution space >> >> Louise >> >> >> >> _______________________________________________ >> 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 Jul 29 11:30: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 C138D3A6B0C; Tue, 29 Jul 2008 11:30: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 1D3B83A6AD1 for ; Tue, 29 Jul 2008 11:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 3mLAeetfhdSY for ; Tue, 29 Jul 2008 11:30:31 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id C5AFB28C100 for ; Tue, 29 Jul 2008 11:30:31 -0700 (PDT) Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m6TITwWS021356; Tue, 29 Jul 2008 14:29:59 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m6TITwrj024872; Tue, 29 Jul 2008 14:29:58 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id D8F55528003; Tue, 29 Jul 2008 14:29:57 -0400 (EDT) X-AuditID: 8a53433a-ab3dcbb000000647-9d-488f61a57399 Received: from smtptpa3.verizon.com (unknown [138.83.71.176]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id BDE754E4003; Tue, 29 Jul 2008 14:29:57 -0400 (EDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id m6TITvdq027485; Tue, 29 Jul 2008 14:29:57 -0400 (EDT) Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 14:29:57 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Jul 2008 14:30:03 -0400 Message-ID: <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> In-Reply-To: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Some thoughts on why I would hum no Thread-Index: AcjxlefywrA0KcafQ16uX8pI0OYa8AAENkbA References: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> From: To: , X-OriginalArrivalTime: 29 Jul 2008 18:29:57.0508 (UTC) FILETIME=[1A6B8440:01C8F1A9] X-Brightmail-Tracker: AAAAAA== Cc: p2pi@ietf.org Subject: Re: [p2pi] Some thoughts on why I would hum no 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 would agree with you that the ability to indicate the existence of P2P caching resources at the application layer is an important function that should not be overlooked. If a carrier were looking to make available caching resources, they'd need a simple and standard way to announce their presence to the P2P systems they would support. I would consider this a feature in the overall approach since some ISPs would not necessarily wish to deploy, manage and maintain P2P caches. The legal protections for caching you mentioned are unfortunately not necessarily ironclad, nor would they apply in all countries. I would disagree with abandoning the concept of ISP guidance for peer selection. In the first P4P field trial, Verizon was able to see significant reductions in network usage by average distance traveled for the P2P traffic tested. In that example, Verizon has no ability whatsoever to influence the flow of traffic between users on another ISP's network. If we were truly to come to an impasse on trust between carriers, those results for internal ISP optimization are still more than worth the effort. I don't believe the ISPs community as a whole would attempt to take the actions you described. That said, if there is enough concern that it could happen, I think we should endeavor to build-in safeguards and mechanisms to detect the abuse rather than abandon the potential benefit. Thanks Doug --- Doug Pasko PMTS - Principal Member of Technical Staff Verizon Network and Technology VC12W413 One Verizon Way, Basking Ridge, NJ 07920 Office: 908-559-1472 Cell: 703-930-7581 -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Nicholas Weaver Sent: Tuesday, July 29, 2008 12:11 PM To: Cc: p2pi@ietf.org; Nicholas Weaver Subject: [p2pi] Some thoughts on why I would hum no Note: I was not at the BOF, but do have some thoughts based on the current discussion: On Jul 29, 2008, at 8:03 AM, wrote: > OK I just realised that perhaps i also may have a different idea of > what/where the real problem is > > yip, reducing overall traffic distance will reduce congestion, and > keeping within an ISP can control inter-connect costs, but if as a > network provider the congestion bottlenecks are near the access then > having such a scheme that improves nearness won't help my network > resource management problem - the p2p system might work better but > the network operators (and their non-p-2-p customers) could still be > complaining? > > Near the access= roughly at the shared dslam, which was what was > postulated within the tsvarea meeting just after the bof In this case, the oracle controlled by the ISP can still help: Namely, I wonder how much the succesful performance of BitTorrent etc rest on leeching of university and other related hosts where you don't have congestion on the uplink. Thus by diverting even your customers away from peering with other internal customers, the ISP benefits as they reduce their real network cost in this case, shifting traffic onto the less congested downlink. The problem comes in that each ISP wants to be as much of a leech as possible: Your customer wants the file, so you need to provide the download for them. You are an ISP, thats what you do. But the UPLOAD is NOT benefiting your customer, only other ISPs' customers. In fact, if you have congestion in the uplink direction, the UPLOAD is penalizing your other customers. Hmm, "Help other people's customers while hurting my own?" I know what my reaction to that would be. Thus even localization is not necessarily in the benefit of the ISP, depending on where the congestion is: you want to ANTI-localize if its the CMTS/DSLAM where congestion is occuring: stick someone else with that bandwidth cost, because at this time, it may cost you MORE to serve the data internally rather than externally. This suggests the limits of ALTO if the ISP is controlling the oracle (rather than a third party like Akamai in the "Taming the Torrent" paper): You get the tragedy of the commons occurring if the ISP's uplink costs are, at this moment, higher than other ISPs' costs, and so effectively you change the leeching problem from the user level to the ISP level, but magnify it because now there is a lot more bits/ money at stake when you aggregate things. Great: lets instead of just arranging a conflict between the ISP and content provider, create inter-ISP conflicts as well. Rather, the idea system for the ISP would be to "Leech and cache": Limit/eliminate the upload from the end user altogether, and have a large local cache for the download. This is why I think that focusing on ALL P2P is, IMO, a mistake: the focus should be on CACHEABLE bulk data: where the ISP can cache the traffic to serve other customers in their network, without worrying about getting sued by the MPRIAA. Caches don't have to be reliable in a P2P system (if they go down, you lose performance, unlike an inline HTTP cache) but when present can be a huge potential win for both the customer AND the ISP. For bulk data P2P, without a cache, each customer needs to, on average over everybody, download N bytes and upload N bytes. I'm sure we can all agree that this is grossly inefficient, especially for popular files. Yet with a cache, each customer needs to download N bytes, but each customer uploads 0, and the ISP as an aggregate only needs to download N and upload N bytes across its connection, which is a huge win, both for performance (the customer is almost always getting the cached data, no congestion on the last mile uplink, no congestion on the general uplink) and for cost. And its relatively easy to do. Use ALTO or a similar program to direct local clients to that cache. Or, heck, there's probably a way to play DNS games: Lookup "hashcode.p2pcache.com" returns the IPs for nodes which have this data and are local: ISPs can redirect to their own oracle, or go to the central oracle if they don't support it. The problem I have, however, is this quickly looks very similar to a CDN. Because it is, just a CDN that's decentralized and can be more available as a public resource. This is why, overall, I'm highly skeptical of commercial P2P distribution for bulk data: the better the system can work in terms of minimizing TOTAL system costs (rather than just minimizing content- provider costs while shifting and magnifying ISP's costs), the more it looks like Akamai! And each trick you do to improve performance (eg, (ab)use DNS so you don't need a separate oracle protocol, reduce the uplink usage to 0 by only communicating data from caches rather than user end nodes, have the content provider pay for the cache to get it deployed, etc etc etc), the more it becomes a conventional CDN. And this is why, if anything, I think the answer should be "No separate protocol": Overload DNS if you want an oracle for topology discovery, just like "Taming the Torrents" does. Forget ALTO. Forget P4P. Just pick an unregistered name, have a centralized oracle, and (optionally) have an RFC extension to DNS for responses which allow the local server to override or redelegate to the ISP's local oracle. You get a system you can deploy today WITHOUT ISP cooperation, and that as ISPs want to cooperate, you can refine the results more. Lacking ISP cooperation is probably a GOOD thing for commercial P2P, as you avoid the tragedy of the commons effect. And for the pirated content, let Pirate Bay run the oracle. Yes, such an oracle has a single point of failure for legal attack. Thats hardly a bug in my opinion. _______________________________________________ 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 Jul 29 12:10: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 7AD093A689B; Tue, 29 Jul 2008 12:10: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 AB66F3A689B for ; Tue, 29 Jul 2008 12:10:16 -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 BnVnb49JVYYE for ; Tue, 29 Jul 2008 12:10:15 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 5993C3A67AB for ; Tue, 29 Jul 2008 12:10:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 29 Jul 2008 12:09:43 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 12:09:30 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 15:09:29 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 29 Jul 2008 19:09:28 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 29 Jul 2008 12:09:25 -0700 From: Reinaldo Penno To: Message-ID: Thread-Topic: Peer Selection, Discovery and Caches Thread-Index: Acjxrp2O1b8AtCjBnUiNRbol7PN9dA== In-Reply-To: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 29 Jul 2008 19:09:29.0730 (UTC) FILETIME=[A05FDE20:01C8F1AE] Subject: [p2pi] Peer Selection, Discovery and Caches 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, Let me try to summarize a few points I heard during the BOF presentation and also that people have been making on the list. Personally I think this group could use some kind of architecture document or a section on some existing document that have pictures, functions, etc. It seems people have different mental pictures and expectations of what the ALTO solution is and their players. Discovery of ALTO Service ========================= * I believe there should a way to discover an ALTO Service in a network. Not only I'm happy to reuse a IETF protocol but I also encourage it. But my experience with many different P2P clients, overlay networks and others is that things are already quite diverse and to help client developers and ISPs we have to tell "use protocol Y to discover the ALTO Service". Or as somebody else said :"there can be only one"...otherwise we will have bootstrapping and interoperability problems Discovery of Caches =================== * _If_ you think caching is an important piece of the ALTO Solution that could reduce bandwidth consumption in the upstream direction, then there should be one recommended way to finding them (many are possible, but one should be recommended). Again, it is all about interoperability and standardization. The discovery could be done by the clients, caches could be just like other peers running P2P protocol and announced by the ALTO Service, or the client could ask the ALTO Service "where is the nearest cache?". Some people preference on which solution we should pursue. Discovery of other "Stuff" ========================== * I'm not sure how relevant is the discovery of media relays and others. I was asked to summarize the discussion on the list and some people thought it could be useful on this way, so it was in the presentation. Personally I thought this was a contention issue. Peer Selection ============== * As long as we can agree that a service in the network (or through some 3rd party) will provide a Peer Selection Service, the semantics of the information passed can be a second step. Of course for interoperability purposes we should have at least one identification of peer and metric that everybody understand. This could be IP address and a number since we are assuming this is an IP network. But, as long as we agree that a service will be provided, the query response protocol could be point to point, DHT based, or others. Thanks, Reinaldo _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 12:12: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 2172D28C104; Tue, 29 Jul 2008 12:12: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 4523B3A6AD0 for ; Tue, 29 Jul 2008 12:12: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 mQLmeCfI5aIt for ; Tue, 29 Jul 2008 12:12: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 221A43A6B42 for ; Tue, 29 Jul 2008 12:12: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 m6TJBg5J001298; Tue, 29 Jul 2008 12:12:06 -0700 (PDT) Message-Id: <01D4998C-4746-43D8-ADF7-65258E4F1A52@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "" In-Reply-To: <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 12:11:41 -0700 References: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Some thoughts on why I would hum no 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 Jul 29, 2008, at 11:30 AM, wrote: > > I would agree with you that the ability to indicate the existence of > P2P > caching resources at the application layer is an important function > that > should not be overlooked. If a carrier were looking to make available > caching resources, they'd need a simple and standard way to announce > their presence to the P2P systems they would support. I would > consider > this a feature in the overall approach since some ISPs would not > necessarily wish to deploy, manage and maintain P2P caches. The legal > protections for caching you mentioned are unfortunately not > necessarily > ironclad, nor would they apply in all countries. > > I would disagree with abandoning the concept of ISP guidance for peer > selection. In the first P4P field trial, Verizon was able to see > significant reductions in network usage by average distance traveled > for > the P2P traffic tested. In that example, Verizon has no ability > whatsoever to influence the flow of traffic between users on another > ISP's network. If we were truly to come to an impasse on trust > between > carriers, those results for internal ISP optimization are still more > than worth the effort. I think its more that the ISP has an unusual set of incentives: You can build your oracles without ISP cooperation, you don't need ISP cooperation ("Taming Torrents" proved this), and with ISP cooperation it makes the incentives weirder: There are cases where there IS no internal ISP optimization: rather it is in the ISP's interest to force ALL the traffic to come from elsewhere, depending on where congestion is occuring. If you get congestion in the CMTS/DSLAM uplink, well, thats hurting all your other customers. And its also: You don't need a new protocol to build your oracles and distribute information, the existing DNS infrastructure can do just fine as a way of performing queries efficiently and effectively. Query for {hashcode}.nonce.myip.p4pcache.com and return a list of IPs that are the peers you would be "best" provided with for the resource {hashcode}. At the same time, this registers myip as being associated with {hashcode} as well. [1] If the ISP wishes, they can override the lookup for ...p4pcache.com should they wish a local oracle to have priority, so ISP cooperation can be used, but isn't required, in a system you can deploy today. and: The more economically viable a commercial bulk-data P2P system is at reducing aggregate costs, rather than just content provider costs, the more it looks like a CDN. EG, the DNS sketch above is effectively how Akamai works (and "Taming the Torrents", so its (ab)using DNS in old and common ways, not new and different ways). CDNs already know how to get good location information and how to distribute it, and how to put caches in the ISPs. So why should the IETF invest resources in designing a system (ALTO) where: a) You can do it all for the client side (oracle query) by (ab)using DNS today in an already well-abused fashion. b) The CDNs already know how to get the information to construct a good oracle on the server side. c) Sees the biggest benefit for piracy-systems and commercial systems that are far less efficient than existing CDNs? Because as soon as you add CDN-style caching into the basic P2P structure, you only bother talking to the local cache and let the cache delegate getting the data. [1] The Joe-job potential is low, as even on set of HUGELY popular torrents, it would mean just a few SYNs per participant for just the "local" peers, so say 10 NEW peers/second * 10 SYNs/peer -> 100 SYN/ sec -> 8 kbps -> who cares? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 12:53: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 3542628C119; Tue, 29 Jul 2008 12:53: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 E8D3E3A67EB for ; Tue, 29 Jul 2008 12:53:09 -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 nSRTPVycZIKL for ; Tue, 29 Jul 2008 12:53:08 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id A74813A6B5D for ; Tue, 29 Jul 2008 12:53:08 -0700 (PDT) Received: from cyndra.cs.yale.edu (cyndra.cs.yale.edu [128.36.229.87]) by netra.cs.yale.edu (Postfix) with ESMTP id 06843409429; Tue, 29 Jul 2008 15:53:21 -0400 (EDT) Date: Tue, 29 Jul 2008 15:53:21 -0400 (EDT) From: "Y. R. Yang" To: Nicholas Weaver In-Reply-To: <01D4998C-4746-43D8-ADF7-65258E4F1A52@ICSI.Berkeley.EDU> Message-ID: References: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> <01D4998C-4746-43D8-ADF7-65258E4F1A52@ICSI.Berkeley.EDU> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Some thoughts on why I would hum no 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 Nick, Thanks a lot for your excellent points. Below are a few comments. On Tue, 29 Jul 2008, 12:11pm -0700, Nicholas Weaver wrote: > > On Jul 29, 2008, at 11:30 AM, > wrote: > > > > >I would agree with you that the ability to indicate the existence of P2P > >caching resources at the application layer is an important function that > >should not be overlooked. If a carrier were looking to make available > >caching resources, they'd need a simple and standard way to announce > >their presence to the P2P systems they would support. I would consider > >this a feature in the overall approach since some ISPs would not > >necessarily wish to deploy, manage and maintain P2P caches. The legal > >protections for caching you mentioned are unfortunately not necessarily > >ironclad, nor would they apply in all countries. > > > >I would disagree with abandoning the concept of ISP guidance for peer > >selection. In the first P4P field trial, Verizon was able to see > >significant reductions in network usage by average distance traveled for > >the P2P traffic tested. In that example, Verizon has no ability > >whatsoever to influence the flow of traffic between users on another > >ISP's network. If we were truly to come to an impasse on trust between > >carriers, those results for internal ISP optimization are still more > >than worth the effort. > > I think its more that the ISP has an unusual set of incentives: > > You can build your oracles without ISP cooperation, you don't need ISP > cooperation ("Taming Torrents" proved this), and with ISP cooperation it makes I would have to disagree with abandoning the more direct ISP information. "Taming torrent" is using the preference of Akamai to guide traffic distribution. Akamai is not a neutral entity and has its own incentives (e.g., load balancing according to the congestion status of its *own* servers). A key question is whether Akamai can know ISP's preferences or try to help ISPs. In terms of ISP incentives, in the P4P implementation and field tests, P2P can always override ISP information to both maintain application performance and to maintain "fairness". For example, in the implementation of current field test, P2P sets a large target for intradomain selection before interdomain selection. > the incentives weirder: > > There are cases where there IS no internal ISP optimization: rather it is in > the ISP's interest to force ALL the traffic to come from elsewhere, depending > on where congestion is occuring. If you get congestion in the CMTS/DSLAM > uplink, well, thats hurting all your other customers. > > > And its also: > > You don't need a new protocol to build your oracles and distribute > information, the existing DNS infrastructure can do just fine as a way of > performing queries efficiently and effectively. Query for > {hashcode}.nonce.myip.p4pcache.com and return a list of IPs that are the peers > you would be "best" provided with for the resource {hashcode}. At the same > time, this registers myip as being associated with {hashcode} as well. [1] Again, who runs p4pcache.com and whose preference does it reflect? > If the ISP wishes, they can override the lookup for ...p4pcache.com should > they wish a local oracle to have priority, so ISP cooperation can be used, but > isn't required, in a system you can deploy today. > > > and: > > The more economically viable a commercial bulk-data P2P system is at reducing > aggregate costs, rather than just content provider costs, the more it looks > like a CDN. EG, the DNS sketch above is effectively how Akamai works (and > "Taming the Torrents", so its (ab)using DNS in old and common ways, not new > and different ways). CDNs already know how to get good location information > and how to distribute it, and how to put caches in the ISPs. > > > > > So why should the IETF invest resources in designing a system (ALTO) where: > > a) You can do it all for the client side (oracle query) by (ab)using DNS > today in an already well-abused fashion. Personally, I would prefer clean, extensible solutions, than abuses :-) > b) The CDNs already know how to get the information to construct a good > oracle on the server side. My understanding is that the intention is to be good only for CDNs. It is clear that the solution space is quite large. There are many research issues remaining. But I do see strong values in IETF standarzing some basic protcols. Richard > c) Sees the biggest benefit for piracy-systems and commercial systems that > are far less efficient than existing CDNs? Because as soon as you add > CDN-style caching into the basic P2P structure, you only bother talking to the > local cache and let the cache delegate getting the data. > > > [1] The Joe-job potential is low, as even on set of HUGELY popular torrents, > it would mean just a few SYNs per participant for just the "local" peers, so > say 10 NEW peers/second * 10 SYNs/peer -> 100 SYN/sec -> 8 kbps -> who cares? > > _______________________________________________ > 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 Jul 29 13:13: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 9A1AA28B56A; Tue, 29 Jul 2008 13:13: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 495B83A6B70 for ; Tue, 29 Jul 2008 13:13:40 -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 dy4MHn6lfxpH for ; Tue, 29 Jul 2008 13:13: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 643823A6B5E for ; Tue, 29 Jul 2008 13:13: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 m6TKDQGb014648; Tue, 29 Jul 2008 13:13:50 -0700 (PDT) Message-Id: <05E62407-1968-4A18-B382-08979C080BD8@ICSI.Berkeley.EDU> From: Nicholas Weaver To: "Y. R. Yang" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 29 Jul 2008 13:13:26 -0700 References: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> <01D4998C-4746-43D8-ADF7-65258E4F1A52@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Some thoughts on why I would hum no 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 Jul 29, 2008, at 12:53 PM, Y. R. Yang wrote: >> I think its more that the ISP has an unusual set of incentives: >> >> You can build your oracles without ISP cooperation, you don't need >> ISP >> cooperation ("Taming Torrents" proved this), and with ISP >> cooperation it makes > > I would have to disagree with abandoning the more direct ISP > information. > > "Taming torrent" is using the preference of Akamai to guide traffic > distribution. Akamai is not a neutral entity and has its own > incentives > (e.g., load balancing according to the congestion status of its *own* > servers). A key question is whether Akamai can know ISP's > preferences or > try to help ISPs. > > In terms of ISP incentives, in the P4P implementation and field > tests, P2P > can always override ISP information to both maintain application > performance and to maintain "fairness". For example, in the > implementation > of current field test, P2P sets a large target for intradomain > selection > before interdomain selection. What my point is that you don't need to REQUIURE ISP cooperation, and that you are far better served building a system which is usable now without ISP cooperation, but where ISP cooperation can be grafted into the system cleanly as ISPs want to add their own support and their own weights. > Again, who runs p4pcache.com and whose preference does it reflect? The content provider(s) or a third party service, and the goal is to maximize aggregate performance. EG, there are easy business models: "You give me a hashcode and a penny, and I'll provide the service for the hashcode. And if the MPAA comes after me, I'll direct them to you". If an ISP wants to provide more detail for their customers, they can (and should) impose their own responses. This is one of the cases where lack of cryptographic signatures is a Good Thing (tm). >> a) You can do it all for the client side (oracle query) by >> (ab)using DNS >> today in an already well-abused fashion. > > Personally, I would prefer clean, extensible solutions, than > abuses :-) I guess I don't really think of it as an abuse. You want a service that can quickly return a set of IP addresses and auxiliary information for a hierarchically-addressed record, which is either generated locally if you have a local authority, or delegated to the proper remote authority. Latency matters as well, you want it to take, if possible, only a single RTT to get a response. And you want an easy to use API for programmers as well, available in as many languages as possible, so that every P2P program can use this with the absolute minimum amount of work. At the same time, you want universal deployment of the oracle infrastructure to maximize the benefit. So actually, I think we are in agreement in the need for a clean extensible solution, I just believe that the clean, extensible solution is already present in DNS. >> b) The CDNs already know how to get the information to construct a >> good >> oracle on the server side. > > My understanding is that the intention is to be good only for CDNs. > > It is clear that the solution space is quite large. There are many > research issues remaining. But I do see strong values in IETF > standarzing > some basic protcols. The actual weights for the oracle in the CDN case are to optimize things for the CDN. But the basic raw data needed should be pretty much the same. So why reinvent the wheel? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 29 16:10: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 BF89628C17A; Tue, 29 Jul 2008 16:10: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 74CE228C17D for ; Tue, 29 Jul 2008 16:10:29 -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 eiFcCSGq402c for ; Tue, 29 Jul 2008 16:10:23 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id E68D928C179 for ; Tue, 29 Jul 2008 16:10:22 -0700 (PDT) Received: from cyndra.cs.yale.edu (cyndra.cs.yale.edu [128.36.229.87]) by netra.cs.yale.edu (Postfix) with ESMTP id DAEA7409475; Tue, 29 Jul 2008 19:10:30 -0400 (EDT) Date: Tue, 29 Jul 2008 19:10:30 -0400 (EDT) From: "Y. R. Yang" To: Nicholas Weaver In-Reply-To: <05E62407-1968-4A18-B382-08979C080BD8@ICSI.Berkeley.EDU> Message-ID: References: <0E8EA255-3FE0-4BB5-95EE-4FE0DB776644@icsi.berkeley.edu> <2FC4EE4E1850E64A94DD4E64DC1C886705757E@FHDP1CCMXCV01.us.one.verizon.com> <01D4998C-4746-43D8-ADF7-65258E4F1A52@ICSI.Berkeley.EDU> <05E62407-1968-4A18-B382-08979C080BD8@ICSI.Berkeley.EDU> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Some thoughts on why I would hum no 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, 29 Jul 2008, 1:13pm -0700, Nicholas Weaver wrote: > > On Jul 29, 2008, at 12:53 PM, Y. R. Yang wrote: > > >I think its more that the ISP has an unusual set of incentives: > > > > > >You can build your oracles without ISP cooperation, you don't need ISP > > >cooperation ("Taming Torrents" proved this), and with ISP cooperation it > > >makes > > > >I would have to disagree with abandoning the more direct ISP information. > > > >"Taming torrent" is using the preference of Akamai to guide traffic > >distribution. Akamai is not a neutral entity and has its own incentives > >(e.g., load balancing according to the congestion status of its *own* > >servers). A key question is whether Akamai can know ISP's preferences or > >try to help ISPs. > > > >In terms of ISP incentives, in the P4P implementation and field tests, P2P > >can always override ISP information to both maintain application > >performance and to maintain "fairness". For example, in the implementation > >of current field test, P2P sets a large target for intradomain selection > >before interdomain selection. > > What my point is that you don't need to REQUIURE ISP cooperation, and > that you are far better served building a system which is usable now > without ISP cooperation, but where ISP cooperation can be grafted into > the system cleanly as ISPs want to add their own support and their own > weights. I agree with the incremental deployment requirement. The P4P implementation and field tests do not require ISP cooperation in order to achieve incremental deployment. If a client is in an ISP with no ISP guidance, we use pure AS-locality peering first. The ASN number is from a public database. Inside the ASN, it is random peering, as we have no information and no guidance. We could use some geodistance database to approximate ISP guidance, but this is not very meaningful. > >Again, who runs p4pcache.com and whose preference does it reflect? > > The content provider(s) or a third party service, and the goal is to maximize > aggregate performance. > > EG, there are easy business models: "You give me a hashcode and a penny, and > I'll provide the service for the hashcode. And if the MPAA comes after me, > I'll direct them to you". In the on-going P4P field test, there is an application optimization engine running at Yale. It queries ISPs for ISP information. A P2P application (a Pando swarm) queries the application optimization engine to obtain guidance on how to select peers. I guess this model may fit into your third-party model (a swarm == a hashcode), although with different access protocols (you are trying to reuse DNS while the P4P field test is using a new protocol). One key difference with your model is that the formulation of the optimization engine is to optimize ISP cost (for the joining client) while satisfying constraints on guaranteeing application performance (the aggregate performance you mentioned, I guess). By ignorging ISP cost, your model can avoid the problem of "misleading" by ISP information. But I consider this as an important opportunity missed on improving network efficiency. > If an ISP wants to provide more detail for their customers, they can (and > should) impose their own responses. This is one of the cases where lack of > cryptographic signatures is a Good Thing (tm). > > > >a) You can do it all for the client side (oracle query) by (ab)using DNS > > >today in an already well-abused fashion. > > > >Personally, I would prefer clean, extensible solutions, than abuses :-) > > I guess I don't really think of it as an abuse. > > You want a service that can quickly return a set of IP addresses and I am not sure the right mode is to return a set of IP addresses. Your model assumes that p2pcache.com maintains the state of the hashcode--it remembers those who queried. But this state may become obsolete when clients leave; neither does it have client bandwidth information, unless you add messages to update the state at p2pcache.com. In P4P field test, the query to application optimization engine includes aggregated swarm state information and returns weight matrix. Thus, it becomes more different from DNS and thus the new protocol. > auxiliary information for a hierarchically-addressed record, which is > either generated locally if you have a local authority, or delegated to > the proper remote authority. > > Latency matters as well, you want it to take, if possible, only a single RTT > to get a response. It will be better if it is smaller than one RTT. The application optimization engine response is cached at applications and thus reduces the delay. > And you want an easy to use API for programmers as well, available in as many > languages as possible, so that every P2P program can use this with the > absolute minimum amount of work. Sure. > At the same time, you want universal deployment of the oracle infrastructure > to maximize the benefit. Sure. BTW: I would prefer to use the term "ALTO server" to "oracle". > So actually, I think we are in agreement in the need for a clean extensible > solution, I just believe that the clean, extensible solution is already > present in DNS. I guess I think that it is different enough from DNS to justify a new protocol framework. > > >b) The CDNs already know how to get the information to construct a good > > >oracle on the server side. > > > >My understanding is that the intention is to be good only for CDNs. > > > >It is clear that the solution space is quite large. There are many > >research issues remaining. But I do see strong values in IETF standarzing > >some basic protcols. > > The actual weights for the oracle in the CDN case are to optimize things for > the CDN. But the basic raw data needed should be pretty much the same. So > why reinvent the wheel? > Our formulation is to optimize not only CDN, but ISP costs as well. It fits into enterprise network as well. So we need a new, extensible framework. Of course, if DNS overloading is the more feasible option, we sure can start from here. Richard _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 02: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 86A2D3A6BC7; Wed, 30 Jul 2008 02: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 759193A6B9A for ; Wed, 30 Jul 2008 02:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 34rN6i+q2nEl for ; Wed, 30 Jul 2008 02:23:59 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 495233A6BC7 for ; Wed, 30 Jul 2008 02:23:59 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6U9O5kv012883; Wed, 30 Jul 2008 12:24:06 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:24:05 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:23:59 +0300 Received: from [130.129.23.187] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:23:58 +0300 Message-Id: <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> From: Lars Eggert To: ext Jari Arkko In-Reply-To: <488F2350.5040903@piuha.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 10:23:54 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 09:23:59.0338 (UTC) FILETIME=[FF7134A0:01C8F225] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: [p2pi] why I didn't hum yes (yet) (was: Re: why i hummed no) 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-7-29, at 15:04, ext Jari Arkko wrote: > I was not in the room to hum either way. But for the record, I think > it makes a sense for the IETF to develop a standard for an oracle > functionality -- but for a very specific information, and with > explicit guidance about how such functionality should and should not > be used. I agree with Jari, and said something along similar lines at the mike after the hum: The only reason I didn't hum for ALTO was that I believe the proposed scope is currently too broad. (And for the record I didn't hum against either.) I do believe we should charter something with a more limited scope. What limited scope? Although ALTO mostly focuses on the query/response protocol for information, we can't totally separate this from the kinds of information asked for and disseminated using ALTO. My litmus test is whether we can answer these questions for each piece of information that ALTO could carry: (1) Why is it not easy or cheap for the application to obtain this information in other ways? (2) What's the rough sketch for how an ALTO box would obtain this information in a way that is timely and accurate? (3) Are the incentives aligned such that it is beneficial for the entity who is paying for the ALTO box to do so, *and* for the apps to use it? The only piece of information for which I have people seen giving reasonable answers to these questions is operator preference, as in "which peers would my ISP prefer I communicated with?" I believe hat chartering ALTO at this time with an initial focus on that one bit of information would make sense. I could even see the charter allowing future work that passes the above litmus test. I'm hoping that the P2PRG can be used as a vessel for discussing related ideas that aren't quite ready for an IETF WG, but that would feed into the IETF effort once they're cooked. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 02:56: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 84E403A6BC9; Wed, 30 Jul 2008 02:56: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 AC2173A6BC9 for ; Wed, 30 Jul 2008 02:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 v1Q36tFnZZmK for ; Wed, 30 Jul 2008 02:56:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F23B13A6BAC for ; Wed, 30 Jul 2008 02:56:23 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6U9uLBx030611; Wed, 30 Jul 2008 04:56:34 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:55:53 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:55:39 +0300 Received: from [130.129.23.187] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 12:55:39 +0300 Message-Id: <723C28FA-9A5A-4E09-89C7-5ECB2C6F5E8A@nokia.com> From: Lars Eggert To: ext Lars Eggert In-Reply-To: <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 10:55:33 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 09:55:39.0439 (UTC) FILETIME=[6BFD9BF0:01C8F22A] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) (was: Re: why i hummed no) 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-7-30, at 10:23, ext Lars Eggert wrote: > The only piece of information for which I have people seen giving > reasonable answers to these questions is operator preference, as in > "which peers would my ISP prefer I communicated with?" Having had more coffe, I now remember that I believed that the cost information proposal also had reasonable answers. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 03:10:23 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 98E4D28C2CF; Wed, 30 Jul 2008 03:10: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 40A0E28C2CF for ; Wed, 30 Jul 2008 03:10: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 hdpmYRXo6bkr for ; Wed, 30 Jul 2008 03:10:20 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D69683A6BB7 for ; Wed, 30 Jul 2008 03:10:19 -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 m6UAA5eX021805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 05:10:05 -0500 (CDT) Received: from kickstartf9.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6UA9mj7003659; Wed, 30 Jul 2008 05:09:54 -0500 (CDT) Message-ID: <48903DF1.8030604@alcatel-lucent.com> Date: Wed, 30 Jul 2008 05:09:53 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.14 (X11/20080521) MIME-Version: 1.0 To: Lars Eggert References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> In-Reply-To: <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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: > Although ALTO mostly focuses on the query/response protocol for > information, we can't totally separate this from the kinds of > information asked for and disseminated using ALTO. My litmus test is > whether we can answer these questions for each piece of information that > ALTO could carry: Lars: Thanks for your clarification. The first and last bullet items below are okay -- the last one can conceivably be answered by Henning's presentation. However, the second one confuses me. More inline. > (1) Why is it not easy or cheap for the application > to obtain this information in other ways? > > (2) What's the rough sketch for how an ALTO box would > obtain this information in a way that is timely and accurate? > > (3) Are the incentives aligned such that it is beneficial > for the entity who is paying for the ALTO box to do so, > *and* for the apps to use it? In the list discussions, you have made a case that acquiring information that changes on microseconds level is probably not a good thing. So let's consider acquiring a somewhat static information, like topology. Are you saying that ALTO should specify a rough sketch of how an ALTO box would obtain topological information? So far we have assumed -- and I believe that this is a good assumption -- that this sort of "provisioning" happens behind the scenes and ALTO does not worry about how the data got there. ISPs will use whatever means they have for populating a topological map, and independent third party ALTO services will use Ono, Vivaldi, et al. to acquire such information (as a side effect creating an innovation loop to do this better.) But a hallmark of all this is that ALTO simply queries and receives an answer. How that answer was derived is intentionally left out of scope. Do you agree with this? If not, then will we be in the position of *standardizing* the many ways topological maps must be derived? I don't believe we want to go there, do we? Some clarification would be extremely helpful to Enrico and me as we digest the discussions to create a new charter. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (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 Jul 30 03:30: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 00D053A6BF1; Wed, 30 Jul 2008 03:30: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 8E4223A6BED for ; Wed, 30 Jul 2008 03:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 KPTAf0wClRHy for ; Wed, 30 Jul 2008 03:30:31 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4D02E3A69C3 for ; Wed, 30 Jul 2008 03:30:31 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UAUK4A012983; Wed, 30 Jul 2008 13:30:33 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:30:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:30:21 +0300 Received: from [130.129.23.187] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:30:20 +0300 Message-Id: <5608987A-D217-43D7-81F2-364132280111@nokia.com> From: Lars Eggert To: ext Vijay Gurbani In-Reply-To: <48903DF1.8030604@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 11:30:15 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 10:30:21.0069 (UTC) FILETIME=[44BD23D0:01C8F22F] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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-7-30, at 11:09, ext Vijay Gurbani wrote: > Lars: Thanks for your clarification. The first and last bullet > items below are okay -- the last one can conceivably be answered by > Henning's presentation. However, the second one confuses me. > More inline. > >> (1) Why is it not easy or cheap for the application >> to obtain this information in other ways? >> (2) What's the rough sketch for how an ALTO box would >> obtain this information in a way that is timely and accurate? >> (3) Are the incentives aligned such that it is beneficial >> for the entity who is paying for the ALTO box to do so, >> *and* for the apps to use it? > > In the list discussions, you have made a case that acquiring > information > that changes on microseconds level is probably not a good thing. So > let's consider acquiring a somewhat static information, like topology. Right. I didn't mention this in my earlier email, but IMO frequently changing performance-related information should be out-of-scope for ALTO. Topology-related information is fine, as you say. Or other kinds of information that has similar characteristics, such as about costs. > Are you saying that ALTO should specify a rough sketch of how an ALTO > box would obtain topological information? So far we have assumed -- > and > I believe that this is a good assumption -- that this sort of > "provisioning" happens behind the scenes and ALTO does not worry about > how the data got there. That's a good question - I was unclear. Let me try to expand on this. I would *not* want an ALTO WG to produce documents that specify how an ALTO box gets or maintains the information it makes available. But when we're talking about what kinds of information ALTO can be reasonably expected to be a query/response protocol for, I believe it is important to have an argument on how an ALTO box can be expected to actually have this information. In other words: designing an ALTO query/response protocol with support for queries about a particular kind of information that we have no idea about how an ALTO box would have it or get it is pointless. > ISPs will use whatever means they have for > populating a topological map, and independent third party ALTO > services > will use Ono, Vivaldi, et al. to acquire such information (as a side > effect creating an innovation loop to do this better.) Agreed. > But a hallmark > of all this is that ALTO simply queries and receives an answer. How > that answer was derived is intentionally left out of scope. Do you > agree with this? Agreed. As I said above, my point is that I wouldn't want to complicate the design of this protocol by needing to cater for queries for information that (1) apps can easily get in other ways, (2) we don't know how an ALTO box would get or maintain it and (3) where there is no benefit to the app and the owner of the ALTO box for using it. > If not, then will we be in the position of > *standardizing* the many ways topological maps must be derived? > > I don't believe we want to go there, do we? I agree that we don't. > Some clarification would > be extremely helpful to Enrico and me as we digest the discussions to > create a new charter. I hope I'm being more clear? (My caffein level is low.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 04:26: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 8D74328C1A0; Wed, 30 Jul 2008 04:26: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 8EBA43A6AED for ; Wed, 30 Jul 2008 04:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=1.300, 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 RKoUcFrZBmCX for ; Wed, 30 Jul 2008 04:26:42 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 4728728C14D for ; Wed, 30 Jul 2008 04:26:42 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 13:26:53 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 13:26:53 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 30 Jul 2008 13:26:52 +0200 Message-ID: <48904FEF.5070900@telecomitalia.it> Date: Wed, 30 Jul 2008 12:26:39 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Lars Eggert References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> In-Reply-To: <5608987A-D217-43D7-81F2-364132280111@nokia.com> X-OriginalArrivalTime: 30 Jul 2008 11:26:53.0525 (UTC) FILETIME=[2ACCD850:01C8F237] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] why I didn't hum yes (yet) 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="===============0276557728==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0276557728== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000407040406030708080302" --------------ms000407040406030708080302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars Eggert wrote: > That's a good question - I was unclear. Let me try to expand on this. > > I would *not* want an ALTO WG to produce documents that specify how > an ALTO box gets or maintains the information it makes available. > > But when we're talking about what kinds of information ALTO can be > reasonably expected to be a query/response protocol for, I believe it > is important to have an argument on how an ALTO box can be expected > to actually have this information. In other words: designing an ALTO > query/response protocol with support for queries about a particular > kind of information that we have no idea about how an ALTO box would > have it or get it is pointless. Well, showing how an ALTO service could acquire topology information is what the survey work (both the draft and the presentation) was meant to. Are you suggesting to mention it in the charter, to address it in a different way, or just to stress it more? -- Ciao, Enrico --------------ms000407040406030708080302 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MzAxMTI2MzlaMCMG CSqGSIb3DQEJBDEWBBTKKL8h1OGIeBZO/xnG/LEzeVPvDzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBADCewcvtSwSW hWeiWP+8mIM84e1HlDCLEry8S7K256oUWGQVbrpC4zCTbGaJ/LyAQLqjIu31RJv5v/YoNQ3O hViWLiLnMCBezpe92yIU42QxOQs/8+9gQUCDO1Ybba2BUl+GEsYONWruFA0H3q9HCKJLZ+sP stwzhcOc/oUJS/dh/3krPDJG/rLGQMS+BqMk3uP1PvaNczbd+KBV0b0xid6lGd3XO4dw0GDu 3AQZXt+hgYoLL2fmBMSeysgDKkhmDAXI6fkHIAjjTCzuUlMelGjSAt+wfLJ5fE1aGeGdEWiE rtIDfB7wJL3yGz9c7dc+mUQi0FHHmxHrN+4nJqSODEIAAAAAAAA= --------------ms000407040406030708080302-- --===============0276557728== 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 --===============0276557728==-- From p2pi-bounces@ietf.org Wed Jul 30 04:39: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 D8C5B28C318; Wed, 30 Jul 2008 04:39: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 0E86628C30B for ; Wed, 30 Jul 2008 04:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 rQ+bEKWp3GUS for ; Wed, 30 Jul 2008 04:39:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8E05428C314 for ; Wed, 30 Jul 2008 04:39:54 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UBdsLW004955; Wed, 30 Jul 2008 14:40:04 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 14:39:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 14:39:46 +0300 Received: from lars.meeting.ietf.org ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 14:39:45 +0300 Message-Id: <4D025273-82E7-4D3A-A98D-D05FDB4AED3F@nokia.com> From: Lars Eggert To: ext Enrico Marocco In-Reply-To: <48904FEF.5070900@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 12:39:40 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <48904FEF.5070900@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 11:39:46.0109 (UTC) FILETIME=[F74BCED0:01C8F238] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] why I didn't hum yes (yet) 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-7-30, at 12:26, ext Enrico Marocco wrote: > Lars Eggert wrote: >> That's a good question - I was unclear. Let me try to expand on this. >> >> I would *not* want an ALTO WG to produce documents that specify how >> an ALTO box gets or maintains the information it makes available. >> >> But when we're talking about what kinds of information ALTO can be >> reasonably expected to be a query/response protocol for, I believe it >> is important to have an argument on how an ALTO box can be expected >> to actually have this information. In other words: designing an ALTO >> query/response protocol with support for queries about a particular >> kind of information that we have no idea about how an ALTO box would >> have it or get it is pointless. > > Well, showing how an ALTO service could acquire topology information > is > what the survey work (both the draft and the presentation) was meant > to. My take-away from that part of the BOF was that there are many, many ideas for what kinds of topology-related (and other) information ALTO could provide, as demonstrated by the survey of existing (research) work. I didn't get a clear picture about which exact pieces of information we're expecting an IETF effort to standardize a query protocol for. My comment is that I question whether if it useful to design ALTO to query for information that (1) is readily available to an application by other means, (2) we don't know where it would come from or what it would be good for, and (3) that doesn't have the correct incentives associated with it such that there was a benefit to providing and using it. > Are you suggesting to mention it in the charter, to address it in a > different way, or just to stress it more? I'd like the charter to explicitly list exactly which pieces of information ALTO will be a query protocol for, at least initially. ("Topology-related information" is very vague.) For each of those pieces, I'd like to see the answers to the three "litmus test" questions from my earlier email (not in the charter, in an email or such.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 06:00: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 2BD893A689D; Wed, 30 Jul 2008 06:00: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 EEBCF3A689D for ; Wed, 30 Jul 2008 06:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 DOhlxvnFop4f for ; Wed, 30 Jul 2008 06:00:54 -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 E31003A688B for ; Wed, 30 Jul 2008 06:00:54 -0700 (PDT) Received: from [130.129.18.222] (helo=aeolus.meeting.ietf.org) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KOBIa-0002un-DS; Wed, 30 Jul 2008 06:01:01 -0700 Message-Id: <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> From: Philip Levis To: Lars Eggert In-Reply-To: <5608987A-D217-43D7-81F2-364132280111@nokia.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 14:00:58 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> X-Mailer: Apple Mail (2.926) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Jul 30, 2008, at 11:30 AM, Lars Eggert wrote: > Hi, > > On 2008-7-30, at 11:09, ext Vijay Gurbani wrote: >> Lars: Thanks for your clarification. The first and last bullet >> items below are okay -- the last one can conceivably be answered by >> Henning's presentation. However, the second one confuses me. >> More inline. >> >>> (1) Why is it not easy or cheap for the application >>> to obtain this information in other ways? >>> (2) What's the rough sketch for how an ALTO box would >>> obtain this information in a way that is timely and accurate? >>> (3) Are the incentives aligned such that it is beneficial >>> for the entity who is paying for the ALTO box to do so, >>> *and* for the apps to use it? >> >> In the list discussions, you have made a case that acquiring >> information >> that changes on microseconds level is probably not a good thing. So >> let's consider acquiring a somewhat static information, like >> topology. > > Right. I didn't mention this in my earlier email, but IMO frequently > changing performance-related information should be out-of-scope for > ALTO. > > Topology-related information is fine, as you say. Or other kinds of > information that has similar characteristics, such as about costs. I think there are some misconceptions here about the intended scope of an Oracle's role. I'd argue -- and this agrees with what was in the presentation -- that the Oracle should not communicate complex information. The request is a list of resources (e.g., peers) and the response is a list of resources that is a subset of the request, perhaps ordered differently. There's a reason why such a simple interface is desirable: it's what a client might actually use. As others have pointed out, p2p clients today continuously monitor the runtime performance of a subset of available peers. Distribution systems like bittorrent choke based on throughput, while lookup systems like Chord or other DHTs typically use latency. Clients use this runtime information to choose which of their set of potential peers they actively use. A client cannot monitor the runtime performance of communication with 10,000 other clients. So while run-time monitoring is necessary for good performance, clients greatly benefit from some guidance or recommendation on which peers to monitor. The problem with having a set of 100 randomly chosen peers is even probing all of them to find which 5-6 are 50-300% better than the others can be very expensive. So rather than give a client a set of random peers, an entity in the network can give the client a set of peers which, for whatever reason, are far to the right on the desired performance distribution. Or, give recommendations on which might be better than others. Numerous studies have shown that, in the wild on real p2p applications today, information such as a rough sense of the network topology can allow a node in the network to give a client a very good set of peers that lead to significant performance gains. The problem is that collecting all of this information is expensive and requires a lot of effort. You don't want to have every client trying to generate an AS map. So instead you have some set of nodes that compute this topology information (iPlane is one example), and can then answer queries about peers using it. The intention isn't that a client asks an Oracle for some tiny set of peers to use. Rather, a client can give an Oracle a set of peers, and the Oracle gives rough recommendations on which peers might be good. The client of course then has to monitor these at runtime. It might be that the best 4 peers in terms of network proximity are heavily loaded, so the client wants to use the next 4 closest instead. There's a difference in time scale. You can't expect an Oracle to be able to measure performance as quickly or accurately as the client itself can, nor can you expect a client to spend the effort and time to generate the same long-term information the Oracle can. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 06: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 B959228C12B; Wed, 30 Jul 2008 06: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 991613A6783 for ; Wed, 30 Jul 2008 06:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9qbHIIQq1wNJ for ; Wed, 30 Jul 2008 06:32:43 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 2E58A3A6843 for ; Wed, 30 Jul 2008 06:32:43 -0700 (PDT) Received: from [130.129.19.238] ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6UDWpKj019588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Jul 2008 09:32:53 -0400 (EDT) Message-Id: <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> From: Henning Schulzrinne To: Philip Levis In-Reply-To: <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 09:32:51 -0400 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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="===============0706412932==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0706412932== Content-Type: multipart/alternative; boundary=Apple-Mail-15-746886500 --Apple-Mail-15-746886500 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >> >> I think there are two useful queries, with the same input ("IP address P"): (1) relative ordering of a set of an IP addresses; the ordering is expected to be correct in some average sense, similar to one would order Rome > Dublin > Reykjavik in terms of average temperature. This doesn't mean that on any given day Dublin is colder than Rome, just that this is likely. This my short version of the description below. (2) Returning topology-related information for one or more IP addresses. This could be either equalities ("X1 is in the same AS as X2") or absolute values ("X1 is in AS 16"). The type of information we know how to produce, but have trouble obtaining in non-kludgey fashions today, include AS number, provider name, continent (or country), subnet. More sophisticated versions would include some notion of network distance, in some network coordinate system. A low- hanging fruit is to simply return the three or four coarse topology metrics and then add more as experience increases. A query unifying the above would include the list X1, ..,, Xn, and return an ordered list, with the coarse topology information above. Henning > > I think there are some misconceptions here about the intended scope > of an Oracle's role. I'd argue -- and this agrees with what was in > the presentation -- that the Oracle should not communicate complex > information. The request is a list of resources (e.g., peers) and > the response is a list of resources that is a subset of the request, > perhaps ordered differently. There's a reason why such a simple > interface is desirable: it's what a client might actually use. > > As others have pointed out, p2p clients today continuously monitor > the runtime performance of a subset of available peers. Distribution > systems like bittorrent choke based on throughput, while lookup > systems like Chord or other DHTs typically use latency. Clients use > this runtime information to choose which of their set of potential > peers they actively use. > > A client cannot monitor the runtime performance of communication > with 10,000 other clients. So while run-time monitoring is necessary > for good performance, clients greatly benefit from some guidance or > recommendation on which peers to monitor. The problem with having a > set of 100 randomly chosen peers is even probing all of them to find > which 5-6 are 50-300% better than the others can be very expensive. > So rather than give a client a set of random peers, an entity in the > network can give the client a set of peers which, for whatever > reason, are far to the right on the desired performance > distribution. Or, give recommendations on which might be better than > others. > > Numerous studies have shown that, in the wild on real p2p > applications today, information such as a rough sense of the network > topology can allow a node in the network to give a client a very > good set of peers that lead to significant performance gains. The > problem is that collecting all of this information is expensive and > requires a lot of effort. You don't want to have every client trying > to generate an AS map. So instead you have some set of nodes that > compute this topology information (iPlane is one example), and can > then answer queries about peers using it. > > The intention isn't that a client asks an Oracle for some tiny set > of peers to use. Rather, a client can give an Oracle a set of peers, > and the Oracle gives rough recommendations on which peers might be > good. The client of course then has to monitor these at runtime. It > might be that the best 4 peers in terms of network proximity are > heavily loaded, so the client wants to use the next 4 closest instead. > > There's a difference in time scale. You can't expect an Oracle to be > able to measure performance as quickly or accurately as the client > itself can, nor can you expect a client to spend the effort and time > to generate the same long-term information the Oracle can. > > Phil > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi --Apple-Mail-15-746886500 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable



=
I think there are two useful queries, with the same input ("IP = address P"):

(1) relative ordering of a set of = an IP addresses; the ordering is expected to be correct in some average = sense, similar to one would order Rome > Dublin > Reykjavik in = terms of average temperature. This doesn't mean that on any given day = Dublin is colder than Rome, just that this is likely. This my short = version of the description below.

(2) Returning = topology-related information for one or more IP addresses. This could be = either equalities ("X1 is in the same AS as X2") or absolute values ("X1 = is in AS 16"). The type of information we know how to produce, but have = trouble obtaining in non-kludgey fashions today, include AS number, = provider name, continent (or country), subnet. More sophisticated = versions would include some notion of network distance, in some network = coordinate system. A low-hanging fruit is to simply return the three or = four coarse topology metrics and then add more as experience = increases.

A query unifying the above would = include the list X1, ..,, Xn, and return an ordered list, with the = coarse topology information = above.

Henning



I think there are some misconceptions here = about the intended scope of an Oracle's role. I'd argue -- and this = agrees with what was in the presentation -- that the Oracle should not = communicate complex information. The request is a list of resources = (e.g., peers) and the response is a list of resources that is a subset = of the request, perhaps ordered differently. There's a reason why such a = simple interface is desirable: it's what a client might actually = use.

As others have pointed out, p2p clients today continuously = monitor the runtime performance of a subset of available peers. = Distribution systems like bittorrent choke based on throughput, while = lookup systems like Chord or other DHTs typically use latency. Clients = use this runtime information to choose which of their set of potential = peers they actively use.

A client cannot monitor the runtime = performance of communication with 10,000 other clients. So while = run-time monitoring is necessary for good performance, clients greatly = benefit from some guidance or recommendation on which peers to monitor. = The problem with having a set of 100 randomly chosen peers is even = probing all of them to find which 5-6 are 50-300% better than the others = can be very expensive. So rather than give a client a set of random = peers, an entity in the network can give the client a set of peers = which, for whatever reason, are far to the right on the desired = performance distribution. Or, give recommendations on which might be = better than others.

Numerous studies have shown that, in the wild = on real p2p applications today, information such as a rough sense of the = network topology can allow a node in the network to give a client a very = good set of peers that lead to significant performance gains. The = problem is that collecting all of this information is expensive and = requires a lot of effort. You don't want to have every client trying to = generate an AS map. So instead you have some set of nodes that compute = this topology information (iPlane is one example), and can then answer = queries about peers using it.

The intention isn't that a client = asks an Oracle for some tiny set of peers to use. Rather, a client can = give an Oracle a set of peers, and the Oracle gives rough = recommendations on which peers might be good. The client of course then = has to monitor these at runtime. It might be that the best 4 peers in = terms of network proximity are heavily loaded, so the client wants to = use the next 4 closest instead.

There's a difference in time = scale. You can't expect an Oracle to be able to measure performance as = quickly or accurately as the client itself can, nor can you expect a = client to spend the effort and time to generate the same long-term = information the Oracle = can.

Phil
_______________________________________________
p2p= i mailing list
p2pi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/p2pi

= --Apple-Mail-15-746886500-- --===============0706412932== 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 --===============0706412932==-- From p2pi-bounces@ietf.org Wed Jul 30 06:39: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 E3AB028C2E7; Wed, 30 Jul 2008 06:39: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 A639728C2FA for ; Wed, 30 Jul 2008 06:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 1ptSRm28Lz+9 for ; Wed, 30 Jul 2008 06:39:08 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id CA77C3A6768 for ; Wed, 30 Jul 2008 06:39:08 -0700 (PDT) Received: from [130.129.18.222] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KOBtj-00084X-AN; Wed, 30 Jul 2008 06:39:23 -0700 Message-Id: <36074C3F-6BA6-4A5F-AA6C-59C8FEA82122@cs.stanford.edu> From: Philip Levis To: Henning Schulzrinne In-Reply-To: <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 14:39:21 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> X-Mailer: Apple Mail (2.926) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Jul 30, 2008, at 2:32 PM, Henning Schulzrinne wrote: > >>> >>> > > I think there are two useful queries, with the same input ("IP > address P"): > > (1) relative ordering of a set of an IP addresses; the ordering is > expected to be correct in some average sense, similar to one would > order Rome > Dublin > Reykjavik in terms of average temperature. > This doesn't mean that on any given day Dublin is colder than Rome, > just that this is likely. This my short version of the description > below. > > (2) Returning topology-related information for one or more IP > addresses. This could be either equalities ("X1 is in the same AS as > X2") or absolute values ("X1 is in AS 16"). The type of information > we know how to produce, but have trouble obtaining in non-kludgey > fashions today, include AS number, provider name, continent (or > country), subnet. More sophisticated versions would include some > notion of network distance, in some network coordinate system. A low- > hanging fruit is to simply return the three or four coarse topology > metrics and then add more as experience increases. Why do you think an end-client wants/needs this information? I'm skeptical on depending on clients to take actions that benefit someone else (e.g., ISP) but harm them. The reason why the ordered list is so promising is that it turns out often the two optimization problems lead to very similar solutions. At the very least, I'd argue separating (1) and (2) in terms of specification. (1) is so simple that it would be easy to nail it down, while (2) would require a bit more work. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 06:41:53 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 066703A6946; Wed, 30 Jul 2008 06:41:53 -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 B61293A68ED for ; Wed, 30 Jul 2008 06:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 WioMYfTVX-m4 for ; Wed, 30 Jul 2008 06:41:45 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BDDE03A68A2 for ; Wed, 30 Jul 2008 06:41:44 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 14:41:59 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 14:41:59 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217425319197; Wed, 30 Jul 2008 14:41:59 +0100 Received: from mut.jungle.bt.co.uk ([10.73.83.52]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6UDficH027894 for ; Wed, 30 Jul 2008 14:41:55 +0100 Message-Id: <200807301341.m6UDficH027894@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jul 2008 14:41:42 +0100 To: p2pi@ietf.org From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jul 2008 13:41:59.0245 (UTC) FILETIME=[0A2F8FD0:01C8F24A] Subject: Re: [p2pi] why i hummed no 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, I'm going to split my reasons for humming no into procedural and technical. Procedural ---------- The BoF's problem description scared me. 1) Vagueness was introduced to avoid deciding what the problem was. 2) I wasn't happy to leave an ALTO w-g to finesse such a vague problem statement. Particularly given I judged that the large majority of those who would work on the problem didn't seem to be listening to advice on why their model of the world was partial. Doing localisation would be easy to standardise, but I believe it SHOULD NOT be the goal. Doing the proper thing: policy-controlled path-selection advice ('conditional localisation') is still a research problem, IMHO. It's likely solutions like we already have from P4P are better, but the claims of 'better' so far given on this list use inappropriate metrics to judge 'better' (see next mail). Not knowing what 'better' means smells like a research problem to me. * At the p2pi workshop in Boston, at least some people were saying that localisation wasn't the goal (eg. the P4P guys) - their solutions allowed ISPs to judge that paths to remote peers could be better than local. * However, /everyone/ presenting in the ALTO BoF didn't seem to have even considered that localisation might not be a sensible goal. My thinking: even if the w-g decides that localisation is NOT a goal, what hope do we have that all those people who started out not understanding this, will be capable of dealing with a much more researchy problem: an optimisation that is NOT trying to localise per se. Technical --------- Next mail I'll give more reasons than have so far been given on this list for why unconditional localisation SHOULD NOT be a goal - from both ISP and user perspectives. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 06:42: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 45A5F3A69F7; Wed, 30 Jul 2008 06:42: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 38FB33A69F7 for ; Wed, 30 Jul 2008 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.107 X-Spam-Level: * X-Spam-Status: No, score=1.107 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_57=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18B=0.331] 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 SaBTWiaKmjnv for ; Wed, 30 Jul 2008 06:42:33 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F07743A69D6 for ; Wed, 30 Jul 2008 06:42:32 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 14:42:46 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 14:42:46 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217425368545; Wed, 30 Jul 2008 14:42:48 +0100 Received: from mut.jungle.bt.co.uk ([10.73.83.52]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6UDgdGQ027985 for ; Wed, 30 Jul 2008 14:42:43 +0100 Message-Id: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jul 2008 14:42:43 +0100 To: p2pi@ietf.org From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jul 2008 13:42:46.0958 (UTC) FILETIME=[269FFCE0:01C8F24A] Subject: Re: [p2pi] why i hummed no 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="===============2038315928==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2038315928== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks,

Following my last mail on procedural reasons, here's my technical reasons.

Technical
---------
I've drawn a picture (very simplified), as I think some people wanted to have a better model of what commercial residential networks look like.
< http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-briscoe.p= df >
Text in the above slideset is repeated below, numbered by slide...

2. Localisation is NOT consistently desirable
------------------------------------------
whether by AS count, hop count, RTT, ...

* for ISPs (slide #3)
=96using an interconnect path may impact other users less and not cost the ISP more
  a)upstream backhaul link
  o in some access technologies (e.g DSL) the upstream backhaul is never congested =96 it's typically a symmetric link fed by an asymmetric access
  o retail ISPs often lease this link without any upstream usage penalties

  b)interconnect
  o if interconnect charging is based on 95th percentile and it's currently not near the 95th percentile
  o or if interconnect is based on a peering contract which only requires the balance of volume transferred between networks to be checked at peak times, and it's currently not a peak time

* For users & apps (slide #4)
  o with newer cc algos, longer RTT hardly requires slower rate
  o desire for shorter RTT to get higher rate will go away

3. ISPs could prefer inter-domain path
--------------------------------------
<picture> - see slide

4. Lower RTT isn't nearly as good as we thought
-----------------------------------------------
for long-lived flows

* app desire for localisation is artefact of TCP algo
  - TCP average rate depends on 1/RTT (for similarly congested paths)
* modern congestion control algos don't do this
  - FAST TCP [Jin04], BitTorrent DNA (rate-based mode)
* for stability, doesn't rate need to depend on 1/RTT?
  - No. Research agrees only acceleration needs to
  - Equilibrium rate can be independent of RTT
  (see slide #4 for a typical example)

5. What metric judges 'better'?
-------------------------------
* NOT lower inter-domain traffic (necessarily)
  - if at the cost of more local upstream congestion
* NOT faster downloads (necessarily)
  - if at the expense of slower downloads for non-P2P users

6. closing message
------------------
* localisation is only desirable conditionally
  - over some inter-domain paths, at some times, with some transports
* updating an inter-domain oracle for dynamic path-specific info is not proven feasible
  - hard even for a single residential ISP
    =96e.g. 20M access lines =3D>  20M2 paths (400,000,000,000,000 paths)
    =96and that doesn't include home network segments
    =96even edge-edge, 7,000 access multiplexers =3D> 50M paths
  - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,000,000 edge-edge paths
* nonetheless, topology-based heuristics modified by static policy (e.g. P4P) are perhaps 'better' than random guesses
* but "localisation is good" MUST NOT be the goal
  - that will lead to the DISINTERNET
* localisation would be easy,... but if it's NOT the goal
  - is an oracle appropriate for standards activity or only for more research?

Cheers


Bob

____________________________________________________________________________=
Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 --===============2038315928== 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 --===============2038315928==-- From p2pi-bounces@ietf.org Wed Jul 30 06:51: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 933CD3A6939; Wed, 30 Jul 2008 06:51: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 65A3F3A6856 for ; Wed, 30 Jul 2008 06:51:24 -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 Y9+ExqdbYqa1 for ; Wed, 30 Jul 2008 06:51:22 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id BBEE23A6A82 for ; Wed, 30 Jul 2008 06:51:21 -0700 (PDT) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.251.2; Wed, 30 Jul 2008 06:51:36 -0700 Received: from NA-EXMSG-C102.redmond.corp.microsoft.com ([157.54.110.49]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.54.46.188]) with mapi; Wed, 30 Jul 2008 06:51:36 -0700 From: Yu-Shun Wang To: Philip Levis , Lars Eggert Date: Wed, 30 Jul 2008 06:51:31 -0700 Thread-Topic: [p2pi] why I didn't hum yes (yet) Thread-Index: AcjyRF4bin7TpOC2QiqT2a3vs6tuqQAADTKw Message-ID: <43AEA9A9F7768B42A89F554F0EBF7ED828B7E525C7@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> In-Reply-To: <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.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" Subject: Re: [p2pi] why I didn't hum yes (yet) 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, Comments inline. Thanks, yushun > -----Original Message----- > > > > Right. I didn't mention this in my earlier email, but IMO frequently > > changing performance-related information should be out-of-scope for > > ALTO. > > > > Topology-related information is fine, as you say. Or other kinds of > > information that has similar characteristics, such as about costs. > > I think there are some misconceptions here about the intended scope of > an Oracle's role. I'd argue -- and this agrees with what was in the > presentation -- that the Oracle should not communicate complex > information. The request is a list of resources (e.g., peers) and the > response is a list of resources that is a subset of the request, > perhaps ordered differently. There's a reason why such a simple > interface is desirable: it's what a client might actually use. While simplicity is good in general, if the protocol is going to be more generic than just for P2P, some indication of what criteria is used to determine the list need to be provided. Actually, one could argue even for P2P apps, there will be need for different criteria. And that could potentially be an extensible option in the protocol. But for each type of criteria, I agree that we don't want to encode complex information. > As others have pointed out, p2p clients today continuously monitor the > runtime performance of a subset of available peers. Distribution > systems like bittorrent choke based on throughput, while lookup > systems like Chord or other DHTs typically use latency. Clients use > this runtime information to choose which of their set of potential > peers they actively use. So there is potential need for different types of criteria. > A client cannot monitor the runtime performance of communication with > 10,000 other clients. So while run-time monitoring is necessary for > good performance, clients greatly benefit from some guidance or > recommendation on which peers to monitor. The problem with having a > set of 100 randomly chosen peers is even probing all of them to find > which 5-6 are 50-300% better than the others can be very expensive. So > rather than give a client a set of random peers, an entity in the > network can give the client a set of peers which, for whatever reason, > are far to the right on the desired performance distribution. Or, give > recommendations on which might be better than others. This is arguing for the Oracle approach as oppose to dynamic measurements done on each client. I agree there's a scalability issue for the latter, but also want to point out that the Oracle may not necessarily have (provisioned or pre-computed) all the info on the potentially random list of nodes in the queries. It all depends on the type of criteria that is used for the queries/selection. > Numerous studies have shown that, in the wild on real p2p applications > today, information such as a rough sense of the network topology can > allow a node in the network to give a client a very good set of peers > that lead to significant performance gains. The problem is that > collecting all of this information is expensive and requires a lot of > effort. You don't want to have every client trying to generate an AS > map. So instead you have some set of nodes that compute this topology > information (iPlane is one example), and can then answer queries about > peers using it. > > The intention isn't that a client asks an Oracle for some tiny set of > peers to use. Rather, a client can give an Oracle a set of peers, and > the Oracle gives rough recommendations on which peers might be good. > The client of course then has to monitor these at runtime. It might be > that the best 4 peers in terms of network proximity are heavily > loaded, so the client wants to use the next 4 closest instead. Not that I disagree with the rationale or example, but it actually sorts the list based on first locality then load. I guess my question is what kind of semantics are we going to impose on the queries and answers? I haven't seen it clearly stated yet. > There's a difference in time scale. You can't expect an Oracle to be > able to measure performance as quickly or accurately as the client > itself can, nor can you expect a client to spend the effort and time > to generate the same long-term information the Oracle can. Agreed. That is also why Lars wants to take the performance part out of the charter (if it is on the table). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 06:55: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 D85443A683E; Wed, 30 Jul 2008 06:55: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 05FDB3A6820 for ; Wed, 30 Jul 2008 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[AWL=-1.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_57=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18B=0.331] 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 mkqkrQN4Sv24 for ; Wed, 30 Jul 2008 06:55:17 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 69C8D3A68C1 for ; Wed, 30 Jul 2008 06:55:16 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 06:55:20 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 06:53:13 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jul 2008 09:53:12 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Jul 2008 13:53:11 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 30 Jul 2008 06:53:08 -0700 From: Reinaldo Penno To: Bob Briscoe , Message-ID: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjyS5jLriNAQ8wzr0CIqAt5X1HtfA== In-Reply-To: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> Mime-version: 1.0 X-OriginalArrivalTime: 30 Jul 2008 13:53:12.0203 (UTC) FILETIME=[9B4CCDB0:01C8F24B] Subject: Re: [p2pi] why i hummed no 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="===============0824920478==" 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. --===============0824920478== Content-type: multipart/alternative; boundary="B_3300245588_1186514" > 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_3300245588_1186514 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello Bob, Actually I sent an email about this issue some time back and some people agreed with it. It talked about the fact that some ISPs/Telcos would prefer P2P to use inter-domain links. Check http://www.ietf.org/mail-archive/web/p2pi/current/msg00212.html Thanks, Reinaldo On 7/30/08 6:42 AM, "Bob Briscoe" wrote: > Folks, >=20 > Following my last mail on procedural reasons, here's my technical reasons= . >=20 > Technical > --------- > I've drawn a picture (very simplified), as I think some people wanted to = have > a better model of what commercial residential networks look like. > <=20 > http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-brisco= e.pdf > f> > > Text in the above slideset is repeated below, numbered by slide... >=20 > 2. Localisation is NOT consistently desirable > ------------------------------------------ > whether by AS count, hop count, RTT, ... >=20 > * for ISPs (slide #3) > =96using an interconnect path may impact other users less and not cost the = ISP > more > a)upstream backhaul link > o in some access technologies (e.g DSL) the upstream backhaul is never > congested =96 it's typically a symmetric link fed by an asymmetric access > o retail ISPs often lease this link without any upstream usage penaltie= s >=20 > b)interconnect > o if interconnect charging is based on 95th percentile and it's current= ly > not near the 95th percentile > o or if interconnect is based on a peering contract which only requires= the > balance of volume transferred between networks to be checked at peak time= s, > and it's currently not a peak time >=20 > * For users & apps (slide #4) > o with newer cc algos, longer RTT hardly requires slower rate > o desire for shorter RTT to get higher rate will go away >=20 > 3. ISPs could prefer inter-domain path > -------------------------------------- > - see slide >=20 > 4. Lower RTT isn't nearly as good as we thought > ----------------------------------------------- > for long-lived flows >=20 > * app desire for localisation is artefact of TCP algo > - TCP average rate depends on 1/RTT (for similarly congested paths) > * modern congestion control algos don't do this > - FAST TCP [Jin04], BitTorrent DNA (rate-based mode) > * for stability, doesn't rate need to depend on 1/RTT? > - No. Research agrees only acceleration needs to > - Equilibrium rate can be independent of RTT > (see slide #4 for a typical example) >=20 > 5. What metric judges 'better'? > ------------------------------- > * NOT lower inter-domain traffic (necessarily) > - if at the cost of more local upstream congestion > * NOT faster downloads (necessarily) > - if at the expense of slower downloads for non-P2P users >=20 > 6. closing message > ------------------ > * localisation is only desirable conditionally > - over some inter-domain paths, at some times, with some transports > * updating an inter-domain oracle for dynamic path-specific info is not p= roven > feasible > - hard even for a single residential ISP > =96e.g. 20M access lines =3D> 20M2 paths (400,000,000,000,000 paths) > =96and that doesn't include home network segments > =96even edge-edge, 7,000 access multiplexers =3D> 50M paths > - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,000,000 edge-= edge > paths > * nonetheless, topology-based heuristics modified by static policy (e.g. = P4P) > are perhaps 'better' than random guesses > * but "localisation is good" MUST NOT be the goal > - that will lead to the DISINTERNET > * localisation would be easy,... but if it's NOT the goal > - is an oracle appropriate for standards activity or only for more rese= arch? >=20 > Cheers >=20 >=20 > Bob >=20 >=20 > _________________________________________________________________________= ___ > Bob Briscoe, Networks Research Centre, BT Resear= ch > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645= 196 >=20 > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi --B_3300245588_1186514 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [p2pi] why i hummed no Hello Bob,

Actually I sent an email about this issue some time back and some people ag= reed with it. It talked about the fact that some ISPs/Telcos would prefer P2= P to use inter-domain links.

Check http://www.ietf.org/mail-archive/web/p2pi/current/msg00212.html

Thanks,

Reinaldo


On 7/30/08 6:42 AM, "Bob Briscoe" <rbriscoe@jungle.bt.co.uk> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Folks,

Following my last mail on procedural reasons, here's my technical reasons.<= BR>
Technical
---------
I've drawn a picture (very simplified), as I think some people wanted to ha= ve a better model of what commercial residential networks look like.
< http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf= /0807alto-briscoe.pdf <http://www.cs.ucl.ac.uk/staff/B.B= riscoe/presents/0807ietf/0807alto-briscoe.pdf> >
Text in the above slideset is repeated below, numbered by slide...

2. Localisation is NOT consistently desirable
------------------------------------------
whether by AS count, hop count, RTT, ...

* for ISPs (slide #3)
ˆusing an interconnect path may impact other users less and not cost t= he ISP more
  a)upstream backhaul link
  o in some access technologies (e.g DSL) the upstream backhaul i= s never congested ˆ it's typically a symmetric link fed by an asymmetri= c access
  o retail ISPs often lease this link without any upstream usage = penalties

  b)interconnect
  o if interconnect charging is based on 95th percentile and it's= currently not near the 95th percentile
  o or if interconnect is based on a peering contract which only = requires the balance of volume transferred between networks to be checked at= peak times, and it's currently not a peak time

* For users & apps (slide #4)
  o with newer cc algos, longer RTT hardly requires slower rate   o desire for shorter RTT to get higher rate will go away

3. ISPs could prefer inter-domain path
--------------------------------------
<picture> - see slide

4. Lower RTT isn't nearly as good as we thought
-----------------------------------------------
for long-lived flows

* app desire for localisation is artefact of TCP algo
  - TCP average rate depends on 1/RTT (for similarly congested pa= ths)
* modern congestion control algos don't do this
  - FAST TCP [Jin04], BitTorrent DNA (rate-based mode)
* for stability, doesn't rate need to depend on 1/RTT?
  - No. Research agrees only acceleration needs to
  - Equilibrium rate can be independent of RTT
  (see slide #4 for a typical example)

5. What metric judges 'better'?
-------------------------------
* NOT lower inter-domain traffic (necessarily)
  - if at the cost of more local upstream congestion
* NOT faster downloads (necessarily)
  - if at the expense of slower downloads for non-P2P users

6. closing message
------------------
* localisation is only desirable conditionally
  - over some inter-domain paths, at some times, with some transp= orts
* updating an inter-domain oracle for dynamic path-specific info is not pro= ven feasible
  - hard even for a single residential ISP
    ˆe.g. 20M access lines =3D>  20M2 paths = (400,000,000,000,000 paths)
    ˆand that doesn't include home network segment= s
    ˆeven edge-edge, 7,000 access multiplexers =3D&g= t; 50M paths
  - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,00= 0,000 edge-edge paths
* nonetheless, topology-based heuristics modified by static policy (e.g. P4= P) are perhaps 'better' than random guesses
* but "localisation is good" MUST NOT be the goal
  - that will lead to the DISINTERNET
* localisation would be easy,... but if it's NOT the goal
  - is an oracle appropriate for standards activity or only for m= ore research?

Cheers


Bob


___________________________________________________________________________= _
Bob Briscoe, <bob.briscoe@bt.com> &n= bsp;   Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    = ;+44 1473 645196
___________= ____________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/m= ailman/listinfo/p2pi
--B_3300245588_1186514-- --===============0824920478== 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 --===============0824920478==-- From p2pi-bounces@ietf.org Wed Jul 30 06:59: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 9309E28C2DF; Wed, 30 Jul 2008 06:59: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 722E928C2E7 for ; Wed, 30 Jul 2008 06:59:12 -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=[AWL=0.000, 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 UBrovTq-aEdq for ; Wed, 30 Jul 2008 06:59:11 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 96DFF28C2CD for ; Wed, 30 Jul 2008 06:59:11 -0700 (PDT) Received: from [130.129.19.238] ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6UDxKjG028129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Jul 2008 09:59:23 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Philip Levis In-Reply-To: <36074C3F-6BA6-4A5F-AA6C-59C8FEA82122@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 09:59:19 -0400 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <36074C3F-6BA6-4A5F-AA6C-59C8FEA82122@cs.stanford.edu> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 do you think an end-client wants/needs this information? I'm > skeptical on depending on clients to take actions that benefit > someone else (e.g., ISP) but harm them. The reason why the ordered > list is so promising is that it turns out often the two optimization > problems lead to very similar solutions. > If it turns out that for a particular client (P2P or otherwise), it finds that this information correlates well with good performance, the client has an incentive to use it. This makes it easy to develop client/application-specific algorithms that rely on common information, rather than having each client spend a lot of kludgey effort (such as querying looking glass sites) to get at the data. There seems to be significant published evidence that these metrics do correlate, on average, with improved performance, even if they occasionally miss the boat. It's the averages we care about, as long as the outliers aren't ridiculously bad and can be detected at run time. > At the very least, I'd argue separating (1) and (2) in terms of > specification. (1) is so simple that it would be easy to nail it > down, while (2) would require a bit more work. Depends on the level of detail reported. The items I mentioned seem trivial and extending the list later seems easy. > > > Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 07:10:02 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 14E9D28C26E; Wed, 30 Jul 2008 07:10:02 -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 9536C3A6AA9 for ; Wed, 30 Jul 2008 07:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_18=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 4bYffNMJpOfM for ; Wed, 30 Jul 2008 07:09:59 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 232813A6B19 for ; Wed, 30 Jul 2008 07:09:58 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 16:10:06 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 16:10:05 +0200 Received: from [172.16.82.10] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 30 Jul 2008 16:10:05 +0200 Message-ID: <48907621.6090807@telecomitalia.it> Date: Wed, 30 Jul 2008 15:09:37 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Bob Briscoe References: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> In-Reply-To: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 30 Jul 2008 14:10:05.0993 (UTC) FILETIME=[F790E190:01C8F24D] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] why i hummed no 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="===============1763161238==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1763161238== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050205060007050605090605" --------------ms050205060007050605090605 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bob, ALTO is not about "localization" only (which, btw, is quite an ambiguous term, best avoided). Probably we have not made it clear enough, but AFAIR network policies are always mentioned amongst possible criteria to rank peers. Anyway, thank you for your contribution, it will help people in understanding the problem are and hopefully will foster some discussion. Enrico Bob Briscoe wrote: > Folks, >=20 > Following my last mail on procedural reasons, here's my technical reaso= ns. >=20 > Technical > --------- > I've drawn a picture (very simplified), as I think some people wanted t= o > have a better model of what commercial residential networks look like. > < > http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-bris= coe.pdf >> > Text in the above slideset is repeated below, numbered by slide... >=20 > 2. Localisation is NOT consistently desirable > ------------------------------------------ > whether by AS count, hop count, RTT, ... >=20 > * for ISPs (slide #3) > =96using an interconnect path may impact other users less and not cost = the > ISP more > a)upstream backhaul link > o in some access technologies (e.g DSL) the upstream backhaul is neve= r > congested =96 it's typically a symmetric link fed by an asymmetric acce= ss > o retail ISPs often lease this link without any upstream usage penalt= ies >=20 > b)interconnect > o if interconnect charging is based on 95th percentile and it's > currently not near the 95th percentile > o or if interconnect is based on a peering contract which only > requires the balance of volume transferred between networks to be > checked at peak times, and it's currently not a peak time >=20 > * For users & apps (slide #4) > o with newer cc algos, longer RTT hardly requires slower rate > o desire for shorter RTT to get higher rate will go away >=20 > 3. ISPs could prefer inter-domain path > -------------------------------------- > - see slide >=20 > 4. Lower RTT isn't nearly as good as we thought > ----------------------------------------------- > for long-lived flows >=20 > * app desire for localisation is artefact of TCP algo > - TCP average rate depends on 1/RTT (for similarly congested paths) > * modern congestion control algos don't do this > - FAST TCP [Jin04], BitTorrent DNA (rate-based mode) > * for stability, doesn't rate need to depend on 1/RTT? > - No. Research agrees only /acceleration /needs to > - Equilibrium rate can be independent of RTT > (see slide #4 for a typical example) >=20 > 5. What metric judges 'better'? > ------------------------------- > * NOT lower inter-domain traffic (necessarily) > - if at the cost of more local upstream congestion > * NOT faster downloads (necessarily) > - if at the expense of slower downloads for non-P2P users >=20 > 6. closing message > ------------------ > * localisation is only desirable conditionally > - over some inter-domain paths, at some times, with some transports > * updating an inter-domain oracle for dynamic path-specific info is not= > proven feasible > - hard even for a single residential ISP > =96e.g. 20M access lines =3D> 20M2 paths (400,000,000,000,000 path= s) > =96and that doesn't include home network segments > =96even edge-edge, 7,000 access multiplexers =3D> 50M paths > - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,000,000 > edge-edge paths > * nonetheless, topology-based heuristics modified by static policy (e.g= =2E > P4P) are perhaps 'better' than random guesses > * but "localisation is good" MUST NOT be the goal > - that will lead to the DISINTERNET > * localisation would be easy,... but if it's NOT the goal > - is an oracle appropriate for standards activity or only for more > research? >=20 > Cheers >=20 >=20 > Bob --------------ms050205060007050605090605 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MzAxNDA5MzdaMCMG CSqGSIb3DQEJBDEWBBQxBFZulnnng+JP5enLDZRbB78rQzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKqyMjuzomi9 T7OZTznld44gzcAwVtKflFdbNcsmAL6X8k2PQ+Zjq60YzB+AQOWiOQQlkdI2oRfgyok1jM19 Q2hfFRLbgxCH+qL10h5RBtkzK+RqP3Yhps+JvSP6lTAN/twnpQyEt+1Jd7j+sJ4Y8v2XHLUY N5xeEMEoEQEb5osgNp4c7yFqLJjjc10DeCq1Ymr2AOnh9S1dIttbcAq7KOOa8t8r7NXZ2zCU y3wkICJwlY6xKL5WBKpHnAjFJUORDQfltXREUsRSpaDaPR8O6mKkHs0cKM8123uBOY3vH771 UIBmZkGhIJef4sIMPY1FDTme5Wq0rQe4izzcz+eAKScAAAAAAAA= --------------ms050205060007050605090605-- --===============1763161238== 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 --===============1763161238==-- From p2pi-bounces@ietf.org Wed Jul 30 08:43: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 279A13A6ADF; Wed, 30 Jul 2008 08:43: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 89FBB3A6ADF for ; Wed, 30 Jul 2008 08:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 5dEkY+lBv3Uq for ; Wed, 30 Jul 2008 08:43:21 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 543943A6AC3 for ; Wed, 30 Jul 2008 08:43:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so60177rvf.49 for ; Wed, 30 Jul 2008 08:43:34 -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=1/bHt1PeRIVitnoyHJZkNDEHzJ1lZsMxwWwJRAOV8AI=; b=MUTSiH7umP2BT1YSHWjSZbTQAOSYGr4+ljzl6f1Br9LlBpFyuKcqztxJtvgKa+AtCb tw+gfdHjETt8S1SoxkLKWkeh17KwxHOiC8T664Bni13ZsTZMgc8DRi5JB/QoJahsg++1 0uffCjLPuuSzbhFxXcFsSwsR0uio4M5alAflw= 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=Rg6L7xJkgxMKBZKCmHIQc5+uNeOBAcl6DqZNIWXmWCSnttChkC1GjtShNhALhZTc0g jFCc6GRdcAvDlpkrkQosLfyDgiTGiRiCMyKlCU2Wp2uPRejHznpTPYpZ7sS72BRIxEg3 1iny3H2KaMaXhmKNYHJ4qdq6WhOMFfU7Kx1hc= Received: by 10.140.178.17 with SMTP id a17mr4437492rvf.156.1217432614089; Wed, 30 Jul 2008 08:43:34 -0700 (PDT) Received: by 10.151.85.12 with HTTP; Wed, 30 Jul 2008 08:43:33 -0700 (PDT) Message-ID: <241bc2150807300843t40f1d0a2q10196d8454acbea9@mail.gmail.com> Date: Wed, 30 Jul 2008 08:43:34 -0700 From: "=?ISO-8859-2?Q?Ula=BA_C._Kozat?=" To: "Henning Schulzrinne" In-Reply-To: MIME-Version: 1.0 References: <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <36074C3F-6BA6-4A5F-AA6C-59C8FEA82122@cs.stanford.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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="===============0718155527==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0718155527== Content-Type: multipart/alternative; boundary="----=_Part_50694_5795583.1217432614053" ------=_Part_50694_5795583.1217432614053 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My understanding of the problem after reading the sequence of e-mails is a little bit confused. But I try to summarize my understanding of the ongoing discussion (mostly I express them as questions): Goal: To develop an "Oracle" architecture to guide peer selection process to achieve some Macro performance and/or economical gains. Question 1: Could such an Oracle system be useful to achieve these Macro gains? It is useful iff P2P App cannot do it on its own in a reasonable time and overhead while Oracle system can. Question 2: Often P2P objectives (in terms of the optimization problem and constraints) differ from one P2P system to another. Can different P2P Apps communicate what they need to attain these objectives to the Oracle in some Macro level and can Oracle make such an assessment with the high level topology, traffic load, etc. information? Remark 1: If the answer to Question 1 is "no Oracle cannot be useful", I think the argument that P2P anyways can fallback to its own selection process is not convincing. The answer to Question 1 should be "Yes, the Oracle system is mostly useful for an important set of P2P apps under at least one interesting type of IP network (e.g., 4G cellular)". Remark 2: Some argue that there are enough research and experimental results that hint that the answer to Question 1 is yes. Some argue they are fictitious or insufficient or they do not use smart enough P2P Apps. I think the research and experimental results should be classified in terms of network assumptions, P2P objectives, and Query-Response types first. For some assumptions, for some objectives, and for some query-response types, in my opinion, there is enough evidence that Oracle works. But I am not sure whether "smarter" P2P Apps themselves can do it in a reasonable time and overhead under the considered set-up. Remark3: Again my personal opinion is that if what P2P app wishes to achieve is not well communicated with the Oracle system or what the Oracle system returns back to the P2P App is not well specified apriori, the odds are it won't be successful. Any chartering should seriously tackle down this issue. Ulas On Wed, Jul 30, 2008 at 6:59 AM, Henning Schulzrinne wrote: > >> Why do you think an end-client wants/needs this information? I'm skeptical >> on depending on clients to take actions that benefit someone else (e.g., >> ISP) but harm them. The reason why the ordered list is so promising is that >> it turns out often the two optimization problems lead to very similar >> solutions. >> >> > If it turns out that for a particular client (P2P or otherwise), it finds > that this information correlates well with good performance, the client has > an incentive to use it. This makes it easy to develop > client/application-specific algorithms that rely on common information, > rather than having each client spend a lot of kludgey effort (such as > querying looking glass sites) to get at the data. > > There seems to be significant published evidence that these metrics do > correlate, on average, with improved performance, even if they occasionally > miss the boat. It's the averages we care about, as long as the outliers > aren't ridiculously bad and can be detected at run time. > > > At the very least, I'd argue separating (1) and (2) in terms of >> specification. (1) is so simple that it would be easy to nail it down, while >> (2) would require a bit more work. >> > > Depends on the level of detail reported. The items I mentioned seem trivial > and extending the list later seems easy. > > > >> >> Phil >> > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_50694_5795583.1217432614053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
My understanding of the problem after reading the sequence of e-mails is a little bit confused. But I try to summarize my understanding of the ongoing discussion (mostly I express them as questions):

Goal: To develop an "Oracle" architecture to guide peer selection process to achieve some Macro performance and/or economical gains.
Question 1: Could such an Oracle system be useful to achieve these Macro gains? It is useful iff P2P App cannot do it on its own in a reasonable time and overhead while Oracle system can.
Question 2: Often P2P objectives (in terms of the optimization problem and constraints) differ from one P2P system to another. Can different P2P Apps communicate what they need to attain these objectives to the Oracle in some Macro level and can Oracle make such an assessment  with the high level topology, traffic load, etc. information?


Remark 1: If the answer to Question 1 is "no Oracle cannot be useful", I think the argument that P2P anyways can fallback to its own selection process is not convincing. The answer to Question 1 should be "Yes, the Oracle system is mostly useful for an important set of P2P apps under at least one interesting type of IP network  (e.g., 4G cellular)".

Remark 2: Some argue that there are enough research and experimental results that hint that the answer to Question 1 is yes. Some argue they are fictitious or insufficient or they do not use smart enough P2P Apps. I think the research and experimental results should be classified in terms of network assumptions, P2P objectives, and Query-Response types first. For some assumptions, for some objectives, and for some query-response types, in my opinion, there is enough evidence that Oracle works. But I am not sure whether "smarter" P2P Apps themselves can do it in a reasonable time and overhead under the considered set-up.

Remark3: Again my personal opinion is that if what P2P app wishes to achieve is not well communicated with the Oracle system or what the Oracle system returns back to the P2P App is not well specified apriori, the odds are it won't be successful. Any chartering should seriously tackle down this issue.

Ulas

On Wed, Jul 30, 2008 at 6:59 AM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

Why do you think an end-client wants/needs this information? I'm skeptical on depending on clients to take actions that benefit someone else (e.g., ISP) but harm them. The reason why the ordered list is so promising is that it turns out often the two optimization problems lead to very similar solutions.


If it turns out that for a particular client (P2P or otherwise), it finds that this information correlates well with good performance, the client has an incentive to use it. This makes it easy to develop client/application-specific algorithms that rely on common information, rather than having each client spend a lot of kludgey effort (such as querying looking glass sites) to get at the data.

There seems to be significant published evidence that these metrics do correlate, on average, with improved performance, even if they occasionally miss the boat. It's the averages we care about, as long as the outliers aren't ridiculously bad and can be detected at run time.



At the very least, I'd argue separating (1) and (2) in terms of specification. (1) is so simple that it would be easy to nail it down, while (2) would require a bit more work.

Depends on the level of detail reported. The items I mentioned seem trivial and extending the list later seems easy.




Phil

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

------=_Part_50694_5795583.1217432614053-- --===============0718155527== 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 --===============0718155527==-- From p2pi-bounces@ietf.org Wed Jul 30 09:00: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 B819F3A6B48; Wed, 30 Jul 2008 09:00: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 1E6AE3A6820 for ; Wed, 30 Jul 2008 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 JONJSHdXXrIV for ; Wed, 30 Jul 2008 09:00:28 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4190028C0E1 for ; Wed, 30 Jul 2008 09:00:28 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UFuTwv003725; Wed, 30 Jul 2008 11:00:30 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:58:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:58:42 +0300 Received: from [130.129.23.187] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:58:41 +0300 Message-Id: <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> From: Lars Eggert To: "ext Henning Schulzrinne" In-Reply-To: <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 16:58:37 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 15:58:42.0202 (UTC) FILETIME=[238777A0:01C8F25D] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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, (1) is basically a relative query (order something provided by the querier based on who/where he is) while (2) is for absolute information. Both query types make sense to me. But what query types make sense is orthogonal to which information or measure is being queried, which is what my concern was about. On 2008-7-30, at 14:32, ext Henning Schulzrinne wrote: > (1) relative ordering of a set of an IP addresses; the ordering is > expected to be correct in some average sense, similar to one would > order Rome > Dublin > Reykjavik in terms of average temperature. > This doesn't mean that on any given day Dublin is colder than Rome, > just that this is likely. This my short version of the description > below. By what measure or measures will this ordering happen? For each of these kinds of measure or information, what's the "litmus test" argument? > (2) Returning topology-related information for one or more IP > addresses. This could be either equalities ("X1 is in the same AS as > X2") or absolute values ("X1 is in AS 16"). The type of information > we know how to produce, but have trouble obtaining in non-kludgey > fashions today, include AS number, provider name, continent (or > country), subnet. I agree that these kinds of information we know how to provide. But at least some of those are also easily obtainable by an application. BBC iPlayer and similar apps in other countries seem to have little problems determining where my IP address is from. Where is the benefit of getting this information through an ALTO box? > More sophisticated versions would include some notion of network > distance, in some network coordinate system. A low-hanging fruit is > to simply return the three or four coarse topology metrics and then > add more as experience increases. With my researcher hat on, I agree, but with my IETF hat on, I'd argue that the P2PRG seems like the correct home for such proposals at this time. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 09:53: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 6B06428C3B0; Wed, 30 Jul 2008 09:53: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 F282428C3B0 for ; Wed, 30 Jul 2008 09:53:10 -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=[AWL=0.000, 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 Tx+yGhZkJr8q for ; Wed, 30 Jul 2008 09:53:09 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A6D5028C3AA for ; Wed, 30 Jul 2008 09:53:09 -0700 (PDT) Received: from dhcp-130-129-19-238.meeting.ietf.org ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6UGrF2p004014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Jul 2008 12:53:16 -0400 (EDT) Message-Id: <2B503009-F718-4D4C-AF44-4F539BB493B3@cs.columbia.edu> From: Henning Schulzrinne To: Lars Eggert In-Reply-To: <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 12:53:14 -0400 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Jul 30, 2008, at 11:58 AM, Lars Eggert wrote: > > On 2008-7-30, at 14:32, ext Henning Schulzrinne wrote: >> (1) relative ordering of a set of an IP addresses; the ordering is >> expected to be correct in some average sense, similar to one would >> order Rome > Dublin > Reykjavik in terms of average temperature. >> This doesn't mean that on any given day Dublin is colder than Rome, >> just that this is likely. This my short version of the description >> below. > > By what measure or measures will this ordering happen? For each of > these kinds of measure or information, what's the "litmus test" > argument? > I can see several approaches: - "Opaque oracle": The oracle won't tell you how it arrived at the ordering - you just have to trust the result. After all, the weatherman on TV also doesn't tell you why he thinks it will rain tomorrow and Delphi never revealed its reasoning, either. Oracles that help end users, prosper. This works reasonably well if there is a single ordering that works well for a variety of applications. - "Semi-opaque oracle": The querier says "low latency" or "high throughput". The oracle consults its backend (such as the ones described during the BOF) and returns an appropriate (partial) ordering. - Transparent: Querier provides some objective function. I suspect that the 2nd version is reasonable, in that it shields the client from the details of the backend database. >> (2) Returning topology-related information for one or more IP >> addresses. This could be either equalities ("X1 is in the same AS >> as X2") or absolute values ("X1 is in AS 16"). The type of >> information we know how to produce, but have trouble obtaining in >> non-kludgey fashions today, include AS number, provider name, >> continent (or country), subnet. > > I agree that these kinds of information we know how to provide. But > at least some of those are also easily obtainable by an application. > BBC iPlayer and similar apps in other countries seem to have little > problems determining where my IP address is from. Where is the > benefit of getting this information through an ALTO box? None of these mechanisms are standardized, as far as I know. How do you currently determine the simple items I mentioned before? For example, there are a number of IP-to-geo mapping services (MaxMind, Quova, etc.), but each uses a different "protocol". Thus, an application has to be tied to a specific provider, which seems far from ideal. With the same argument, we could get rid of HTTP and DNS... > > >> More sophisticated versions would include some notion of network >> distance, in some network coordinate system. A low-hanging fruit is >> to simply return the three or four coarse topology metrics and then >> add more as experience increases. > > > With my researcher hat on, I agree, but with my IETF hat on, I'd > argue that the P2PRG seems like the correct home for such proposals > at this time. I don't see returning AS numbers and the other information as "research", even if the longer-term metrics may be. The alternative to ALTO is not "research", but lots of proprietary alternatives that don't feel encumbered by the same level of doubts. > > > Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 09:56: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 575B228C0F5; Wed, 30 Jul 2008 09:56: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 585043A695D for ; Wed, 30 Jul 2008 09:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 gsD8pazxi1C7 for ; Wed, 30 Jul 2008 09:56:10 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 722DB3A6952 for ; Wed, 30 Jul 2008 09:56:10 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UGuFE1023558; Wed, 30 Jul 2008 11:56:18 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 19:56:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 19:56:11 +0300 Received: from lars.meeting.ietf.org ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 19:56:11 +0300 Message-Id: From: Lars Eggert To: ext Lars Eggert In-Reply-To: <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 17:55:50 +0100 References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 16:56:11.0486 (UTC) FILETIME=[2B766FE0:01C8F265] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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-7-30, at 16:58, ext Lars Eggert wrote: >> More sophisticated versions would include some notion of network >> distance, in some network coordinate system. A low-hanging fruit is >> to simply return the three or four coarse topology metrics and then >> add more as experience increases. > > With my researcher hat on, I agree, but with my IETF hat on, I'd > argue that the P2PRG seems like the correct home for such proposals > at this time. And because I got asked: I was referring to the "sophisticated versions" in Henning's email, *not* the entire ALTO effort. As I said before, I do believe we have identified some pieces that seem ready to charter. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 10:21: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 A12023A6BF9; Wed, 30 Jul 2008 10:21: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 DFBB23A6876 for ; Wed, 30 Jul 2008 10:21:03 -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 yRXO8DmzMzN1 for ; Wed, 30 Jul 2008 10:21:02 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 9DCA23A6BF9 for ; Wed, 30 Jul 2008 10:21:02 -0700 (PDT) Received: from cyndra.cs.yale.edu (cyndra.cs.yale.edu [128.36.229.87]) by netra.cs.yale.edu (Postfix) with ESMTP id C5DC940948E; Wed, 30 Jul 2008 13:21:17 -0400 (EDT) Date: Wed, 30 Jul 2008 13:21:17 -0400 (EDT) From: "Y. R. Yang" To: Henning Schulzrinne In-Reply-To: <2B503009-F718-4D4C-AF44-4F539BB493B3@cs.columbia.edu> Message-ID: References: <488F173A.7040507@alcatel-lucent.com> <67093319-6DF3-4B1A-B6B2-D1695BC089D2@cisco.com> <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> <2B503009-F718-4D4C-AF44-4F539BB493B3@cs.columbia.edu> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Wed, 30 Jul 2008, 12:53pm -0400, Henning Schulzrinne wrote: > > On Jul 30, 2008, at 11:58 AM, Lars Eggert wrote: > > > > >On 2008-7-30, at 14:32, ext Henning Schulzrinne wrote: > > >(1) relative ordering of a set of an IP addresses; the ordering is expected > > >to be correct in some average sense, similar to one would order Rome > > > >Dublin > Reykjavik in terms of average temperature. This doesn't mean that > > >on any given day Dublin is colder than Rome, just that this is likely. This > > >my short version of the description below. > > > >By what measure or measures will this ordering happen? For each of these > >kinds of measure or information, what's the "litmus test" argument? > > > > I can see several approaches: > > - "Opaque oracle": The oracle won't tell you how it arrived at the ordering - > you just have to trust the result. After all, the weatherman on TV also > doesn't tell you why he thinks it will rain tomorrow and Delphi never revealed > its reasoning, either. Oracles that help end users, prosper. This works > reasonably well if there is a single ordering that works well for a variety of > applications. > > - "Semi-opaque oracle": The querier says "low latency" or "high throughput". > The oracle consults its backend (such as the ones described during the BOF) > and returns an appropriate (partial) ordering. > > - Transparent: Querier provides some objective function. > > I suspect that the 2nd version is reasonable, in that it shields the client > from the details of the backend database. By Henning's classification, the current P4P field test provides an example metric of the first category: the "opaque" p4p distance (or pdistance or vcost). In the most "sophisticated" version, the pdistances are determined by the shadow variables of a primal-dual decomposition to conduct optimal ISP traffic engineering. These terms sound scary, but if you ask economists on primal-dual decomposition and shadow prices to explain market economies, they typically can give you a simple explanatinon. Of course, this pdistance may also reflect in a sense the relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I guess this why it should be considered opaque. I do not see this "opaqueness" as bad. Henning gave good examples. When I buy something in a market, I do not ask exactly how the prices are derived. > > >(2) Returning topology-related information for one or more IP addresses. > > >This could be either equalities ("X1 is in the same AS as X2") or absolute > > >values ("X1 is in AS 16"). The type of information we know how to produce, > > >but have trouble obtaining in non-kludgey fashions today, include AS > > >number, provider name, continent (or country), subnet. > > > >I agree that these kinds of information we know how to provide. But at > >least some of those are also easily obtainable by an application. BBC > >iPlayer and similar apps in other countries seem to have little > >problems determining where my IP address is from. Where is the benefit > >of getting this information through an ALTO box? > > None of these mechanisms are standardized, as far as I know. How do you > currently determine the simple items I mentioned before? > > For example, there are a number of IP-to-geo mapping services (MaxMind, Quova, > etc.), but each uses a different "protocol". Thus, an application has to be > tied to a specific provider, which seems far from ideal. With the same > argument, we could get rid of HTTP and DNS... > > > > > > > > >More sophisticated versions would include some notion of network distance, > > >in some network coordinate system. A low-hanging fruit is to simply return > > >the three or four coarse topology metrics and then add more as experience > > >increases. > > > > > >With my researcher hat on, I agree, but with my IETF hat on, I'd argue that > >the P2PRG seems like the correct home for such proposals at this time. > > I don't see returning AS numbers and the other information as "research", even > if the longer-term metrics may be. > > The alternative to ALTO is not "research", but lots of proprietary > alternatives that don't feel encumbered by the same level of doubts. > > > > > > > >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 Wed Jul 30 10:38: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 9C9713A6C3B; Wed, 30 Jul 2008 10:38: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 129FD3A6C30 for ; Wed, 30 Jul 2008 10:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 OSSuqCZOjtM9 for ; Wed, 30 Jul 2008 10:38:17 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id E22293A6BF9 for ; Wed, 30 Jul 2008 10:38:16 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so65025ywj.49 for ; Wed, 30 Jul 2008 10:38:30 -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=tzT4uwgoM0pJEaULhiwHRqKduxo9x+eeO/6lmMMMSQA=; b=MBqq5I/bM/GK7rgmVyEphoZcqQerZoPRArsm3GAoOpsqWQgC1lRv8j0VlpSGCaMq46 0Egrfz1hzQjjeeSYJFywPsnFxU04SbTtQnRRA6vAQCg3dDgXqMfawMVb0vTg3Sv5VMkq oDmELHyk6T+jeMxmCjA/8LykudgKysVFuxwMI= 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=ni9kXMX2VDYZdZjkU1HaqsOr9TnKBy0J2fno8a2w8//lU01eUw/AbyGx6nnUqyk8ec 1T7uwtDsOH5QPxMV0auwSBG9ol0JHJaIuOzhvJ/EfwIVH0JPuRkzOVoWg93tOCE4Pq7J lIG8gI+Pc9YulOd2JmIJ/wiSZyLyzuecUt6Nc= Received: by 10.141.18.15 with SMTP id v15mr4586055rvi.296.1217439510077; Wed, 30 Jul 2008 10:38:30 -0700 (PDT) Received: by 10.151.85.12 with HTTP; Wed, 30 Jul 2008 10:38:29 -0700 (PDT) Message-ID: <241bc2150807301038r33f03fbby3e2d96a76b07927b@mail.gmail.com> Date: Wed, 30 Jul 2008 10:38:29 -0700 From: "=?ISO-8859-2?Q?Ula=BA_C._Kozat?=" To: "Y. R. Yang" In-Reply-To: MIME-Version: 1.0 References: <488F2350.5040903@piuha.net> <1727880B-0315-490B-83A4-A6D65AA21980@nokia.com> <48903DF1.8030604@alcatel-lucent.com> <5608987A-D217-43D7-81F2-364132280111@nokia.com> <5C40571A-B9D7-47B5-A0F7-E89998AB3BF6@cs.stanford.edu> <570CF89D-EACE-45AF-BFF0-89AA0F6B6560@cs.columbia.edu> <730F37A9-7A7C-43C0-BE1E-1270452DEC75@nokia.com> <2B503009-F718-4D4C-AF44-4F539BB493B3@cs.columbia.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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="===============2007117619==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2007117619== Content-Type: multipart/alternative; boundary="----=_Part_51976_22601825.1217439510002" ------=_Part_51976_22601825.1217439510002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My comment is at the bottom. Ulas > > > > - "Opaque oracle": The oracle won't tell you how it arrived at the > ordering - > > you just have to trust the result. After all, the weatherman on TV also > > doesn't tell you why he thinks it will rain tomorrow and Delphi never > revealed > > its reasoning, either. Oracles that help end users, prosper. This works > > reasonably well if there is a single ordering that works well for a > variety of > > applications. > > > > - "Semi-opaque oracle": The querier says "low latency" or "high > throughput". > > The oracle consults its backend (such as the ones described during the > BOF) > > and returns an appropriate (partial) ordering. > > > > - Transparent: Querier provides some objective function. > > > > I suspect that the 2nd version is reasonable, in that it shields the > client > > from the details of the backend database. > > By Henning's classification, the current P4P field test provides an > example metric of the first category: the "opaque" p4p distance (or > pdistance or vcost). In the most "sophisticated" version, the pdistances > are determined by the shadow variables of a primal-dual decomposition to > conduct optimal ISP traffic engineering. These terms sound scary, but if > you ask economists on primal-dual decomposition and shadow prices to > explain market economies, they typically can give you a simple > explanatinon. Of course, this pdistance may also reflect in a sense the > relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I > guess this why it should be considered opaque. I do not see this > "opaqueness" as bad. Henning gave good examples. When I buy something in a > market, I do not ask exactly how the prices are derived. > > It is not maybe essential to know how the price is computed, but it is critical to know if that pricing is done with respect to P2P App's expectation. If I reuse the analogy above, it is a waste of time to go to an expensive store if there is not any chance of buying anything. I better know a-priori if my constraints are in line with the pricing. ------=_Part_51976_22601825.1217439510002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

My comment is at the bottom.

Ulas


>
> - "Opaque oracle": The oracle won't tell you how it arrived at the ordering -
> you just have to trust the result. After all, the weatherman on TV also
> doesn't tell you why he thinks it will rain tomorrow and Delphi never revealed
> its reasoning, either. Oracles that help end users, prosper. This works
> reasonably well if there is a single ordering that works well for a variety of
> applications.
>
> - "Semi-opaque oracle": The querier says "low latency" or "high throughput".
> The oracle consults its backend (such as the ones described during the BOF)
> and returns an appropriate (partial) ordering.
>
> - Transparent: Querier provides some objective function.
>
> I suspect that the 2nd version is reasonable, in that it shields the client
> from the details of the backend database.

By Henning's classification, the current P4P field test provides an
example metric of the first category: the "opaque" p4p distance (or
pdistance or vcost). In the most "sophisticated" version, the pdistances
are determined by the shadow variables of a primal-dual decomposition to
conduct optimal ISP traffic engineering. These terms sound scary, but if
you ask economists on primal-dual decomposition and shadow prices to
explain market economies, they typically can give you a simple
explanatinon. Of course, this pdistance may also reflect in a sense the
relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I
guess this why it should be considered opaque. I do not see this
"opaqueness" as bad. Henning gave good examples. When I buy something in a
market, I do not ask exactly how the prices are derived.


It is not maybe essential to know how the price is computed, but it is critical to know
if that pricing is done with respect to P2P App's expectation. If I reuse the analogy above,
it is a waste of time to go to an expensive store if there is not any chance of buying anything.
I better know a-priori if my constraints are in line with the pricing.

------=_Part_51976_22601825.1217439510002-- --===============2007117619== 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 --===============2007117619==-- From p2pi-bounces@ietf.org Wed Jul 30 12:20: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 7FF5C3A6B18; Wed, 30 Jul 2008 12:20: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 20F103A6903 for ; Wed, 30 Jul 2008 12:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.047 X-Spam-Level: * X-Spam-Status: No, score=1.047 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_57=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 WZmGqlZm+wfU for ; Wed, 30 Jul 2008 12:20:28 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CC6753A6ABD for ; Wed, 30 Jul 2008 12:19:58 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 20:20:09 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 20:20:08 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217445610795; Wed, 30 Jul 2008 20:20:10 +0100 Received: from mut.jungle.bt.co.uk ([10.73.16.50]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6UJJBdB024250; Wed, 30 Jul 2008 20:20:05 +0100 Message-Id: <200807301920.m6UJJBdB024250@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jul 2008 20:18:52 +0100 To: Reinaldo Penno From: Bob Briscoe In-Reply-To: References: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jul 2008 19:20:08.0651 (UTC) FILETIME=[479D39B0:01C8F279] Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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="===============1582400388==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1582400388== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reinaldo,

Yup, thanks. I had read your mail.

I was just trying to be more specific. I was hiliting the many cases where the cost of upstream congestion to an ISPs own customers is greater than the cost of interconnect /plus/ the cost of upstream congestion to another ISP's customers, even where both uploaders are residential.

I also wanted to illustrate what backhaul meant for all those that had never heard of it - given it's so important to this discussion.


Bob

At 14:53 30/07/2008, Reinaldo Penno wrote:
Hello Bob,

Actually I sent an email about this issue some time back and some people agreed with it. It talked about the fact that some ISPs/Telcos would prefer P2P to use inter-domain links.

Check http://www.ietf.org/mail-archive/web/p2pi/current/msg00212.html

Thanks,

Reinaldo


On 7/30/08 6:42 AM, "Bob Briscoe" <rbriscoe@jungle.bt.co.uk> wrote:

Folks,

Following my last mail on procedural reasons, here's my technical reasons.

Technical
---------
I've drawn a picture (very simplified), as I think some people wanted to have a better model of what commercial residential networks look like.
< http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-briscoe.p= df <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pres= ents/0807ietf/0807alto-briscoe.pdf> >
Text in the above slideset is repeated below, numbered by slide...

2. Localisation is NOT consistently desirable
------------------------------------------
whether by AS count, hop count, RTT, ...

* for ISPs (slide #3)
=88using an interconnect path may impact other users less and not cost the ISP more
  a)upstream backhaul link
  o in some access technologies (e.g DSL) the upstream backhaul is never congested =88 it's typically a symmetric link fed by an asymmetric access
  o retail ISPs often lease this link without any upstream usage penalties

  b)interconnect
  o if interconnect charging is based on 95th percentile and it's currently not near the 95th percentile
  o or if interconnect is based on a peering contract which only requires the balance of volume transferred between networks to be checked at peak times, and it's currently not a peak time

* For users & apps (slide #4)
  o with newer cc algos, longer RTT hardly requires slower rate
  o desire for shorter RTT to get higher rate will go away

3. ISPs could prefer inter-domain path
--------------------------------------
<picture> - see slide

4. Lower RTT isn't nearly as good as we thought
-----------------------------------------------
for long-lived flows

* app desire for localisation is artefact of TCP algo
  - TCP average rate depends on 1/RTT (for similarly congested paths)
* modern congestion control algos don't do this
  - FAST TCP [Jin04], BitTorrent DNA (rate-based mode)
* for stability, doesn't rate need to depend on 1/RTT?
  - No. Research agrees only acceleration needs to
  - Equilibrium rate can be independent of RTT
  (see slide #4 for a typical example)

5. What metric judges 'better'?
-------------------------------
* NOT lower inter-domain traffic (necessarily)
  - if at the cost of more local upstream congestion
* NOT faster downloads (necessarily)
  - if at the expense of slower downloads for non-P2P users

6. closing message
------------------
* localisation is only desirable conditionally
  - over some inter-domain paths, at some times, with some transports
* updating an inter-domain oracle for dynamic path-specific info is not proven feasible
  - hard even for a single residential ISP
    =88e.g. 20M access lines =3D>  20M2 paths (400,000,000,000,000 paths)
    =88and that doesn't include home network segments
    =88even edge-edge, 7,000 access multiplexers =3D> 50M paths
  - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,000,000 edge-edge paths
* nonetheless, topology-based heuristics modified by static policy (e.g. P4P) are perhaps 'better' than random guesses
* but "localisation is good" MUST NOT be the goal
  - that will lead to the DISINTERNET
* localisation would be easy,... but if it's NOT the goal
  - is an oracle appropriate for standards activity or only for more research?

Cheers


Bob


____________________________________________________________________________=
Bob Briscoe, <bob.briscoe@bt.com >     Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

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

____________________________________________________________________________=
Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 --===============1582400388== 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 --===============1582400388==-- From p2pi-bounces@ietf.org Wed Jul 30 12:28: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 340423A695B; Wed, 30 Jul 2008 12:28: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 744A13A6862 for ; Wed, 30 Jul 2008 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_18=0.6, J_CHICKENPOX_57=0.6, MIME_QP_LONG_LINE=1.396, 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 2N7k7LpQ7Gq7 for ; Wed, 30 Jul 2008 12:27:58 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1F7083A695B for ; Wed, 30 Jul 2008 12:27:57 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 20:28:11 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 20:28:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217446090558; Wed, 30 Jul 2008 20:28:10 +0100 Received: from mut.jungle.bt.co.uk ([10.73.16.50]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6UJRp9j025016; Wed, 30 Jul 2008 20:28:06 +0100 Message-Id: <200807301928.m6UJRp9j025016@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jul 2008 20:27:49 +0100 To: Enrico Marocco From: Bob Briscoe In-Reply-To: <48907621.6090807@telecomitalia.it> References: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk> <48907621.6090807@telecomitalia.it> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jul 2008 19:28:10.0688 (UTC) FILETIME=[66EE3C00:01C8F27A] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] why i hummed no 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 Enrico, I am well aware there were sensible people in the = room who know the problem isn't localisation (see = my preceding mail on procedural rather than issues with the ALTO BoF). However, those who stated it as a solely = localisation problem had the floor exclusively on = Tuesday. That was a signal to me that any future = ALTO w-g will have to continue to deal with this = high percentage of low cluefulness among those working on this issue. I'm not worried that you don't understand it. I'm = worried we can't get others to understand this point. Bob At 15:09 30/07/2008, Enrico Marocco wrote: >Bob, ALTO is not about "localization" only (which, btw, is quite an >ambiguous term, best avoided). Probably we have not made it clear >enough, but AFAIR network policies are always mentioned amongst possible >criteria to rank peers. > >Anyway, thank you for your contribution, it will help people in >understanding the problem are and hopefully will foster some discussion. > >Enrico > >Bob Briscoe wrote: > > Folks, > > > > Following my last mail on procedural reasons, here's my technical reaso= ns. > > > > Technical > > --------- > > I've drawn a picture (very simplified), as I think some people wanted to > > have a better model of what commercial residential networks look like. > > < > > = > http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-brisco= e.pdf > >> > > Text in the above slideset is repeated below, numbered by slide... > > > > 2. Localisation is NOT consistently desirable > > ------------------------------------------ > > whether by AS count, hop count, RTT, ... > > > > * for ISPs (slide #3) > > =ADusing an interconnect path may impact other users less and not cost = the > > ISP more > > a)upstream backhaul link > > o in some access technologies (e.g DSL) the upstream backhaul is never > > congested =AD it's typically a symmetric link fed by an asymmetric acce= ss > > o retail ISPs often lease this link without any upstream usage penalt= ies > > > > b)interconnect > > o if interconnect charging is based on 95th percentile and it's > > currently not near the 95th percentile > > o or if interconnect is based on a peering contract which only > > requires the balance of volume transferred between networks to be > > checked at peak times, and it's currently not a peak time > > > > * For users & apps (slide #4) > > o with newer cc algos, longer RTT hardly requires slower rate > > o desire for shorter RTT to get higher rate will go away > > > > 3. ISPs could prefer inter-domain path > > -------------------------------------- > > - see slide > > > > 4. Lower RTT isn't nearly as good as we thought > > ----------------------------------------------- > > for long-lived flows > > > > * app desire for localisation is artefact of TCP algo > > - TCP average rate depends on 1/RTT (for similarly congested paths) > > * modern congestion control algos don't do this > > - FAST TCP [Jin04], BitTorrent DNA (rate-based mode) > > * for stability, doesn't rate need to depend on 1/RTT? > > - No. Research agrees only /acceleration /needs to > > - Equilibrium rate can be independent of RTT > > (see slide #4 for a typical example) > > > > 5. What metric judges 'better'? > > ------------------------------- > > * NOT lower inter-domain traffic (necessarily) > > - if at the cost of more local upstream congestion > > * NOT faster downloads (necessarily) > > - if at the expense of slower downloads for non-P2P users > > > > 6. closing message > > ------------------ > > * localisation is only desirable conditionally > > - over some inter-domain paths, at some times, with some transports > > * updating an inter-domain oracle for dynamic path-specific info is not > > proven feasible > > - hard even for a single residential ISP > > =ADe.g. 20M access lines =3D> 20M2 paths (400,000,000,000,000 path= s) > > =ADand that doesn't include home network segments > > =ADeven edge-edge, 7,000 access multiplexers =3D> 50M paths > > - for inter-domain oracles, 100M muxes =3D> 100,000,000,000,000,000 > > edge-edge paths > > * nonetheless, topology-based heuristics modified by static policy (e.g. > > P4P) are perhaps 'better' than random guesses > > * but "localisation is good" MUST NOT be the goal > > - that will lead to the DISINTERNET > > * localisation would be easy,... but if it's NOT the goal > > - is an oracle appropriate for standards activity or only for more > > research? > > > > Cheers > > > > > > Bob > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 64519= 6 = _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jul 30 13:23: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 598A73A697C; Wed, 30 Jul 2008 13:23: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 0929C3A6981 for ; Wed, 30 Jul 2008 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nhDBeddiM8AG for ; Wed, 30 Jul 2008 13:21:35 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id C68593A697C for ; Wed, 30 Jul 2008 13:21:34 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so308631ugd.46 for ; Wed, 30 Jul 2008 13:21:47 -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:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=vTp2fyFLYp0MVRKIEVx1zrW+UINTCUk26R4B7xfcyGk=; b=LbVaBKyf0iRNUqjWmONydeXnNocm3Y/9ez0V6OK9BT2L/11aLaN8AVNd+eNAl8j239 Cr3K0Z4/XHR5A1syspU2dZ+JQMC/gglFj0pFjz9ve6FySJ8BakGaDbKsnP9RSwoxY0bs NphGkh+CaSDhiZleSLPEev9VP9aO5uqCZddSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=tWdulOXUbx4Gz0KuOmNaLBqtcjl0c2jYLaR841+WfqNM4L0OhDxvH60JOFhWLRjiGe 0OJO38o1/92UCkl8to8U1aXwMcVksm0llJCzKpjuX0tx6gAiJVgHKdpi7IhhDLcWDmMI +zZU4g/wgPxxFmAxejBr6Fqe+uIBdEaBYdQY0= Received: by 10.103.172.9 with SMTP id z9mr3742085muo.122.1217449306853; Wed, 30 Jul 2008 13:21:46 -0700 (PDT) Received: by 10.103.198.5 with HTTP; Wed, 30 Jul 2008 13:21:46 -0700 (PDT) Message-ID: <2378673b0807301321s16739fbj51ee5f227b0966d9@mail.gmail.com> Date: Wed, 30 Jul 2008 13:21:46 -0700 From: "Satish Raghunath" To: p2pi@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 598a7195bb492c51 Subject: Re: [p2pi] why I didn't hum yes (yet) 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 >> By Henning's classification, the current P4P field test provides an >> example metric of the first category: the "opaque" p4p distance (or >> pdistance or vcost). In the most "sophisticated" version, the pdistances >> are determined by the shadow variables of a primal-dual decomposition to >> conduct optimal ISP traffic engineering. These terms sound scary, but if >> you ask economists on primal-dual decomposition and shadow prices to >> explain market economies, they typically can give you a simple >> explanatinon. Of course, this pdistance may also reflect in a sense the >> relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I >> guess this why it should be considered opaque. I do not see this >> "opaqueness" as bad. Henning gave good examples. When I buy something in a >> market, I do not ask exactly how the prices are derived. >> >> > It is not maybe essential to know how the price is computed, but it is > critical to know > if that pricing is done with respect to P2P App's expectation. If I reuse > the analogy above, > it is a waste of time to go to an expensive store if there is not any chance > of buying anything. > I better know a-priori if my constraints are in line with the pricing. A few observations regarding P2P expectations are useful here. a) Henning and Richard's suggestion of an abstract goal for the relative order (e.g. low latency) conveys these expectations. From the application standpoint, it is now relieved of topology or network details in order to answer "what does it mean in networking terms if I want low latency?". b) The question of trusting the "price"/"ordering" provided by the Oracle is somewhat easier to answer. Any computation that does not reasonably achieve both the provider and application's goals will naturally lose its popularity. The applications are free to ignore the Oracle's advice when they find out that results are not up to expectations. That means if there is a big enough constituency that finds the Oracle useful, it has reason to exist. In any case a standard query-response medium allows the community to discover and evolve better ordering/pricing/info-dissemination methods. Thanks, Satish _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 03:25: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 34F1B3A6C05; Thu, 31 Jul 2008 03:25: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 BE7753A6C05 for ; Thu, 31 Jul 2008 03:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_18=0.6, J_CHICKENPOX_57=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 wxSlfIE03Z1W for ; Thu, 31 Jul 2008 03:25:39 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 3B5923A6AEB for ; Thu, 31 Jul 2008 03:25:39 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m6VAPeWa013453; Thu, 31 Jul 2008 12:25:40 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jul 2008 12:25:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 12:25:37 +0200 Message-ID: <00275A5B436CA441900CB10936742A38DFAA79@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <200807301928.m6UJRp9j025016@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why i hummed no Thread-Index: AcjyepoXg86vZoWsR+6sG+me7UDFtAAaCPag References: <200807301342.m6UDgdGQ027985@bagheera.jungle.bt.co.uk><48907621.6090807@telecomitalia.it> <200807301928.m6UJRp9j025016@bagheera.jungle.bt.co.uk> From: "PAPADIMITRIOU Dimitri" To: "Bob Briscoe" , "Enrico Marocco" X-OriginalArrivalTime: 31 Jul 2008 10:25:39.0951 (UTC) FILETIME=[C797AFF0:01C8F2F7] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: p2pi@ietf.org Subject: Re: [p2pi] why i hummed no 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 share the concern that the statement part of the charter discussion "Discovery mechanism for locating the oracle - Query/Response protocol for communicating with the oracle" combined with the objective listed in the PS doc. "...to choose the best endpoint among those which host a desired resource." induces - unconditional localisation - as it does not consider the issue of combining perf. obj. x cost. obj. from both ISP and host/APP side. It is exactly the reasoning I have tried to outline also by underlining the challenge of best path selection (what Bob referred to as the "policy-controlled path-selection advice"). In a sense, using the so-called oracle for best-end point selection only is not going to deliver the expected/satisfactory outcome for all parties at stakes in this effort. -d. > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Bob Briscoe > Sent: Wednesday, July 30, 2008 9:28 PM > To: Enrico Marocco > Cc: p2pi@ietf.org > Subject: Re: [p2pi] why i hummed no > > Enrico, > > I am well aware there were sensible people in the > room who know the problem isn't localisation (see > my preceding mail on procedural rather than issues with the ALTO BoF). > > However, those who stated it as a solely > localisation problem had the floor exclusively on > Tuesday. That was a signal to me that any future > ALTO w-g will have to continue to deal with this > high percentage of low cluefulness among those working on this issue. > > I'm not worried that you don't understand it. I'm > worried we can't get others to understand this point. > > > Bob > > > At 15:09 30/07/2008, Enrico Marocco wrote: > >Bob, ALTO is not about "localization" only (which, btw, is quite an > >ambiguous term, best avoided). Probably we have not made it clear > >enough, but AFAIR network policies are always mentioned > amongst possible > >criteria to rank peers. > > > >Anyway, thank you for your contribution, it will help people in > >understanding the problem are and hopefully will foster some > discussion. > > > >Enrico > > > >Bob Briscoe wrote: > > > Folks, > > > > > > Following my last mail on procedural reasons, here's my > technical reasons. > > > > > > Technical > > > --------- > > > I've drawn a picture (very simplified), as I think some > people wanted to > > > have a better model of what commercial residential > networks look like. > > > < > > > > > > http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807 > alto-briscoe.pdf > > >> > > > Text in the above slideset is repeated below, numbered by slide... > > > > > > 2. Localisation is NOT consistently desirable > > > ------------------------------------------ > > > whether by AS count, hop count, RTT, ... > > > > > > * for ISPs (slide #3) > > > -using an interconnect path may impact other users less > and not cost the > > > ISP more > > > a)upstream backhaul link > > > o in some access technologies (e.g DSL) the upstream > backhaul is never > > > congested - it's typically a symmetric link fed by an > asymmetric access > > > o retail ISPs often lease this link without any > upstream usage penalties > > > > > > b)interconnect > > > o if interconnect charging is based on 95th percentile and it's > > > currently not near the 95th percentile > > > o or if interconnect is based on a peering contract which only > > > requires the balance of volume transferred between networks to be > > > checked at peak times, and it's currently not a peak time > > > > > > * For users & apps (slide #4) > > > o with newer cc algos, longer RTT hardly requires slower rate > > > o desire for shorter RTT to get higher rate will go away > > > > > > 3. ISPs could prefer inter-domain path > > > -------------------------------------- > > > - see slide > > > > > > 4. Lower RTT isn't nearly as good as we thought > > > ----------------------------------------------- > > > for long-lived flows > > > > > > * app desire for localisation is artefact of TCP algo > > > - TCP average rate depends on 1/RTT (for similarly > congested paths) > > > * modern congestion control algos don't do this > > > - FAST TCP [Jin04], BitTorrent DNA (rate-based mode) > > > * for stability, doesn't rate need to depend on 1/RTT? > > > - No. Research agrees only /acceleration /needs to > > > - Equilibrium rate can be independent of RTT > > > (see slide #4 for a typical example) > > > > > > 5. What metric judges 'better'? > > > ------------------------------- > > > * NOT lower inter-domain traffic (necessarily) > > > - if at the cost of more local upstream congestion > > > * NOT faster downloads (necessarily) > > > - if at the expense of slower downloads for non-P2P users > > > > > > 6. closing message > > > ------------------ > > > * localisation is only desirable conditionally > > > - over some inter-domain paths, at some times, with > some transports > > > * updating an inter-domain oracle for dynamic > path-specific info is not > > > proven feasible > > > - hard even for a single residential ISP > > > -e.g. 20M access lines => 20M2 paths > (400,000,000,000,000 paths) > > > -and that doesn't include home network segments > > > -even edge-edge, 7,000 access multiplexers => 50M paths > > > - for inter-domain oracles, 100M muxes => > 100,000,000,000,000,000 > > > edge-edge paths > > > * nonetheless, topology-based heuristics modified by > static policy (e.g. > > > P4P) are perhaps 'better' than random guesses > > > * but "localisation is good" MUST NOT be the goal > > > - that will lead to the DISINTERNET > > > * localisation would be easy,... but if it's NOT the goal > > > - is an oracle appropriate for standards activity or > only for more > > > research? > > > > > > Cheers > > > > > > > > > Bob > > > > > > > > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ > 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 Jul 31 05: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 8C6F43A6B11; Thu, 31 Jul 2008 05: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 754943A6A7E for ; Thu, 31 Jul 2008 05:29:07 -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 ujUxa1XPhcCR for ; Thu, 31 Jul 2008 05:29:06 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 5C4153A6B11 for ; Thu, 31 Jul 2008 05:29:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id E0FEEE10BD0; Thu, 31 Jul 2008 08:28:13 -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 rv78N7IEFWWV; Thu, 31 Jul 2008 08:28:02 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 95779E10B83; Thu, 31 Jul 2008 08:28:02 -0400 (EDT) Date: Thu, 31 Jul 2008 08:28:02 -0400 (EDT) From: Laird Popkin To: Satish Raghunath Message-ID: <1540190627.90361217507282550.JavaMail.root@dkny.pando.com> In-Reply-To: <535336058.90281217506802245.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [130.129.19.8] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 expand on Satish' comments: - The ALTO server's guidance must be viewed as advisory by the p2p applications, will will in practice use it as an additional information source used in addition to whatever other strategies the p2p application uses. So if the guidance is bad, the p2p network won't use it. That is, even if the p2p network doesn't decide not to trust a particular ALTO source, the existing mechanisms for p2p transit optimization will apply, minimizing the "pain" caused by bad guidance. - Random peer selection is so inefficient, that any degree of guidance is likely to be quite helpful, which is of (IMO) greater benefit than the relatively subtle differences between guidance strategies. That is, if I connect to a 'low latency' peer or a 'bulk data' peer, while one or the other would be better for a particular use, either will be better than a random peer somewhere on the planet. So while I think that there's a lot of good optimization that can be done by making the most appropriate recommendation, I believe that having any recommendation at all is so much of a benefit that I'm happy solving the simplest case first (i.e. let the ALTO server define "best" any way that it likes) and then we can tackle the complex case (i.e. negotiating priorities and rankings between the ALTO client and server). As long as the protocol is extensible (which is a requirement), this can be addressed over time. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Satish Raghunath" To: p2pi@ietf.org Sent: Wednesday, July 30, 2008 4:21:46 PM (GMT-0500) America/New_York Subject: Re: [p2pi] why I didn't hum yes (yet) >> By Henning's classification, the current P4P field test provides an >> example metric of the first category: the "opaque" p4p distance (or >> pdistance or vcost). In the most "sophisticated" version, the pdistances >> are determined by the shadow variables of a primal-dual decomposition to >> conduct optimal ISP traffic engineering. These terms sound scary, but if >> you ask economists on primal-dual decomposition and shadow prices to >> explain market economies, they typically can give you a simple >> explanatinon. Of course, this pdistance may also reflect in a sense the >> relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I >> guess this why it should be considered opaque. I do not see this >> "opaqueness" as bad. Henning gave good examples. When I buy something in a >> market, I do not ask exactly how the prices are derived. >> >> > It is not maybe essential to know how the price is computed, but it is > critical to know > if that pricing is done with respect to P2P App's expectation. If I reuse > the analogy above, > it is a waste of time to go to an expensive store if there is not any chance > of buying anything. > I better know a-priori if my constraints are in line with the pricing. A few observations regarding P2P expectations are useful here. a) Henning and Richard's suggestion of an abstract goal for the relative order (e.g. low latency) conveys these expectations. From the application standpoint, it is now relieved of topology or network details in order to answer "what does it mean in networking terms if I want low latency?". b) The question of trusting the "price"/"ordering" provided by the Oracle is somewhat easier to answer. Any computation that does not reasonably achieve both the provider and application's goals will naturally lose its popularity. The applications are free to ignore the Oracle's advice when they find out that results are not up to expectations. That means if there is a big enough constituency that finds the Oracle useful, it has reason to exist. In any case a standard query-response medium allows the community to discover and evolve better ordering/pricing/info-dissemination methods. Thanks, Satish _______________________________________________ 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 Jul 31 05:45: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 B7EA43A6C4A; Thu, 31 Jul 2008 05:45: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 BA7003A6C4A for ; Thu, 31 Jul 2008 05:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 8z1YEFihqGVY for ; Thu, 31 Jul 2008 05:45:38 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D28763A6BFE for ; Thu, 31 Jul 2008 05:45:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D21EFE10BE5; Thu, 31 Jul 2008 08:45:23 -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 ACpy83B8iRoz; Thu, 31 Jul 2008 08:45:17 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 4DDD0E10BE2; Thu, 31 Jul 2008 08:45:17 -0400 (EDT) Date: Thu, 31 Jul 2008 08:45:17 -0400 (EDT) From: Laird Popkin To: =?utf-8?Q?Ula=C5=9F_C=2E_Kozat?= Message-ID: <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> In-Reply-To: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [130.129.19.8] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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="===============0851491754==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0851491754== Content-Type: multipart/alternative; boundary="----=_Part_4062_1059867267.1217508317274" ------=_Part_4062_1059867267.1217508317274 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe that the question should not be whether any P2P app cannot achiev= e the=C2=A0 optimizations =C2=A0without a standard protocol, because many p= 2p networks implement some sort of optimization related to localization of = data transfer, often using something oracle-like, but whether it is valuabl= e to have a common protocol for communication between network operators and= applications.=20 Addressing remark 1: localizing network traffic (based on the p4p field tes= ts, which used ISP network maps and an "oracle") shows a strong benefit in = transit reduction and in performance improvement, for networks that are DSL= , Cable or FTTH.=20 Addressing remark 2: the guidance provided by an ALTO server could vary bas= ed on a wide range of metadata. For example, different p2p networks might r= eceive different guidance. Or guidance could vary based on class of content= (e.g. paid commercial content vs. consumer generated content). Rather than= try to incorporate a wide range of specific metadata fields into the ALTO = protocol, I believe that for now it would be better to simply make sure tha= t ALTO requests are extensible so that vendors and providers can implement = whatever metadata that they require, and over time useful metadata fields c= an be standardized.=20 Addressing remark 3: I believe that it may not be possible to define "best"= , and we should leave that definition open to ALTO implementers, and to=C2= =A0 extensions =C2=A0of the protocol. For example, a p2p network could the = same protocol to deliver real-time video streams, and background downloads.= , so to differentiate between the two the application could tell the ALTO s= erver the use case, and the ALTO server could send appropriate guidance.=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: "Ula=C5=9F C. Kozat" =20 To: "Henning Schulzrinne" =20 Cc: p2pi@ietf.org=20 Sent: Wednesday, July 30, 2008 11:43:34 AM (GMT-0500) America/New_York=20 Subject: Re: [p2pi] why I didn't hum yes (yet)=20 My understanding of the problem after reading the sequence of e-mails is a = little bit confused. But I try to summarize my understanding of the ongoing= discussion (mostly I express them as questions):=20 Goal: To develop an "Oracle" architecture to guide peer selection process t= o achieve some Macro performance and/or economical gains.=20 Question 1: Could such an Oracle system be useful to achieve these Macro ga= ins? It is useful iff P2P App cannot do it on its own in a reasonable time = and overhead while Oracle system can.=20 Question 2: Often P2P objectives (in terms of the optimization problem and = constraints) differ from one P2P system to another. Can different P2P Apps = communicate what they need to attain these objectives to the Oracle in some= Macro level and can Oracle make such an assessment=C2=A0 with the high lev= el topology, traffic load, etc. information?=20 Remark 1: If the answer to Question 1 is "no Oracle cannot be useful", I th= ink the argument that P2P anyways can fallback to its own selection process= is not convincing. The answer to Question 1 should be "Yes, the Oracle sys= tem is mostly useful for an important set of P2P apps under at least one in= teresting type of IP network=C2=A0 (e.g., 4G cellular)".=20 Remark 2: Some argue that there are enough research and experimental result= s that hint that the answer to Question 1 is yes. Some argue they are ficti= tious or insufficient or they do not use smart enough P2P Apps. I think the= research and experimental results should be classified in terms of network= assumptions, P2P objectives, and Query-Response types first. For some assu= mptions, for some objectives, and for some query-response types, in my opin= ion, there is enough evidence that Oracle works. But I am not sure whether = "smarter" P2P Apps themselves can do it in a reasonable time and overhead u= nder the considered set-up.=20 Remark3: Again my personal opinion is that if what P2P app wishes to achiev= e is not well communicated with the Oracle system or what the Oracle system= returns back to the P2P App is not well specified apriori, the odds are it= won't be successful. Any chartering should seriously tackle down this issu= e.=20 Ulas=20 On Wed, Jul 30, 2008 at 6:59 AM, Henning Schulzrinne < hgs@cs.columbia.edu = > wrote:=20 Why do you think an end-client wants/needs this information? I'm skeptical = on depending on clients to take actions that benefit someone else (e.g., IS= P) but harm them. The reason why the ordered list is so promising is that i= t turns out often the two optimization problems lead to very similar soluti= ons.=20 If it turns out that for a particular client (P2P or otherwise), it finds t= hat this information correlates well with good performance, the client has = an incentive to use it. This makes it easy to develop client/application-sp= ecific algorithms that rely on common information, rather than having each = client spend a lot of kludgey effort (such as querying looking glass sites)= to get at the data.=20 There seems to be significant published evidence that these metrics do corr= elate, on average, with improved performance, even if they occasionally mis= s the boat. It's the averages we care about, as long as the outliers aren't= ridiculously bad and can be detected at run time.=20 At the very least, I'd argue separating (1) and (2) in terms of specificati= on. (1) is so simple that it would be easy to nail it down, while (2) would= require a bit more work.=20 Depends on the level of detail reported. The items I mentioned seem trivial= and extending the list later seems easy.=20 Phil=20 _______________________________________________=20 p2pi mailing list=20 p2pi@ietf.org=20 https://www.ietf.org/mailman/listinfo/p2pi=20 _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_4062_1059867267.1217508317274 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe that the question should not be wheth= er any P2P app cannot achieve the=C2=A0optimizations=C2=A0without a standar= d protocol, because many p2p networks implement some sort of optimization r= elated to localization of data transfer, often using something oracle-like,= but whether it is valuable to have a common protocol for communication bet= ween network operators and applications.


Addressing rema= rk 1: localizing network traffic (based on the p4p field tests, which used = ISP network maps and an "oracle") shows a strong benefit in transit reducti= on and in performance improvement, for networks that are DSL, Cable or FTTH= .

Addressing remark 2: the guidance provided by an= ALTO server could vary based on a wide range of metadata. For example, dif= ferent p2p networks might receive different guidance. Or guidance could var= y based on class of content (e.g. paid commercial content vs. consumer gene= rated content). Rather than try to incorporate a wide range of specific met= adata fields into the ALTO protocol, I believe that for now it would be bet= ter to simply make sure that ALTO requests are extensible so that vendors a= nd providers can implement whatever metadata that they require, and over ti= me useful metadata fields can be standardized.

Add= ressing remark 3: I believe that it may not be possible to define "best", a= nd we should leave that definition open to ALTO implementers, and to=C2=A0e= xtensions=C2=A0of the protocol. For example, a p2p network could the same p= rotocol to deliver real-time video streams, and background downloads., so t= o differentiate between the two the application could tell the ALTO server = the use case, and the ALTO server could send appropriate guidance.

-= =C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks
=C2=A0=C2=A0= mobile:=C2=A0646/465-0570

----- Original Message -----
From: "Ula= =C5=9F C. Kozat" <ulas.kozat@gmail.com>
To: "Henning Schulzrinne" <= ;hgs@cs.columbia.edu>
Cc: p2pi@ietf.org
Sent: Wednesday, July 30, 200= 8 11:43:34 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] why I didn= 't hum yes (yet)

My understanding of the problem af= ter reading the sequence of e-mails is a little bit confused. But I try to = summarize my understanding of the ongoing discussion (mostly I express them= as questions):

Goal: To develop an "Oracle" architecture to guide peer selection process t= o achieve some Macro performance and/or economical gains.
Question 1: Co= uld such an Oracle system be useful to achieve these Macro gains? It is use= ful iff P2P App cannot do it on its own in a reasonable time and overhead w= hile Oracle system can.
Question 2: Often P2P objectives (in terms of the optimization problem and = constraints) differ from one P2P system to another. Can different P2P Apps = communicate what they need to attain these objectives to the Oracle in some= Macro level and can Oracle make such an assessment=C2=A0 with the high lev= el topology, traffic load, etc. information?


Remark 1: If the answer to Question 1 is "no Oracle cannot be usefu= l", I think the argument that P2P anyways can fallback to its own selection= process is not convincing. The answer to Question 1 should be "Yes, the Or= acle system is mostly useful for an important set of P2P apps under at leas= t one interesting type of IP network=C2=A0 (e.g., 4G cellular)".

Remark 2: Some argue that there are enough research and experimental re= sults that hint that the answer to Question 1 is yes. Some argue they are f= ictitious or insufficient or they do not use smart enough P2P Apps. I think= the research and experimental results should be classified in terms of net= work assumptions, P2P objectives, and Query-Response types first. For some = assumptions, for some objectives, and for some query-response types, in my = opinion, there is enough evidence that Oracle works. But I am not sure whet= her "smarter" P2P Apps themselves can do it in a reasonable time and overhe= ad under the considered set-up.

Remark3: Again my personal opinion is that if what P2P app wishes to ac= hieve is not well communicated with the Oracle system or what the Oracle sy= stem returns back to the P2P App is not well specified apriori, the odds ar= e it won't be successful. Any chartering should seriously tackle down this = issue.

Ulas

On Wed, Jul 30, 2008 at 6:59 AM,= Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

Why do you think an end-client wants/needs this information? I'm skeptical = on depending on clients to take actions that benefit someone else (e.g., IS= P) but harm them. The reason why the ordered list is so promising is that i= t turns out often the two optimization problems lead to very similar soluti= ons.


If it turns out that for a particular client (P2P or otherwise), it finds t= hat this information correlates well with good performance, the client has = an incentive to use it. This makes it easy to develop client/application-sp= ecific algorithms that rely on common information, rather than having each = client spend a lot of kludgey effort (such as querying looking glass sites)= to get at the data.

There seems to be significant published evidence that these metrics do corr= elate, on average, with improved performance, even if they occasionally mis= s the boat. It's the averages we care about, as long as the outliers aren't= ridiculously bad and can be detected at run time.



At the very least, I'd argue separating (1) and (2) in terms of specificati= on. (1) is so simple that it would be easy to nail it down, while (2) would= require a bit more work.

Depends on the level of detail reported. The items I mentioned seem trivial= and extending the list later seems easy.




Phil

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


_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
------=_Part_4062_1059867267.1217508317274-- --===============0851491754== 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 --===============0851491754==-- From p2pi-bounces@ietf.org Thu Jul 31 06:02: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 AC7AC3A6C6E; Thu, 31 Jul 2008 06:02: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 C495C3A68C2 for ; Thu, 31 Jul 2008 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.19 X-Spam-Level: X-Spam-Status: No, score=-10.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 X3IcJO0sKnAf for ; Thu, 31 Jul 2008 06:01:59 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 842CD3A63EC for ; Thu, 31 Jul 2008 06:01:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 2E663E10BDB; Thu, 31 Jul 2008 09:01:41 -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 fgQBrxM2RGT3; Thu, 31 Jul 2008 09:01:30 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id D4319E10B83; Thu, 31 Jul 2008 09:01:30 -0400 (EDT) Date: Thu, 31 Jul 2008 09:01:30 -0400 (EDT) From: Laird Popkin To: Henning Schulzrinne Message-ID: <1251684323.90561217509290847.JavaMail.root@dkny.pando.com> In-Reply-To: <1466365856.90511217508856958.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [130.129.19.8] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 thing that limits the harm caused by bad guidance is that p2p networks do not use just the nodes provided by ALTO, but also establish random peer connections using existing mechanisms (e.g. peer exchange). For example, in the P4P field tests, we used 80% P4P guidance and 20% random peers, and peers also find more 'random' peers over time (e.g. peer exchange). This was done so that the p2p network is robustly connected between ISPs (for example), while using 100% P4P guidance could potentially lead to isolated clusters of peers in each ISP, which would be harmful to the network. The random peer connections interact with the p2p networks' ongoing optimization of peer transfers to take advantage of 'good' guidance, and to limit the harm caused by 'bad' guidance. For example, let's consider the ALTO recommendations as being 'great'. In this case a peer might 40 great peer recommendations and 10 random ones. The peer will immediately start using the 'great' peers and download only minimally from the 'random' peers. Now let's consider the ALTO recommendations as being 'bad', where they're worse than random peers. In this case a peer might get 40 'bad' peer recommendations and 10 random ones. The peer might waste time trying the 'bad' peer recommendations, but then optimizes to use the faster 'random' peers. So while bad guidance slows down the initial speed ramp a bit, the impact is limited. In P4P testing, we saw that good guidance could generate increases of download speed of 3x or better, and 10x in some cases, and that bad guidance could generate slowdowns of perhaps 20%. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Henning Schulzrinne" To: "Philip Levis" Cc: p2pi@ietf.org Sent: Wednesday, July 30, 2008 9:59:19 AM (GMT-0500) America/New_York Subject: Re: [p2pi] why I didn't hum yes (yet) > > Why do you think an end-client wants/needs this information? I'm > skeptical on depending on clients to take actions that benefit > someone else (e.g., ISP) but harm them. The reason why the ordered > list is so promising is that it turns out often the two optimization > problems lead to very similar solutions. > If it turns out that for a particular client (P2P or otherwise), it finds that this information correlates well with good performance, the client has an incentive to use it. This makes it easy to develop client/application-specific algorithms that rely on common information, rather than having each client spend a lot of kludgey effort (such as querying looking glass sites) to get at the data. There seems to be significant published evidence that these metrics do correlate, on average, with improved performance, even if they occasionally miss the boat. It's the averages we care about, as long as the outliers aren't ridiculously bad and can be detected at run time. > At the very least, I'd argue separating (1) and (2) in terms of > specification. (1) is so simple that it would be easy to nail it > down, while (2) would require a bit more work. Depends on the level of detail reported. The items I mentioned seem trivial and extending the list later seems easy. > > > 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 Thu Jul 31 08:07: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 0B7FE3A6AB8; Thu, 31 Jul 2008 08:07: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 A63C13A6CC9 for ; Thu, 31 Jul 2008 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.656 X-Spam-Level: X-Spam-Status: No, score=-5.656 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 3o8+LE7WBMhF for ; Thu, 31 Jul 2008 07:41:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B61373A6CA5 for ; Thu, 31 Jul 2008 07:41:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="91572211" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2008 14:41:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6VEf3oS002382 for ; Thu, 31 Jul 2008 07:41:03 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VEf3pI008148 for ; Thu, 31 Jul 2008 14:41:03 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA28067 for p2pi@ietf.org; Thu, 31 Jul 2008 07:37:42 -0700 (PDT) Date: Thu, 31 Jul 2008 07:37:42 -0700 From: Toerless Eckert To: p2pi@ietf.org Message-ID: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1218; t=1217515264; x=1218379264; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20DSCP=20or=20not |Sender:=20; bh=KTMEfj0XPc4qE1lDYcXl8n7gk5VHmZSCDbsGQrDU6lU=; b=TihvLjZFlClleJu27ABTqcAMFXMWaFtHohiBN+Nr2tW4d2ULS7R6fl/bfH to0DGFjYQH5us2B93V1fQgHpXNXtEZ6wP+FoFv5Ds/H2Kg8Wou1TwNE33vjr 8pjMKUgdkm; Authentication-Results: sj-dkim-2; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Thu, 31 Jul 2008 08:07:48 -0700 Subject: [p2pi] DSCP or not 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 to me as if the best long term solution would be to utilize a scavenger DSCP class in the network. For such a class i think the existing flow control mechanisms as eg: in TCP may not be suited best to exhaust the available bandwidth - as it likely fluctuates more frequently and short term than in best effort. SSo some form of agressive transmission with effecient retransmission (and maybe FEC) is probably best when using such a scavenger clas. Practically speaking, it will be a long time for most core networks to support such a clss, specifically because of the limited number of exp bits in MPLS, inertia, technical problems, and so on. So now we need the algorithm to handle scavenger traffic in the best effort class, that very carefully tries not to cause any congestion and in face of congestion throttles itself back to zero or close to it. If we could bring together those two algorithms together, and the algorithm for a connection would be selected based on whether or not the ntework resets the scavenger DSCP class to best effort (because there is no scavenger class configured) ... then i think this would be a good short and long term solution. Cheers Toerless _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 08:48: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 12B943A6C81; Thu, 31 Jul 2008 08:48: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 CEEC63A6C81 for ; Thu, 31 Jul 2008 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 uU08UQ6vd-zU for ; Thu, 31 Jul 2008 08:48:41 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id E75A33A682E for ; Thu, 31 Jul 2008 08:48:40 -0700 (PDT) Received: from dhcp-130-129-19-238.meeting.ietf.org ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6VFm6eE022814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Jul 2008 11:48:08 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Toerless Eckert In-Reply-To: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 11:48:05 -0400 References: <20080731143742.GM10916@cisco.com> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 don't think we need to wait until a DiffServ/scavenger service is supported across the backbone. Most of the problems are in the access networks (both within a residence and in the first mile), where deploying DiffServ seems much more realistic. The backbone network should presumably leave the DSCP alone in transit, but even that isn't all that important, since the important link limit in both cable and DSL is the uplink. I don't know if and how DOCSIS can manage transmission slots on the uplink based on DiffServ, however. Henning On Jul 31, 2008, at 10:37 AM, Toerless Eckert wrote: > > Seems to me as if the best long term solution would be to utilize a > scavenger > DSCP class in the network. For such a class i think the existing > flow control mechanisms as eg: in TCP may not be suited best to > exhaust > the available bandwidth - as it likely fluctuates more frequently and > short term than in best effort. SSo some form of agressive > transmission with > effecient retransmission (and maybe FEC) is probably best when using > such a scavenger clas. > > Practically speaking, it will be a long time for most core networks > to support such a clss, specifically because of the limited number of > exp bits in MPLS, inertia, technical problems, and so on. So now > we need the algorithm to handle scavenger traffic in the best effort > class, > that very carefully tries not to cause any congestion and in face of > congestion throttles itself back to zero or close to it. > > If we could bring together those two algorithms together, and the > algorithm for a connection would be selected based on whether or not > the ntework > resets the scavenger DSCP class to best effort (because there is no > scavenger class > configured) ... then i think this would be a good short and long > term solution. > > Cheers > Toerless > _______________________________________________ > 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 Jul 31 08:50: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 C57223A6BAE; Thu, 31 Jul 2008 08:50: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 08E3B3A6BAE for ; Thu, 31 Jul 2008 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 lMNc3P-faMPo for ; Thu, 31 Jul 2008 08:50:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 11DD13A6949 for ; Thu, 31 Jul 2008 08:50:35 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 397F333C3C; Thu, 31 Jul 2008 11:50:16 -0400 (EDT) Date: Thu, 31 Jul 2008 11:50:16 -0400 From: John Leslie To: Toerless Eckert Message-ID: <20080731155016.GZ24936@verdi> References: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080731143742.GM10916@cisco.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 Toerless Eckert wrote: > > Seems to me as if the best long term solution would be to utilize a > scavenger DSCP class in the network. Possibly, but this is "long-term" and requires wide enough deployment of the "scavenger DSCP class"... > For such a class i think the existing flow control mechanisms as eg: > in TCP may not be suited best to exhaust the available bandwidth - > as it likely fluctuates more frequently and short term than in best > effort. Hard to say -- it depends so much upon buffer sizes and RTT: but certainly for small enough buffer sizes and large enough RTT this would be a problem. > So some form of agressive transmission with effecient retransmission > (and maybe FEC) is probably best when using such a scavenger class. That doesn't necessarily follow... We do want to keep the bottleneck buffer full enough; but we'd much prefer to never fill it so much as to drop our packet(s). > Practically speaking, it will be a long time for most core networks > to support such a class, specifically because of the limited number > of exp bits in MPLS, inertia, technical problems, and so on. I'd list "inertia" first (and I'm not sure the others even apply). > So now we need the algorithm to handle scavenger traffic in the best > effort class, that very carefully tries not to cause any congestion > and in face of congestion throttles itself back to zero or close to it. This does look like our best bet short-term. > If we could bring together those two algorithms together, and the > algorithm for a connection would be selected based on whether or not > the network resets the scavenger DSCP class to best effort (because > there is no scavenger class configured) ... then i think this would > be a good short and long term solution. I would prefer not to concern ourselves with guessing what the future may bring in "network" support of DSCP. It's really unlikely that we'll see "enough" DSCP support within five years. Instead, I look at the actual situation driving this work, and I see a great likelihood of the bottleneck being the uplink from a customer site. To me, this almost shouts, "backpressure solution needed." If the customer's ISP runs an ALTO server, that server _should_ be in a "good enough" position to signal the backpressure. It does tend to change the way we look at developing an ALTO protocol, but IMHO the payoff could be significant... -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 10:02: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 B71EE28C23D; Thu, 31 Jul 2008 10:02: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 F27BB28C259 for ; Thu, 31 Jul 2008 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 pBukTLhH9KNh for ; Thu, 31 Jul 2008 10:02:41 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D1EB128C1C9 for ; Thu, 31 Jul 2008 10:02:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6VH2rq3004184; Thu, 31 Jul 2008 20:02:54 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 20:02:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 20:02:35 +0300 Received: from [130.129.23.187] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 20:02:34 +0300 Message-Id: <3C4E554A-1543-41BD-B1B4-C9D3E5B37EA5@nokia.com> From: Lars Eggert To: ext Toerless Eckert In-Reply-To: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 18:02:30 +0100 References: <20080731143742.GM10916@cisco.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 31 Jul 2008 17:02:35.0173 (UTC) FILETIME=[3A922D50:01C8F32F] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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-7-31, at 15:37, ext Toerless Eckert wrote: > Seems to me as if the best long term solution would be to utilize a > scavenger > DSCP class in the network. RFC3662 was published five years ago. Even assuming slow adoption, we should have heard from some operators that use it by now. I'm not aware of any deployment. I agree that universal deployment of DiffServ scavenger service would be the better solution, but it looks unlikely it will happen. A transport-level solution that approximates what the DiffServ solution would give us, but with a different (better?) incentive angle, seems attractive. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 10:05: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 D9F813A6A76; Thu, 31 Jul 2008 10:05: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 16D0E3A6A76 for ; Thu, 31 Jul 2008 10:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 BJskIdSkg0Yn for ; Thu, 31 Jul 2008 10:05:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E0F4D3A6D03 for ; Thu, 31 Jul 2008 10:05:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="91642850" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2008 17:05:41 +0000 Received: from [130.129.22.215] ([10.86.248.230]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m6VGgXMH010134; Thu, 31 Jul 2008 09:42:33 -0700 Message-Id: <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> From: David R Oran To: Henning Schulzrinne In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 31 Jul 2008 13:05:38 -0400 References: <20080731143742.GM10916@cisco.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2315; t=1217522554; x=1218386554; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20DSCP=20or=20not |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=iWjWK1C7x0F8l9Tc1sr1WC4Fa/ffhGOt4OdCooOK1FE=; b=hhKu3tJCb/4HS8I+Px36ObNE3uV8VxEsvH48nkjDyhH4aNJQnXCoBy5vfs bGICWzgo1Zzp/5EMJpkPEDthI01lzCSrCnXsNNo1/LKTaNXE0OM37i5ySV7s OWABVOhli4; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote: > I don't think we need to wait until a DiffServ/scavenger service is > supported across the backbone. Most of the problems are in the > access networks (both within a residence and in the first mile), > where deploying DiffServ seems much more realistic. The backbone > network should presumably leave the DSCP alone in transit, but even > that isn't all that important, since the important link limit in > both cable and DSL is the uplink. I don't know if and how DOCSIS can > manage transmission slots on the uplink based on DiffServ, however. > Yes. > Henning > > On Jul 31, 2008, at 10:37 AM, Toerless Eckert wrote: > >> >> Seems to me as if the best long term solution would be to utilize a >> scavenger >> DSCP class in the network. For such a class i think the existing >> flow control mechanisms as eg: in TCP may not be suited best to >> exhaust >> the available bandwidth - as it likely fluctuates more frequently and >> short term than in best effort. SSo some form of agressive >> transmission with >> effecient retransmission (and maybe FEC) is probably best when using >> such a scavenger clas. >> >> Practically speaking, it will be a long time for most core networks >> to support such a clss, specifically because of the limited number of >> exp bits in MPLS, inertia, technical problems, and so on. So now >> we need the algorithm to handle scavenger traffic in the best >> effort class, >> that very carefully tries not to cause any congestion and in face of >> congestion throttles itself back to zero or close to it. >> >> If we could bring together those two algorithms together, and the >> algorithm for a connection would be selected based on whether or >> not the ntework >> resets the scavenger DSCP class to best effort (because there is no >> scavenger class >> configured) ... then i think this would be a good short and long >> term solution. >> >> Cheers >> Toerless >> _______________________________________________ >> 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 Thu Jul 31 10:54: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 CCD4C28C16D; Thu, 31 Jul 2008 10:54: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 7DCB728C16D for ; Thu, 31 Jul 2008 10:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] 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 ubvY82mgG-Qb for ; Thu, 31 Jul 2008 10:54:09 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 0519728C1A5 for ; Thu, 31 Jul 2008 10:54:08 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m6VHqbVX020000; Thu, 31 Jul 2008 19:54:23 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jul 2008 19:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 19:52:41 +0200 Message-ID: <00275A5B436CA441900CB10936742A38DFAC8D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20080731143742.GM10916@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] DSCP or not Thread-Index: AcjzH0AVjelGGKhRQSSTEqhi5OCjOwACiJYA References: <20080731143742.GM10916@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Toerless Eckert" , X-OriginalArrivalTime: 31 Jul 2008 17:52:45.0065 (UTC) FILETIME=[3C9B3F90:01C8F336] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [p2pi] DSCP or not 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 to me as if the best long term solution would be to > utilize a scavenger DSCP class in the network. make sense. the real question is the how long would it take for an RFC3662-like DSCP to be deployed and this depends on which extend. on the other hand, now that need has been identified together with the identification of congestion at the access level would expectedly limit the deployment time. i see a need to document this approach in the context of this effort. > For such a class i think the existing > flow control mechanisms as eg: in TCP may not be suited best > to exhaust > the available bandwidth - as it likely fluctuates more frequently and > short term than in best effort. SSo some form of agressive > transmission with > effecient retransmission (and maybe FEC) is probably best when using > such a scavenger clas. > > Practically speaking, it will be a long time for most core networks > to support such a clss, specifically because of the limited number of > exp bits in MPLS, inertia, technical problems, and so on. see above. > So now we need the algorithm to handle scavenger traffic in the best > effort class, > that very carefully tries not to cause any congestion and in face of > congestion throttles itself back to zero or close to it. how long this one would take - not sure we got a clear answer during the BoF ? and how trustable this solution would be ? -d. > If we could bring together those two algorithms together, and the > algorithm for a connection would be selected based on whether > or not the ntework > resets the scavenger DSCP class to best effort (because there > is no scavenger class > configured) ... then i think this would be a good short and > long term solution. > > Cheers > Toerless > _______________________________________________ > 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 Jul 31 10:54: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 A461428C1C7; Thu, 31 Jul 2008 10:54: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 F04EB28C1C7 for ; Thu, 31 Jul 2008 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 EACa4istlOhl for ; Thu, 31 Jul 2008 10:54:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id F2F6E28C1FE for ; Thu, 31 Jul 2008 10:54:18 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 18:54:36 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 18:54:36 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217526785694; Thu, 31 Jul 2008 18:53:05 +0100 Received: from mut.jungle.bt.co.uk ([10.73.178.210]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6VHsBVg000355; Thu, 31 Jul 2008 18:54:32 +0100 Message-Id: <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 31 Jul 2008 18:54:06 +0100 To: Laird Popkin From: Bob Briscoe In-Reply-To: <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com> <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Jul 2008 17:54:36.0414 (UTC) FILETIME=[7EF9C1E0:01C8F336] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Laird, At 13:45 31/07/2008, Laird Popkin wrote: >Addressing remark 1: localizing network traffic (based on the p4p >field tests, which used ISP network maps and an "oracle") shows a >strong benefit in transit reduction and in performance improvement, >for networks that are DSL, Cable or FTTH. I think my rather important previous point got missed (sorry my mail had a lot of points)... Neither of these metrics for 'better' impresses me much at all. * If performance of p2p is better, and if there is shared congestion with other non-p2p users on the same local network, this means the performance of others will most likely be worse. Overall, is this better or worse? * If there's transit reduction, equivalent traffic will instead be being uploaded from the local network. Again, if the local network already has shared congestion upstream (a cable network does), that's making it _worse_ both for local p2p & non-p2p users. It costs more (bit for bit) to upgrade access and backhaul than it does to upgrade interconnect (there's a considerable economy of scale). If someone from a cablecco has told you it's most important to reduce transit costs, you'll find they did NOT mean "and at the same time please introduce higher backhaul and access costs instead". See the picture I posted yesterday to this list: The Internetwork is provided to be used. Let's not assume a DISINTERNET is 'better' without being clear what 'better' means. I've seen no research that uses a full cost-benefit analysis. That's hard (e.g. what's the relative value of p2p bits versus non-p2p bits). But without such a study, unfortunately, what everyone is calling 'better' looks like 'worse' to me on second looks - at least for networks with a congested upstream. On third looks (ie a full study) it might not be worse. But can people please enter this debate on the assumption that network economics is dangerous in the hands of amateurs (which includes the large majority of folks even in telcos/cablecos). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 11:07: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 440DC3A6B5D; Thu, 31 Jul 2008 11:07: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 041E728C216 for ; Thu, 31 Jul 2008 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 idnt66p7UcjI for ; Thu, 31 Jul 2008 11:07:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B5B2E3A6B5D for ; Thu, 31 Jul 2008 11:07:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="71035250" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2008 18:06:51 +0000 Received: from [130.129.22.215] ([10.86.248.230]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m6VHhglP012760; Thu, 31 Jul 2008 10:43:43 -0700 Message-Id: From: David R Oran To: "PAPADIMITRIOU Dimitri" In-Reply-To: <00275A5B436CA441900CB10936742A38DFAC8D@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 31 Jul 2008 14:06:48 -0400 References: <20080731143742.GM10916@cisco.com> <00275A5B436CA441900CB10936742A38DFAC8D@FRVELSMBS22.ad2.ad.alcatel.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2707; t=1217526224; x=1218390224; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20DSCP=20or=20not |Sender:=20 |To:=20=22PAPADIMITRIOU=20Dimitri=22=20; bh=ne9lfth2E6yo9pWoi0pRab/5XXo+ucnkXm9Kfn80bs8=; b=S0h2Wiibmz/kcAjNHLtZaUj/Y1gaS2wKoXtzBPz65mfTS+TpHR/RNpfNQU nCmumLcVPrYlU9Ex7zHQycjBhOkgWBtjkaVB++t7SpAQhmFCzxFtUZPP11xZ A3ZInnF6My; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 we can exploit both a scavenger DSCP and different congestion control in the endpoint as long as the the interaction between the two is understood and the combination works as well or better than either alone. That allows incremental deployment to have a decent utility function, and incidentally may allow better instrumentation by making visible the usage of the changed congestion control in the positions of the network that don't over-write non BE dscps. DaveO. On Jul 31, 2008, at 1:52 PM, PAPADIMITRIOU Dimitri wrote: > >> Seems to me as if the best long term solution would be to >> utilize a scavenger DSCP class in the network. > > make sense. the real question is the how long would it take for an > RFC3662-like DSCP to be deployed and this depends on which extend. on > the other hand, now that need has been identified together with the > identification of congestion at the access level would expectedly > limit > the deployment time. i see a need to document this approach in the > context of this effort. > >> For such a class i think the existing >> flow control mechanisms as eg: in TCP may not be suited best >> to exhaust >> the available bandwidth - as it likely fluctuates more frequently and >> short term than in best effort. SSo some form of agressive >> transmission with >> effecient retransmission (and maybe FEC) is probably best when using >> such a scavenger clas. >> >> Practically speaking, it will be a long time for most core networks >> to support such a clss, specifically because of the limited number of >> exp bits in MPLS, inertia, technical problems, and so on. > > see above. > >> So now we need the algorithm to handle scavenger traffic in the best >> effort class, >> that very carefully tries not to cause any congestion and in face of >> congestion throttles itself back to zero or close to it. > > how long this one would take - not sure we got a clear answer during > the > BoF ? and how trustable this solution would be ? > > -d. >> If we could bring together those two algorithms together, and the >> algorithm for a connection would be selected based on whether >> or not the ntework >> resets the scavenger DSCP class to best effort (because there >> is no scavenger class >> configured) ... then i think this would be a good short and >> long term solution. >> >> Cheers >> Toerless >> _______________________________________________ >> 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 Thu Jul 31 11:21: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 0A9E828C159; Thu, 31 Jul 2008 11:21: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 96A9128C159 for ; Thu, 31 Jul 2008 11:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 7OvPh76xKnR2 for ; Thu, 31 Jul 2008 11:21:01 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id C41C53A6960 for ; Thu, 31 Jul 2008 11:21:01 -0700 (PDT) Received: from dhcp-130-129-19-238.meeting.ietf.org ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6VIKnRm019029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Jul 2008 14:20:50 -0400 (EDT) Message-Id: <241D6A3B-8E61-4986-BD67-2FDF4C249BE8@cs.columbia.edu> From: Henning Schulzrinne To: Lars Eggert In-Reply-To: <3C4E554A-1543-41BD-B1B4-C9D3E5B37EA5@nokia.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 14:20:48 -0400 References: <20080731143742.GM10916@cisco.com> <3C4E554A-1543-41BD-B1B4-C9D3E5B37EA5@nokia.com> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ext Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 > Part of the problem is that DiffServ was never completely specified, in that there were no standard DSCP values to make deployment feasible at the consumer level. Plus, the problematic combination of VoIP + P2P is relatively new. Also, as far as I know, DiffServ is deployed in a number of more closed networks. > RFC3662 was published five years ago. Even assuming slow adoption, > we should have heard from some operators that use it by now. I'm not > aware of any deployment. > > I agree that universal deployment of DiffServ scavenger service > would be the better solution, but it looks unlikely it will happen. > A transport-level solution that approximates what the DiffServ > solution would give us, but with a different (better?) incentive > angle, seems attractive. > > 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 Thu Jul 31 15:03: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 20D8128C276; Thu, 31 Jul 2008 15:03: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 3FF6B3A6864 for ; Thu, 31 Jul 2008 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, J_CHICKENPOX_57=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 1L-hdu+ulGEA for ; Thu, 31 Jul 2008 15:03:35 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 6B3833A67FF for ; Thu, 31 Jul 2008 15:03:31 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 31 Jul 2008 15:01:20 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 15:01:29 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 15:01:29 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 18:01:27 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 21:57:13 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 14:57:08 -0700 From: Reinaldo Penno To: Bob Briscoe , Laird Popkin Message-ID: Thread-Topic: [p2pi] why I didn't hum yes (yet) Thread-Index: AcjzWGBlHgD1ftjMNUCXsH5q9Rt3bQ== In-Reply-To: <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> Mime-version: 1.0 X-OriginalArrivalTime: 31 Jul 2008 22:01:27.0513 (UTC) FILETIME=[FB141C90:01C8F358] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 believe see your point. Even if we decouple the optimization part from the protocol, we are still doing this work under the assumption that the optimization will make everybody happy (based on some policy). If it cannot be proved that the optimization work for P2P clients _and_ Service Provider on a cost-effective basis then the protocol work is moot. I think a cost analysis of such optimizations from a Service Provider point of view would be interesting. Thanks, Reinaldo On 7/31/08 10:54 AM, "Bob Briscoe" wrote: > Laird, > > At 13:45 31/07/2008, Laird Popkin wrote: >> Addressing remark 1: localizing network traffic (based on the p4p >> field tests, which used ISP network maps and an "oracle") shows a >> strong benefit in transit reduction and in performance improvement, >> for networks that are DSL, Cable or FTTH. > > I think my rather important previous point got missed (sorry my mail > had a lot of points)... > > Neither of these metrics for 'better' impresses me much at all. > > * If performance of p2p is better, and if there is shared congestion > with other non-p2p users on the same local network, this means the > performance of others will most likely be worse. Overall, is this > better or worse? > > * If there's transit reduction, equivalent traffic will instead be > being uploaded from the local network. Again, if the local network > already has shared congestion upstream (a cable network does), that's > making it _worse_ both for local p2p & non-p2p users. > > > It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". > > See the picture I posted yesterday to this list: > f> > > The Internetwork is provided to be used. Let's not assume a > DISINTERNET is 'better' without being clear what 'better' means. > > I've seen no research that uses a full cost-benefit analysis. That's > hard (e.g. what's the relative value of p2p bits versus non-p2p > bits). But without such a study, unfortunately, what everyone is > calling 'better' looks like 'worse' to me on second looks - at least > for networks with a congested upstream. > > On third looks (ie a full study) it might not be worse. But can > people please enter this debate on the assumption that network > economics is dangerous in the hands of amateurs (which includes the > large majority of folks even in telcos/cablecos). > > > Bob > > > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > > _______________________________________________ > 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 Jul 31 16:46: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 1680C3A6D56; Thu, 31 Jul 2008 16:46: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 32A523A6D56 for ; Thu, 31 Jul 2008 16:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.072 X-Spam-Level: X-Spam-Status: No, score=-0.072 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 5pslhexSFX-i for ; Thu, 31 Jul 2008 16:46:11 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7F8B23A69E0 for ; Thu, 31 Jul 2008 16:46:10 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 00:46:23 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 00:46:23 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217547983202; Fri, 1 Aug 2008 00:46:23 +0100 Received: from mut.jungle.bt.co.uk ([10.73.144.37]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6VNk432028583; Fri, 1 Aug 2008 00:46:21 +0100 Message-Id: <200807312346.m6VNk432028583@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Aug 2008 00:46:01 +0100 To: Henning Schulzrinne From: Bob Briscoe In-Reply-To: <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> References: <20080731143742.GM10916@cisco.com> <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Jul 2008 23:46:23.0796 (UTC) FILETIME=[A3F4A740:01C8F367] Cc: p2pi@ietf.org, Toerless Eckert Subject: Re: [p2pi] DSCP or not 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 Henning, etc Yes, access is the pinch point (and interconnect). But your facts aren't quite right on DSL... The user's own DSL upstream access is certainly a bottleneck (so you'd just have to buy a home hub that does Diffserv). But there's absolutely never any congestion on the shared upstream backhaul (because it's symmetric but fed by the asymmetric access). However, a combination of file-sharing traffic and provisioning with contention makes the downstream DSL backhaul of many providers show persistent loss rates (0-2% peaking at 3% somtimes) throughout the 'day' (08:00-24:00 ish). To add Diffserv would require configing it in the downstream queues of the remote access server (BRAS). Regarding vendor support for Diffserv on BRASs, many support it, but most vendors offer fairly limited numbers of queues and you may find all the queues are already used for other scheduling stuff the provider has already put in (weighted fair queueing between ISPs sharing the BRAS, video services, VoIP etc). IOW, there's already a lot of scheduling stuff done in access networks - much of it is Diffserv-based - ie driven by internally generated DSCPs - but much is just nailed up by the provider config locally on the link in question. BT have been drawing up plans for a scavenger class on the most congested links I mention above for the last few months, but that's not an official customer promise or anything. Just internal design work that may get taken up as a product, or may not. Initially it's unlikely to have a customer-controlled interface. On backbones, it's an absolute certainty that any DSCP set for one network would currently be cleared by the next. There's been pre-standards inter-provider DS activity around VPNs for some time much of which could be re-used for scavenger. Dave Clark pulled it together to try to bridge the impasse that DS had got to. Bruce Davie was the co-chair of the w-g. The idea was to put it all in this white paper: then go off and put the different parts into the appropriate standards bodies. This has been happeneing (e.g. inter-provider SLA metrics in the ITU etc). Here's my brief 3pp comparison of the issues between doing scavenger in the host and in the network, that I mentioned this afternoon: "Solving this traffic management problem... and the next, and the next" The main issue for DS is of course the interface with hosts. But also that networks have to add policing to BE once BE is better than something else. But everyone's guessing when they work out how to do this, because they can't use traditional Diffserv token bucket policing for residential customers - the traffic isn't aggregated enough. So it's all volume limits and arbitrary stuff being bandied about. However, I've also tried to show that it's not all downhill for host-based scavenger either, tho I think it has more chance of getting there first (in a sense it already has with DNA) but I predict issues we haven't seen yet, which is why TANA is right to at least aim to document the issue as a whole. Does anyone know what the status of the background service is in 3GPP? It's been in the specs along with EF, AF & BE for some time (see ref in my p2pi position paper above). Bob At 18:05 31/07/2008, David R Oran wrote: >On Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote: > >>I don't think we need to wait until a DiffServ/scavenger service is >>supported across the backbone. Most of the problems are in the >>access networks (both within a residence and in the first mile), >>where deploying DiffServ seems much more realistic. The backbone >>network should presumably leave the DSCP alone in transit, but even >>that isn't all that important, since the important link limit in >>both cable and DSL is the uplink. I don't know if and how DOCSIS can >>manage transmission slots on the uplink based on DiffServ, however. >Yes. > >>Henning >> >>On Jul 31, 2008, at 10:37 AM, Toerless Eckert wrote: >> >>> >>>Seems to me as if the best long term solution would be to utilize a >>>scavenger >>>DSCP class in the network. For such a class i think the existing >>>flow control mechanisms as eg: in TCP may not be suited best to >>>exhaust >>>the available bandwidth - as it likely fluctuates more frequently and >>>short term than in best effort. SSo some form of agressive >>>transmission with >>>effecient retransmission (and maybe FEC) is probably best when using >>>such a scavenger clas. >>> >>>Practically speaking, it will be a long time for most core networks >>>to support such a clss, specifically because of the limited number of >>>exp bits in MPLS, inertia, technical problems, and so on. So now >>>we need the algorithm to handle scavenger traffic in the best >>>effort class, >>>that very carefully tries not to cause any congestion and in face of >>>congestion throttles itself back to zero or close to it. >>> >>>If we could bring together those two algorithms together, and the >>>algorithm for a connection would be selected based on whether or >>>not the ntework >>>resets the scavenger DSCP class to best effort (because there is no >>>scavenger class >>>configured) ... then i think this would be a good short and long >>>term solution. >>> >>>Cheers >>> Toerless >>>_______________________________________________ >>>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 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 17:50: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 361E528C2B0; Thu, 31 Jul 2008 17:50: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 AC64E28C310 for ; Thu, 31 Jul 2008 17:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 34QZaVOPDST8 for ; Thu, 31 Jul 2008 17:49:53 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id D45D428C2B0 for ; Thu, 31 Jul 2008 17:49:52 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 01:50:05 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 01:50:03 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217551675580; Fri, 1 Aug 2008 01:47:55 +0100 Received: from mut.jungle.bt.co.uk ([10.73.64.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m710nWGx032599; Fri, 1 Aug 2008 01:50:01 +0100 Message-Id: <200808010050.m710nWGx032599@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Aug 2008 01:14:01 +0100 To: Reinaldo Penno From: Bob Briscoe In-Reply-To: References: <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 01 Aug 2008 00:50:03.0905 (UTC) FILETIME=[88EB0710:01C8F370] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Reinaldo, There's no need to include the service provider's (ISP's) view. I was merely proposing we should include the non-p2p users potentially impacted by the better performance of p2p. People often talk about harm to 'the network', but the ISP isn't harmed. It's other user's traffic that is harmed. The ISP's aim is to try to ensure its customers as a whole get most out of the network - only in that sense is the ISP 'harmed' if they don't - because the ISP is then less competitive against another ISP that manages to achieve a better carve up. Bob At 22:57 31/07/2008, Reinaldo Penno wrote: >I believe see your point. Even if we decouple the optimization part from the >protocol, we are still doing this work under the assumption that the >optimization will make everybody happy (based on some policy). > >If it cannot be proved that the optimization work for P2P clients _and_ >Service Provider on a cost-effective basis then the protocol work is moot. > >I think a cost analysis of such optimizations from a Service Provider point >of view would be interesting. > >Thanks, > >Reinaldo > > >On 7/31/08 10:54 AM, "Bob Briscoe" wrote: > > > Laird, > > > > At 13:45 31/07/2008, Laird Popkin wrote: > >> Addressing remark 1: localizing network traffic (based on the p4p > >> field tests, which used ISP network maps and an "oracle") shows a > >> strong benefit in transit reduction and in performance improvement, > >> for networks that are DSL, Cable or FTTH. > > > > I think my rather important previous point got missed (sorry my mail > > had a lot of points)... > > > > Neither of these metrics for 'better' impresses me much at all. > > > > * If performance of p2p is better, and if there is shared congestion > > with other non-p2p users on the same local network, this means the > > performance of others will most likely be worse. Overall, is this > > better or worse? > > > > * If there's transit reduction, equivalent traffic will instead be > > being uploaded from the local network. Again, if the local network > > already has shared congestion upstream (a cable network does), that's > > making it _worse_ both for local p2p & non-p2p users. > > > > > > It costs more (bit for bit) to upgrade access and backhaul than it > > does to upgrade interconnect (there's a considerable economy of > > scale). If someone from a cablecco has told you it's most important > > to reduce transit costs, you'll find they did NOT mean "and at the > > same time please introduce higher backhaul and access costs instead". > > > > See the picture I posted yesterday to this list: > > > > f> > > > > The Internetwork is provided to be used. Let's not assume a > > DISINTERNET is 'better' without being clear what 'better' means. > > > > I've seen no research that uses a full cost-benefit analysis. That's > > hard (e.g. what's the relative value of p2p bits versus non-p2p > > bits). But without such a study, unfortunately, what everyone is > > calling 'better' looks like 'worse' to me on second looks - at least > > for networks with a congested upstream. > > > > On third looks (ie a full study) it might not be worse. But can > > people please enter this debate on the assumption that network > > economics is dangerous in the hands of amateurs (which includes the > > large majority of folks even in telcos/cablecos). > > > > > > Bob > > > > > > > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, > BT Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 > 1473 645196 > > > > > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 17:50: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 5C39C28C376; Thu, 31 Jul 2008 17:50: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 8D3DA28C2B0 for ; Thu, 31 Jul 2008 17:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 odASi8yGmr2P for ; Thu, 31 Jul 2008 17:49:54 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CEB5628C30D for ; Thu, 31 Jul 2008 17:49:53 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 01:50:05 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 01:50:04 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217551676313; Fri, 1 Aug 2008 01:47:56 +0100 Received: from mut.jungle.bt.co.uk ([10.73.64.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m710nWH0032599; Fri, 1 Aug 2008 01:50:02 +0100 Message-Id: <200808010050.m710nWH0032599@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Aug 2008 01:31:59 +0100 To: Ivica Rimac From: Bob Briscoe In-Reply-To: <489237DE.7040406@bell-labs.com> References: <489237DE.7040406@bell-labs.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 01 Aug 2008 00:50:04.0217 (UTC) FILETIME=[891AA290:01C8F370] Cc: p2pi@ietf.org Subject: Re: [p2pi] p2p localization and transit vs. local traffic 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 Ivica, At 23:08 31/07/2008, Ivica Rimac wrote: >Bob, > >but isn't a P2P content network's self-scaling property based on the >assumption that each peer sources as much data as it consumes (at >least in average)? I.e., the total amount of data sourced from peers >sholdn't change Agreed, but... >and even with a pure random peer selection approach (a la BT) peers >have a chance of being selected by other (local or remote) peers as sources. I'm not saying random is good. I'm saying localisation is not good. And there's a better way... >I do not see transit reduction generally implying an increase in >local network traffic other then when the P2P network is running in >surplus mode. Eh? If a sink moves its traffic source from a remote peer to a local one, that's more traffic on the local upstream and less on the remote upstream and less on the interconnect. I'm saying the best allocation is congestion minimisation. Which is significantly different from topological localisation. Some networks have less upstream congestion than others as a result of their design constraints (e.g. DSL vs cable). So using a certain amount of interconnect between the two types is more optimal than localising within one type. But /only/ until congestion 'balances out' to minimum everywhere. A good modern congestion control is good at congestion minimisation (but note that TCP has the 1/RTT artefact that skews matters unlike more modern controls - see my slides). So if you want to judge whether an oracle is performing well, - don't judge how well it localises - judge whether it bootstraps connections in the same pattern that BitTorrent DNA would evolve to - given enough time. This also says the P2P network has the best info to help the oracle, not the individual ISPs which only have topology info and partial congestion info. Bob >-ivica > > >>> >Addressing remark 1: localizing network traffic (based on the >>> p4p >field tests, which used ISP network maps and an "oracle") >>> shows a >strong benefit in transit reduction and in performance >>> improvement, >for networks that are DSL, Cable or FTTH. >>I think my rather important previous point got missed (sorry my >>mail had a lot of points)... >>Neither of these metrics for 'better' impresses me much at all. >>* If performance of p2p is better, and if there is shared >>congestion with other non-p2p users on the same local network, this >>means the performance of others will most likely be worse. Overall, >>is this better or worse? >>* If there's transit reduction, equivalent traffic will instead be >>being uploaded from the local network. Again, if the local network >>already has shared congestion upstream (a cable network does), >>that's making it _worse_ both for local p2p & non-p2p users. >> >>It costs more (bit for bit) to upgrade access and backhaul than it >>does to upgrade interconnect (there's a considerable economy of >>scale). If someone from a cablecco has told you it's most important >>to reduce transit costs, you'll find they did NOT mean "and at the >>same time please introduce higher backhaul and access costs instead". > >-- > Ivica Rimac Bell Labs / Alcatel-Lucent > Email: rimac@bell-labs.com 791 Holmdel-Keyport Road > Phone: +1-732-888-7205 Holmdel, NJ 07733, USA > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jul 31 18:14: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 8DAC928C141; Thu, 31 Jul 2008 18:14: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 7FCFA28C141 for ; Thu, 31 Jul 2008 18:14:05 -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 7TghqEDx7t99 for ; Thu, 31 Jul 2008 18:14:04 -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 7053E3A6A2D for ; Thu, 31 Jul 2008 18:14:04 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KOjDo-0002zJ-Cx; Thu, 31 Jul 2008 18:14:21 -0700 Message-Id: From: Philip Levis To: Bob Briscoe In-Reply-To: <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 1 Aug 2008 02:14:25 +0100 References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com> <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.926) X-Scan-Signature: fff7235990e19ba309b2ccff5b27b3b9 Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Jul 31, 2008, at 6:54 PM, Bob Briscoe wrote: > Laird, > > At 13:45 31/07/2008, Laird Popkin wrote: >> Addressing remark 1: localizing network traffic (based on the p4p >> field tests, which used ISP network maps and an "oracle") shows a >> strong benefit in transit reduction and in performance improvement, >> for networks that are DSL, Cable or FTTH. > > I think my rather important previous point got missed (sorry my mail > had a lot of points)... > > Neither of these metrics for 'better' impresses me much at all. > > * If performance of p2p is better, and if there is shared congestion > with other non-p2p users on the same local network, this means the > performance of others will most likely be worse. Overall, is this > better or worse? > > * If there's transit reduction, equivalent traffic will instead be > being uploaded from the local network. Again, if the local network > already has shared congestion upstream (a cable network does), > that's making it _worse_ both for local p2p & non-p2p users. > > > It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". > > See the picture I posted yesterday to this list: > > > The Internetwork is provided to be used. Let's not assume a > DISINTERNET is 'better' without being clear what 'better' means. > > I've seen no research that uses a full cost-benefit analysis. That's > hard (e.g. what's the relative value of p2p bits versus non-p2p > bits). But without such a study, unfortunately, what everyone is > calling 'better' looks like 'worse' to me on second looks - at least > for networks with a congested upstream. > > On third looks (ie a full study) it might not be worse. But can > people please enter this debate on the assumption that network > economics is dangerous in the hands of amateurs (which includes the > large majority of folks even in telcos/cablecos). Bob, I think you're getting lost in the weeds here. The goal is to define a mechanism by which entities with a greater knowledge of the network can provide guidance to clients on whom those clients might want to communicate with. This guidance could be based on localization, or it could be based on other properties which turn out to be better but we have not discovered yet. The interface proposed, (X,Y,Z) -> (Z), does not assume localization. Doing so would be folly, as it would preclude using the mechanism for applications which are better served by other selection policies. That being said, the points in your slides are interesting. Do you have any real and repeatable experimental evidence that it's "worse?" I'll admit that none of the experimental studies cover every single edge case -- they would then be so voluminous as to be unreadable -- but I'm tempted to trust experimental data collected from real networks over back-of-the-envelope calculations. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 01:06: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 421DD3A6AF6; Fri, 1 Aug 2008 01:06: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 AAE093A6AF6 for ; Fri, 1 Aug 2008 01:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_57=0.6, SARE_LWSHORTT=1.24] 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 Zi2zUySlcIPk for ; Fri, 1 Aug 2008 01:06:28 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id D0E593A68D6 for ; Fri, 1 Aug 2008 01:06:27 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m717tCq1004835; Fri, 1 Aug 2008 09:55:33 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 1 Aug 2008 09:55:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 09:53:59 +0200 Message-ID: <00275A5B436CA441900CB10936742A38DFAD26@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <200807312346.m6VNk432028583@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] DSCP or not Thread-Index: AcjzZ9wvGXJyecCLTyGYLOg5DhcVZgAAO7HA References: <20080731143742.GM10916@cisco.com><9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> <200807312346.m6VNk432028583@bagheera.jungle.bt.co.uk> From: "PAPADIMITRIOU Dimitri" To: "Bob Briscoe" , "Henning Schulzrinne" X-OriginalArrivalTime: 01 Aug 2008 07:55:32.0761 (UTC) FILETIME=[F94D5090:01C8F3AB] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Bob Briscoe > Sent: Friday, August 01, 2008 1:46 AM > To: Henning Schulzrinne > Cc: p2pi@ietf.org; Toerless Eckert > Subject: Re: [p2pi] DSCP or not > > Henning, etc > > Yes, access is the pinch point (and interconnect). > > But your facts aren't quite right on DSL... > The user's own DSL upstream access is certainly a bottleneck (so > you'd just have to buy a home hub that does Diffserv). But there's > absolutely never any congestion on the shared upstream backhaul > (because it's symmetric but fed by the asymmetric access). previous post correctly point that in the upstream direction the bottleneck is on the first mile access link. in the downstream direction and considering a pure distribution tree the (main) bottleneck is on the link toward the aggr. network of the edge router playing the role of NAS (see for inst.) since distribution of traffic can only have a lower granularity down the tree. note: access contains the first mile and the metro-access for aggr. if you consider the figure you made use in your previous pointer you have simplified that aggr. network to a backhaul link. while multiple aggr. nodes may be comprised. note also that these network are progressively becoming more meshy. > However, a combination of file-sharing traffic and provisioning with > contention makes the downstream DSL backhaul of many providers show > persistent loss rates (0-2% peaking at 3% somtimes) throughout the > 'day' (08:00-24:00 ish). To add Diffserv would require configing it > in the downstream queues of the remote access server (BRAS). > > Regarding vendor support for Diffserv on BRASs, many support it, but > most vendors offer fairly limited numbers of queues and you may find > all the queues are already used for other scheduling stuff the > provider has already put in (weighted fair queueing between ISPs > sharing the BRAS, video services, VoIP etc). what do you call a "fairly limited" number of queues ? per subscriber and per traffic class queuing are available on such devices. access nodes can also provide for the same capability (using e.g. VLAN per subscriber). the main point will be to consider a representative baseline scenario for this type of exercise. > IOW, there's already a > lot of scheduling stuff done in access networks - much of it is > Diffserv-based - ie driven by internally generated DSCPs - but much > is just nailed up by the provider config locally on the link > in question. The key question is what will be the boundary of the DS domain and whether we will see or not (re-)classification and re-marking at the AN even when the CPE is performing the job. if this is the case then which MF classification should be used. > BT have been drawing up plans for a scavenger class on the most > congested links I mention above for the last few months, but that's > not an official customer promise or anything. Just internal design > work that may get taken up as a product, or may not. Initially it's > unlikely to have a customer-controlled interface. > > On backbones, it's an absolute certainty that any DSCP set for one > network would currently be cleared by the next. > > There's been pre-standards inter-provider DS activity around VPNs for > some time much of which could be re-used for scavenger. Dave Clark > pulled it together to try to bridge the impasse that DS had got to. > Bruce Davie was the co-chair of the w-g. The idea was to put it all > in this white paper: > > then go off and put the different parts into the appropriate > standards bodies. This has been happeneing (e.g. inter-provider SLA > metrics in the ITU etc). > > Here's my brief 3pp comparison of the issues between doing scavenger > in the host and in the network, that I mentioned this afternoon: > "Solving this traffic management problem... and the next, and > the next" > > > The main issue for DS is of course the interface with hosts. But also > that networks have to add policing to BE once BE is better than > something else. But everyone's guessing when they work out how to do > this, because they can't use traditional Diffserv token bucket > policing for residential customers - the traffic isn't aggregated > enough. So it's all volume limits and arbitrary stuff being > bandied about. the exact reason why you have an aggregation network in between. now this does not prevent the use of DS at these boundaries. > However, I've also tried to show that it's not all downhill for > host-based scavenger either, tho I think it has more chance of > getting there first (in a sense it already has with DNA) but I > predict issues we haven't seen yet, which is why TANA is right to at > least aim to document the issue as a whole. i agree but the assumption made when documenting these issues shall be representative - caricaturing and limiting capabilities of access networks as they used to be, would not be of any help. -d. > Does anyone know what the status of the background service is in > 3GPP? It's been in the specs along with EF, AF & BE for some time > (see ref in my p2pi position paper above). > > > > Bob > > At 18:05 31/07/2008, David R Oran wrote: > > >On Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote: > > > >>I don't think we need to wait until a DiffServ/scavenger service is > >>supported across the backbone. Most of the problems are in the > >>access networks (both within a residence and in the first mile), > >>where deploying DiffServ seems much more realistic. The backbone > >>network should presumably leave the DSCP alone in transit, but even > >>that isn't all that important, since the important link limit in > >>both cable and DSL is the uplink. I don't know if and how DOCSIS can > >>manage transmission slots on the uplink based on DiffServ, however. > >Yes. > > > >>Henning > >> > >>On Jul 31, 2008, at 10:37 AM, Toerless Eckert wrote: > >> > >>> > >>>Seems to me as if the best long term solution would be to utilize a > >>>scavenger > >>>DSCP class in the network. For such a class i think the existing > >>>flow control mechanisms as eg: in TCP may not be suited best to > >>>exhaust > >>>the available bandwidth - as it likely fluctuates more > frequently and > >>>short term than in best effort. SSo some form of agressive > >>>transmission with > >>>effecient retransmission (and maybe FEC) is probably best > when using > >>>such a scavenger clas. > >>> > >>>Practically speaking, it will be a long time for most core networks > >>>to support such a clss, specifically because of the > limited number of > >>>exp bits in MPLS, inertia, technical problems, and so on. So now > >>>we need the algorithm to handle scavenger traffic in the best > >>>effort class, > >>>that very carefully tries not to cause any congestion and > in face of > >>>congestion throttles itself back to zero or close to it. > >>> > >>>If we could bring together those two algorithms together, and the > >>>algorithm for a connection would be selected based on whether or > >>>not the ntework > >>>resets the scavenger DSCP class to best effort (because there is no > >>>scavenger class > >>>configured) ... then i think this would be a good short and long > >>>term solution. > >>> > >>>Cheers > >>> Toerless > >>>_______________________________________________ > >>>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 > > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ > 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 Aug 1 01:32: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 BD5F028C330; Fri, 1 Aug 2008 01:32: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 F3E7528C2E2 for ; Fri, 1 Aug 2008 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 VJWaWKL4xoMn for ; Fri, 1 Aug 2008 01:32:54 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C12BF28C18C for ; Fri, 1 Aug 2008 01:32:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D96E2E10AA6; Fri, 1 Aug 2008 04:32: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 26dsnbnQkyjA; Fri, 1 Aug 2008 04:31:55 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 894C0E10AB4; Fri, 1 Aug 2008 04:31:55 -0400 (EDT) Date: Fri, 1 Aug 2008 04:31:55 -0400 (EDT) From: Laird Popkin To: Philip Levis Message-ID: <826442146.93941217579515505.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [86.47.44.252] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 add a little field test data, so far we've not seen any cases where traffic localization increased "last mile" uplink consumption. When traffic isn't localized, an ISP's customers are uploading to the general internet. When traffic is localized, an ISP's customers upload about the same volume, but the destination of the upload shifts from external to internal destinations. This happens in part because the ISP's customers connect to each other, and in part because the external users connect to each other instead of connecting into the ISP. The result is that the consumption of the "last mile" doesn't change, but the consumption of internal and external links drops. You're right that a cost analysis is complex, since it varies dramatically between ISPs (and is subject to debate within ISPs). That's why I'd rather talk about resource consumption (e.g. data volumes, link utilization). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Philip Levis" To: "Bob Briscoe" Cc: "Laird Popkin" , p2pi@ietf.org Sent: 01 August 2008 02:14:25 o'clock (GMT) Europe/London Subject: Re: [p2pi] why I didn't hum yes (yet) On Jul 31, 2008, at 6:54 PM, Bob Briscoe wrote: > Laird, > > At 13:45 31/07/2008, Laird Popkin wrote: >> Addressing remark 1: localizing network traffic (based on the p4p >> field tests, which used ISP network maps and an "oracle") shows a >> strong benefit in transit reduction and in performance improvement, >> for networks that are DSL, Cable or FTTH. > > I think my rather important previous point got missed (sorry my mail > had a lot of points)... > > Neither of these metrics for 'better' impresses me much at all. > > * If performance of p2p is better, and if there is shared congestion > with other non-p2p users on the same local network, this means the > performance of others will most likely be worse. Overall, is this > better or worse? > > * If there's transit reduction, equivalent traffic will instead be > being uploaded from the local network. Again, if the local network > already has shared congestion upstream (a cable network does), > that's making it _worse_ both for local p2p & non-p2p users. > > > It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". > > See the picture I posted yesterday to this list: > > > The Internetwork is provided to be used. Let's not assume a > DISINTERNET is 'better' without being clear what 'better' means. > > I've seen no research that uses a full cost-benefit analysis. That's > hard (e.g. what's the relative value of p2p bits versus non-p2p > bits). But without such a study, unfortunately, what everyone is > calling 'better' looks like 'worse' to me on second looks - at least > for networks with a congested upstream. > > On third looks (ie a full study) it might not be worse. But can > people please enter this debate on the assumption that network > economics is dangerous in the hands of amateurs (which includes the > large majority of folks even in telcos/cablecos). Bob, I think you're getting lost in the weeds here. The goal is to define a mechanism by which entities with a greater knowledge of the network can provide guidance to clients on whom those clients might want to communicate with. This guidance could be based on localization, or it could be based on other properties which turn out to be better but we have not discovered yet. The interface proposed, (X,Y,Z) -> (Z), does not assume localization. Doing so would be folly, as it would preclude using the mechanism for applications which are better served by other selection policies. That being said, the points in your slides are interesting. Do you have any real and repeatable experimental evidence that it's "worse?" I'll admit that none of the experimental studies cover every single edge case -- they would then be so voluminous as to be unreadable -- but I'm tempted to trust experimental data collected from real networks over back-of-the-envelope calculations. Phil _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 01:35: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 2376D28C115; Fri, 1 Aug 2008 01:35: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 B20DF28C18C for ; Fri, 1 Aug 2008 01:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_57=0.6, SARE_LWSHORTT=1.24] 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 GPxyTKE+5XdJ for ; Fri, 1 Aug 2008 01:35:53 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 50D6F3A67F7 for ; Fri, 1 Aug 2008 01:35:53 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9851305; Fri, 01 Aug 2008 04:34:55 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 04:34:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 04:28:31 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F601940661@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] DSCP or not Thread-Index: AcjzZ7sJ5wHdbKktSaGM81ij2wBSkAASNmt9 References: <20080731143742.GM10916@cisco.com><9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> <200807312346.m6VNk432028583@bagheera.jungle.bt.co.uk> From: "Woundy, Richard" To: "Bob Briscoe" , "Henning Schulzrinne" X-OriginalArrivalTime: 01 Aug 2008 08:34:54.0676 (UTC) FILETIME=[791CF140:01C8F3B1] Cc: Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 We haven't given up on the scavenger class either, although obviously our technical challenges are different than Bob's. :) ________________________________ From: p2pi-bounces@ietf.org on behalf of Bob Briscoe Sent: Thu 7/31/2008 7:46 PM To: Henning Schulzrinne Cc: p2pi@ietf.org; Toerless Eckert Subject: Re: [p2pi] DSCP or not Henning, etc Yes, access is the pinch point (and interconnect). But your facts aren't quite right on DSL... The user's own DSL upstream access is certainly a bottleneck (so you'd just have to buy a home hub that does Diffserv). But there's absolutely never any congestion on the shared upstream backhaul (because it's symmetric but fed by the asymmetric access). However, a combination of file-sharing traffic and provisioning with contention makes the downstream DSL backhaul of many providers show persistent loss rates (0-2% peaking at 3% somtimes) throughout the 'day' (08:00-24:00 ish). To add Diffserv would require configing it in the downstream queues of the remote access server (BRAS). Regarding vendor support for Diffserv on BRASs, many support it, but most vendors offer fairly limited numbers of queues and you may find all the queues are already used for other scheduling stuff the provider has already put in (weighted fair queueing between ISPs sharing the BRAS, video services, VoIP etc). IOW, there's already a lot of scheduling stuff done in access networks - much of it is Diffserv-based - ie driven by internally generated DSCPs - but much is just nailed up by the provider config locally on the link in question. BT have been drawing up plans for a scavenger class on the most congested links I mention above for the last few months, but that's not an official customer promise or anything. Just internal design work that may get taken up as a product, or may not. Initially it's unlikely to have a customer-controlled interface. On backbones, it's an absolute certainty that any DSCP set for one network would currently be cleared by the next. There's been pre-standards inter-provider DS activity around VPNs for some time much of which could be re-used for scavenger. Dave Clark pulled it together to try to bridge the impasse that DS had got to. Bruce Davie was the co-chair of the w-g. The idea was to put it all in this white paper: then go off and put the different parts into the appropriate standards bodies. This has been happeneing (e.g. inter-provider SLA metrics in the ITU etc). Here's my brief 3pp comparison of the issues between doing scavenger in the host and in the network, that I mentioned this afternoon: "Solving this traffic management problem... and the next, and the next" The main issue for DS is of course the interface with hosts. But also that networks have to add policing to BE once BE is better than something else. But everyone's guessing when they work out how to do this, because they can't use traditional Diffserv token bucket policing for residential customers - the traffic isn't aggregated enough. So it's all volume limits and arbitrary stuff being bandied about. However, I've also tried to show that it's not all downhill for host-based scavenger either, tho I think it has more chance of getting there first (in a sense it already has with DNA) but I predict issues we haven't seen yet, which is why TANA is right to at least aim to document the issue as a whole. Does anyone know what the status of the background service is in 3GPP? It's been in the specs along with EF, AF & BE for some time (see ref in my p2pi position paper above). Bob At 18:05 31/07/2008, David R Oran wrote: >On Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote: > >>I don't think we need to wait until a DiffServ/scavenger service is >>supported across the backbone. Most of the problems are in the >>access networks (both within a residence and in the first mile), >>where deploying DiffServ seems much more realistic. The backbone >>network should presumably leave the DSCP alone in transit, but even >>that isn't all that important, since the important link limit in >>both cable and DSL is the uplink. I don't know if and how DOCSIS can >>manage transmission slots on the uplink based on DiffServ, however. >Yes. > >>Henning >> >>On Jul 31, 2008, at 10:37 AM, Toerless Eckert wrote: >> >>> >>>Seems to me as if the best long term solution would be to utilize a >>>scavenger >>>DSCP class in the network. For such a class i think the existing >>>flow control mechanisms as eg: in TCP may not be suited best to >>>exhaust >>>the available bandwidth - as it likely fluctuates more frequently and >>>short term than in best effort. SSo some form of agressive >>>transmission with >>>effecient retransmission (and maybe FEC) is probably best when using >>>such a scavenger clas. >>> >>>Practically speaking, it will be a long time for most core networks >>>to support such a clss, specifically because of the limited number of >>>exp bits in MPLS, inertia, technical problems, and so on. So now >>>we need the algorithm to handle scavenger traffic in the best >>>effort class, >>>that very carefully tries not to cause any congestion and in face of >>>congestion throttles itself back to zero or close to it. >>> >>>If we could bring together those two algorithms together, and the >>>algorithm for a connection would be selected based on whether or >>>not the ntework >>>resets the scavenger DSCP class to best effort (because there is no >>>scavenger class >>>configured) ... then i think this would be a good short and long >>>term solution. >>> >>>Cheers >>> Toerless >>>_______________________________________________ >>>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 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ 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 Aug 1 01:35: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 531BA28C2AB; Fri, 1 Aug 2008 01:35: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 28B3A3A67F7 for ; Fri, 1 Aug 2008 01:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_57=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 0Z5v6lLm1xoz for ; Fri, 1 Aug 2008 01:35:54 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id ED66728C115 for ; Fri, 1 Aug 2008 01:35:53 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9851307; Fri, 01 Aug 2008 04:34:55 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 04:34:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 04:25:26 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why I didn't hum yes (yet) Thread-Index: AcjzNph27JruTJu1TMCJF9j0ZK+FLAAc1ztS References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com><1959788251.90461217508317275.JavaMail.root@dkny.pando.com> <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> From: "Woundy, Richard" To: "Bob Briscoe" , "Laird Popkin" X-OriginalArrivalTime: 01 Aug 2008 08:34:55.0317 (UTC) FILETIME=[797EC050:01C8F3B1] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) 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 Bob, I feel compelled to respond to some of your points. At Comcast, we studied the P4P results from Verizon earlier this year, before we committed to a trial this summer. There were three items of interest from those results: 1. Faster downloads for P2P users 2. Reduced backbone transit traffic for the ISP 3. * The same aggregate amount of uploading by ISP customers We're not ready to reveal the results of our own recently-concluded P4P trial, but suffice it to say that we are seeing similar results. I suspect the reason behind point #3 is that P2P uploads within the ISP displace the P2P uploads outside the ISP. And the reason behind point #2 may be that there are fewer outside factors (e.g. multiple transit backbones) that could cause congestion. We need to perform more analysis before we can conclude that ISP localization doesn't increase upstream traffic, but at least on average it does not increase upstream traffic. If it turns out that P4P localization is cost-neutral on an access basis, then that would be a critical item to retain for ALTO. BTW, I agree with many of your other comments. For example, I agree that minimizing RTT for P2P connections isn't all that critical. For example, I've heard that clever P2P users are often motivated (where possible) to select peers in Japan and Korea, because higher upload throughput trumps RTT every time. >It costs more (bit for bit) to upgrade access and backhaul than it does to upgrade interconnect (there's a considerable economy of scale). If someone from a cablecco has told you it's most important to reduce transit costs, you'll find they did NOT mean "and at the same time please introduce higher backhaul and access costs instead". I've been talking to Laird, and I seem to be from a 'cableco', so maybe you're referring to me. (And maybe I'm one of the amateurs as well.) :^/ But I am pretty sure I have been consistent on this point, from the P2PI Workshop to the ALTO BOF to other private conversations -- our broadband access costs are much higher than our backbone / transit costs. As my boss would say, "backhoe costs don't follow Moore's Law". For Comcast, minimizing transit costs is nice but not the fundamental concern. BTW, I have heard that for other ISPs, transit costs *are* a fundamental issue. And not just in the so-called "third world". -- Rich Laird, At 13:45 31/07/2008, Laird Popkin wrote: >Addressing remark 1: localizing network traffic (based on the p4p >field tests, which used ISP network maps and an "oracle") shows a >strong benefit in transit reduction and in performance improvement, >for networks that are DSL, Cable or FTTH. I think my rather important previous point got missed (sorry my mail had a lot of points)... Neither of these metrics for 'better' impresses me much at all. * If performance of p2p is better, and if there is shared congestion with other non-p2p users on the same local network, this means the performance of others will most likely be worse. Overall, is this better or worse? * If there's transit reduction, equivalent traffic will instead be being uploaded from the local network. Again, if the local network already has shared congestion upstream (a cable network does), that's making it _worse_ both for local p2p & non-p2p users. It costs more (bit for bit) to upgrade access and backhaul than it does to upgrade interconnect (there's a considerable economy of scale). If someone from a cablecco has told you it's most important to reduce transit costs, you'll find they did NOT mean "and at the same time please introduce higher backhaul and access costs instead". See the picture I posted yesterday to this list: The Internetwork is provided to be used. Let's not assume a DISINTERNET is 'better' without being clear what 'better' means. I've seen no research that uses a full cost-benefit analysis. That's hard (e.g. what's the relative value of p2p bits versus non-p2p bits). But without such a study, unfortunately, what everyone is calling 'better' looks like 'worse' to me on second looks - at least for networks with a congested upstream. On third looks (ie a full study) it might not be worse. But can people please enter this debate on the assumption that network economics is dangerous in the hands of amateurs (which includes the large majority of folks even in telcos/cablecos). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ 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 Aug 1 01: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 AF6553A6A7C; Fri, 1 Aug 2008 01: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 735E43A6A7C for ; Fri, 1 Aug 2008 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.927 X-Spam-Level: X-Spam-Status: No, score=-9.927 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_57=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 kAQCnAOrJh5O for ; Fri, 1 Aug 2008 01:42:58 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 3D5DA3A6768 for ; Fri, 1 Aug 2008 01:42:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id E561DE10A80; Fri, 1 Aug 2008 04:42:45 -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 zIDN3QGCRRU7; Fri, 1 Aug 2008 04:42:34 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 8913DE10A14; Fri, 1 Aug 2008 04:42:34 -0400 (EDT) Date: Fri, 1 Aug 2008 04:42:34 -0400 (EDT) From: Laird Popkin To: Bob Briscoe Message-ID: <574573834.93971217580154524.JavaMail.root@dkny.pando.com> In-Reply-To: <200808010050.m710nWH0032599@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 X-Originating-IP: [86.47.44.252] Cc: Ivica Rimac , p2pi@ietf.org Subject: Re: [p2pi] p2p localization and transit vs. local traffic 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 Field test data does not support the assertion that "If a sink moves its traffic source from a remote peer to a local one, that's more traffic on the local upstream and less on the remote upstream and less on the interconnect." I think that you're thinking only about internal data transfer, and forgetting that the users are currently uploading not only to other customers of the same ISP (2% of the time, on average), but also (98% of the time, on average) to users on the rest of the internet. While there's a alrge increase in local upstream uploading to other customers of the same ISP, there's a cooresponding drop in local upstream uploading to the general internet. So far in field testing the two effects balance each other out, so total uplink consumption doesn't change much. Regarding "This also says the P2P network has the best info to help the oracle, not the individual ISPs which only have topology info and partial congestion info." I would modify this to say that neither the p2p network nor the ISP have sufficient information in isolation to make the best peer assignment selections. So (IMO, of course) the ISP should provide information to the p2p network that, in combination with what the p2p network knows, allows it to make better peer assignment selections. Specifically, the p2p network knows a lot about peer network profile (e.g. firewalled, current utilization) and the ISP knows about network topology, and by working together the two can make much better choices than either by themselves. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Bob Briscoe" To: "Ivica Rimac" Cc: p2pi@ietf.org Sent: 01 August 2008 01:31:59 o'clock (GMT) Europe/London Subject: Re: [p2pi] p2p localization and transit vs. local traffic Ivica, At 23:08 31/07/2008, Ivica Rimac wrote: >Bob, > >but isn't a P2P content network's self-scaling property based on the >assumption that each peer sources as much data as it consumes (at >least in average)? I.e., the total amount of data sourced from peers >sholdn't change Agreed, but... >and even with a pure random peer selection approach (a la BT) peers >have a chance of being selected by other (local or remote) peers as sources. I'm not saying random is good. I'm saying localisation is not good. And there's a better way... >I do not see transit reduction generally implying an increase in >local network traffic other then when the P2P network is running in >surplus mode. Eh? If a sink moves its traffic source from a remote peer to a local one, that's more traffic on the local upstream and less on the remote upstream and less on the interconnect. I'm saying the best allocation is congestion minimisation. Which is significantly different from topological localisation. Some networks have less upstream congestion than others as a result of their design constraints (e.g. DSL vs cable). So using a certain amount of interconnect between the two types is more optimal than localising within one type. But /only/ until congestion 'balances out' to minimum everywhere. A good modern congestion control is good at congestion minimisation (but note that TCP has the 1/RTT artefact that skews matters unlike more modern controls - see my slides). So if you want to judge whether an oracle is performing well, - don't judge how well it localises - judge whether it bootstraps connections in the same pattern that BitTorrent DNA would evolve to - given enough time. This also says the P2P network has the best info to help the oracle, not the individual ISPs which only have topology info and partial congestion info. Bob >-ivica > > >>> >Addressing remark 1: localizing network traffic (based on the >>> p4p >field tests, which used ISP network maps and an "oracle") >>> shows a >strong benefit in transit reduction and in performance >>> improvement, >for networks that are DSL, Cable or FTTH. >>I think my rather important previous point got missed (sorry my >>mail had a lot of points)... >>Neither of these metrics for 'better' impresses me much at all. >>* If performance of p2p is better, and if there is shared >>congestion with other non-p2p users on the same local network, this >>means the performance of others will most likely be worse. Overall, >>is this better or worse? >>* If there's transit reduction, equivalent traffic will instead be >>being uploaded from the local network. Again, if the local network >>already has shared congestion upstream (a cable network does), >>that's making it _worse_ both for local p2p & non-p2p users. >> >>It costs more (bit for bit) to upgrade access and backhaul than it >>does to upgrade interconnect (there's a considerable economy of >>scale). If someone from a cablecco has told you it's most important >>to reduce transit costs, you'll find they did NOT mean "and at the >>same time please introduce higher backhaul and access costs instead". > >-- > Ivica Rimac Bell Labs / Alcatel-Lucent > Email: rimac@bell-labs.com 791 Holmdel-Keyport Road > Phone: +1-732-888-7205 Holmdel, NJ 07733, USA > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ 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 Aug 1 01:49: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 255B228C3A5; Fri, 1 Aug 2008 01:49: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 5665E3A6C31 for ; Thu, 31 Jul 2008 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 dvenxyVul4Ep for ; Thu, 31 Jul 2008 10:14:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8F25B3A6892 for ; Thu, 31 Jul 2008 10:14:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="71008520" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2008 17:14:15 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VHEEci009688; Thu, 31 Jul 2008 10:14:14 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VHEE69015717; Thu, 31 Jul 2008 17:14:14 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA27455; Thu, 31 Jul 2008 10:10:53 -0700 (PDT) Date: Thu, 31 Jul 2008 10:10:53 -0700 From: ext Toerless Eckert To: Lars Eggert Message-ID: <20080731171053.GB10916@cisco.com> References: <20080731143742.GM10916@cisco.com> <3C4E554A-1543-41BD-B1B4-C9D3E5B37EA5@nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <3C4E554A-1543-41BD-B1B4-C9D3E5B37EA5@nokia.com> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1016; t=1217524454; x=1218388454; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20ext=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[p2pi]=20DSCP=20or=20not |Sender:=20; bh=NaaQM96rMCsjr5iEGsGO0EfjFEm3QPX8ujE+FxrjHCE=; b=ozqibWT62SQB4EzD0qUOnE8KCmjP5+KO3oma5TgW9Iw2OKkEm9aeeWKc3J SVSHQskoaKHOOqpEV4WfWJlw6vYgtQMW6tb+ycO9gE0vcZphIIOYiglsfPzp lHTkUGurI7V9gkQ3jSMHvfj6sNPrByyBEQ5FRiVbQ/LYIlXtv5bwo=; Authentication-Results: sj-dkim-1; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Fri, 01 Aug 2008 01:49:14 -0700 Cc: p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 Thu, Jul 31, 2008 at 06:02:30PM +0100, Lars Eggert wrote: > On 2008-7-31, at 15:37, ext Toerless Eckert wrote: > > RFC3662 was published five years ago. Even assuming slow adoption, we > should have heard from some operators that use it by now. I'm not > aware of any deployment. > > I agree that universal deployment of DiffServ scavenger service would > be the better solution, but it looks unlikely it will happen. A > transport-level solution that approximates what the DiffServ solution > would give us, but with a different (better?) incentive angle, seems > attractive. It's all a matter of market driver. DiffServ was added to networks for voice. The more successfull the workaround (in single DSCP class) is for preprovisioning/download traffic (p2p or not), the less pressure is there to adopt a real DSCP solution. But as long as nobody can prove the workaround can work as well as real DSCP separation, it logically should not be the IETF standards solution, right ? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 01:49: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 4EEAE28C3CE; Fri, 1 Aug 2008 01:49: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 A62D928C261 for ; Thu, 31 Jul 2008 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.317, 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 H0No0EtoMxYX for ; Thu, 31 Jul 2008 11:25:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A72F428C273 for ; Thu, 31 Jul 2008 11:25:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="134097674" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2008 18:24:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6VIOXIY023182; Thu, 31 Jul 2008 11:24:33 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VIOX5c005994; Thu, 31 Jul 2008 18:24:33 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA12400; Thu, 31 Jul 2008 11:21:12 -0700 (PDT) Date: Thu, 31 Jul 2008 11:21:11 -0700 From: Toerless Eckert To: David R Oran Message-ID: <20080731182111.GG10916@cisco.com> References: <20080731143742.GM10916@cisco.com> <00275A5B436CA441900CB10936742A38DFAC8D@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=986; t=1217528673; x=1218392673; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[p2pi]=20DSCP=20or=20not |Sender:=20; bh=BCxfgJnps9z1D7j7GbSXb4xL/M8nFqr7tv0+HE5O6DI=; b=oNaPTlr9S1fETRylMZyWcYl6IxdUHW3vQM9ov8NosJCXRu4p71QEktLUVw vTf5k2w9gndUdASNSzLslMUuHbd301F6PeLdKaeQYIDQSk8oAPb4I+G3pXJN IlUTeXWgKm; Authentication-Results: sj-dkim-3; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Mailman-Approved-At: Fri, 01 Aug 2008 01:49:14 -0700 Cc: p2pi@ietf.org, PAPADIMITRIOU Dimitri Subject: Re: [p2pi] DSCP or not 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 Thu, Jul 31, 2008 at 02:06:48PM -0400, David R Oran wrote: > I think we can exploit both a scavenger DSCP and different congestion > control in the endpoint as long as the the interaction between the two > is understood and the combination works as well or better than either > alone. That allows incremental deployment to have a decent utility > function, and incidentally may allow better instrumentation by making > visible the usage of the changed congestion control in the positions > of the network that don't over-write non BE dscps. Right. The first thing to validate is the presumption that a conservative algorithm for p2p within the best-effort class would not leverage spare bandwidth as good as a more aggressive scavenger algorithm can in the presence of a real scavenger dscp class. If we can easily show this, then the dual-approach i think is justified. If we can't then a scavenger dscp class is not justified. Cheers Toerless _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 01:49: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 7401F28C3DA; Fri, 1 Aug 2008 01:49: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 08A353A6D1C for ; Thu, 31 Jul 2008 12:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 adkdxj1vLNxS for ; Thu, 31 Jul 2008 12:36:12 -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 308D23A6D2F for ; Thu, 31 Jul 2008 12:36:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="60088816" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 19:36:24 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6VJaN1i032712; Thu, 31 Jul 2008 12:36:23 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VJaNOe008827; Thu, 31 Jul 2008 19:36:23 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26872; Thu, 31 Jul 2008 12:33:02 -0700 (PDT) Date: Thu, 31 Jul 2008 12:33:02 -0700 From: Toerless Eckert To: David R Oran Message-ID: <20080731193302.GT10916@cisco.com> References: <20080731143742.GM10916@cisco.com> <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1248; t=1217532983; x=1218396983; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[p2pi]=20DSCP=20or=20not |Sender:=20; bh=XnRXray0QIkB+AtuayXe+4bnwL55ZpGAG56FIAwzcMI=; b=K6ZbgOTnJ6OmHygzMbTI5Q94WZn1IGPc5Aj/yUBgZkyo3MadBCvI1yF9rN Qug0+e3GSjpGfzdWuUn1L73gdjmRT8O4uOTIJiX0fViFvxBn5YP6xdB9U+Qc uFqS4NGDNw; Authentication-Results: sj-dkim-2; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Fri, 01 Aug 2008 01:49:14 -0700 Cc: p2pi@ietf.org Subject: Re: [p2pi] DSCP or not 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 Thu, Jul 31, 2008 at 01:05:38PM -0400, David R Oran wrote: > > On Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote: > > >I don't think we need to wait until a DiffServ/scavenger service is > >supported across the backbone. Most of the problems are in the > >access networks (both within a residence and in the first mile), > >where deploying DiffServ seems much more realistic. The backbone > >network should presumably leave the DSCP alone in transit, but even > >that isn't all that important, since the important link limit in > >both cable and DSL is the uplink. I don't know if and how DOCSIS can > >manage transmission slots on the uplink based on DiffServ, however. > > > Yes. The upstream scheduler on the CMTS schedules packets on the upstream from multiple CMs. This is not a DSCP aware process. On the CM you can in the upstream direction to DSCP to queue mapping like eg: on any router, based on DSCP, etc.., but this does not interact with the upstreams cheduler. If you set up docsis service flows then these will impact the total amount of bandwidth the particular CM gets from the scheduler, But to me those service flows are really more like intserv (per flow admission control). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 01:49: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 9B5F728C3E0; Fri, 1 Aug 2008 01:49: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 57A0028C21A for ; Thu, 31 Jul 2008 15:12:21 -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 vXx8fyLZXSiw for ; Thu, 31 Jul 2008 15:12:20 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 66C4328C2D2 for ; Thu, 31 Jul 2008 15:12:20 -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 m6VMCb0N016871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 17:12:37 -0500 (CDT) Received: from [135.112.131.40] (tesla.mh.lucent.com [135.112.131.40]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6VMCVI6001185; Thu, 31 Jul 2008 17:12:31 -0500 (CDT) Message-ID: <489237DE.7040406@bell-labs.com> Date: Thu, 31 Jul 2008 18:08:30 -0400 From: Ivica Rimac User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: rbriscoe@jungle.bt.co.uk X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Fri, 01 Aug 2008 01:49:14 -0700 Cc: p2pi@ietf.org Subject: [p2pi] p2p localization and transit vs. local traffic 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="===============1713377603==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1713377603== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060608090509080909040508" This is a cryptographically signed message in MIME format. --------------ms060608090509080909040508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bob, but isn't a P2P content network's self-scaling property based on the assumption that each peer sources as much data as it consumes (at least in average)? I.e., the total amount of data sourced from peers sholdn't change and even with a pure random peer selection approach (a la BT) peers have a chance of being selected by other (local or remote) peers as sources. I do not see transit reduction generally implying an increase in local network traffic other then when the P2P network is running in surplus mode. -ivica >> >Addressing remark 1: localizing network traffic (based on the p4p >> >field tests, which used ISP network maps and an "oracle") shows a >> >strong benefit in transit reduction and in performance improvement, >> >for networks that are DSL, Cable or FTTH. > > I think my rather important previous point got missed (sorry my mail > had a lot of points)... > > Neither of these metrics for 'better' impresses me much at all. > > * If performance of p2p is better, and if there is shared congestion > with other non-p2p users on the same local network, this means the > performance of others will most likely be worse. Overall, is this > better or worse? > > * If there's transit reduction, equivalent traffic will instead be > being uploaded from the local network. Again, if the local network > already has shared congestion upstream (a cable network does), that's > making it _worse_ both for local p2p & non-p2p users. > > > It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". -- Ivica Rimac Bell Labs / Alcatel-Lucent Email: rimac@bell-labs.com 791 Holmdel-Keyport Road Phone: +1-732-888-7205 Holmdel, NJ 07733, USA --------------ms060608090509080909040508 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNXMIICwKADAgECAhAQgaiUhTUxC0zp5nyjsjOS MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wODAzMDkxNzU5MjBaFw0wOTAzMDkxNzU5MjBaMIGPMR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNyaW1hY0BiZWxsLWxhYnMu Y29tMR8wHQYJKoZIhvcNAQkBFhByaW1hY0BsdWNlbnQuY29tMScwJQYJKoZIhvcNAQkBFhhy aW1hY0BhbGNhdGVsLWx1Y2VudC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDK7JPL2Qzl+mOdWV/LSSIitjU729alrdXFqj3JFJyD08V+89YfcBshgJcFCZrR/CR8CoRV HlpTPSxk/3M61L1b0S2TPQL6Joo5L9qkZWvi6Rp7E5f52aMH72uCE0XOmB+20uCKMOAow++1 Wwu8zad82i5EQnY+kf55z/PhUMXgJfjaTgyWeBZLgj0w3KjH+h1ejXCscBuowAryO4WVIssZ GCegeXn5fVRbkHQseRtZ9PG6MNaRX4gHmmJGkDDux41ygFFSBwAsQxquRvV3yJfJ9Raz4rcG /vnXe4e85W6fmWhH91oOQeHrFSkhtO1FeaXJMO+3kIUsdxy+/FAlvMTfAgMBAAGjXDBaMEoG A1UdEQRDMEGBE3JpbWFjQGJlbGwtbGFicy5jb22BEHJpbWFjQGx1Y2VudC5jb22BGHJpbWFj QGFsY2F0ZWwtbHVjZW50LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAGBx /tov0qmTYSCpEkEJTR4K9pN1CHuMc4bB6jHtn2ErJGd4v2tfCseXuL94sx3KZ9A3QiRZCwjP 0siZP52vqJFoUszeWkukLx5Kqvm0kvMHxwaA/ehIw/XUk9RGIDvi242/QPWJV9qej+evud21 SKJ7oAlEiGH660Sbhx808KmsMIIDVzCCAsCgAwIBAgIQEIGolIU1MQtM6eZ8o7IzkjANBgkq hkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0EwHhcNMDgwMzA5MTc1OTIwWhcNMDkwMzA5MTc1OTIwWjCBjzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcmltYWNAYmVsbC1sYWJzLmNvbTEf MB0GCSqGSIb3DQEJARYQcmltYWNAbHVjZW50LmNvbTEnMCUGCSqGSIb3DQEJARYYcmltYWNA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyuyT y9kM5fpjnVlfy0kiIrY1O9vWpa3Vxao9yRScg9PFfvPWH3AbIYCXBQma0fwkfAqEVR5aUz0s ZP9zOtS9W9Etkz0C+iaKOS/apGVr4ukaexOX+dmjB+9rghNFzpgfttLgijDgKMPvtVsLvM2n fNouREJ2PpH+ec/z4VDF4CX42k4MlngWS4I9MNyox/odXo1wrHAbqMAK8juFlSLLGRgnoHl5 +X1UW5B0LHkbWfTxujDWkV+IB5piRpAw7seNcoBRUgcALEMarkb1d8iXyfUWs+K3Bv7513uH vOVun5loR/daDkHh6xUpIbTtRXmlyTDvt5CFLHccvvxQJbzE3wIDAQABo1wwWjBKBgNVHREE QzBBgRNyaW1hY0BiZWxsLWxhYnMuY29tgRByaW1hY0BsdWNlbnQuY29tgRhyaW1hY0BhbGNh dGVsLWx1Y2VudC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBgcf7aL9Kp k2EgqRJBCU0eCvaTdQh7jHOGweox7Z9hKyRneL9rXwrHl7i/eLMdymfQN0IkWQsIz9LImT+d r6iRaFLM3lpLpC8eSqr5tJLzB8cGgP3oSMP11JPURiA74tuNv0D1iVfano/nr7ndtUiie6AJ RIhh+utEm4cfNPCprDGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhAQgaiUhTUxC0zp5nyjsjOSMAkGBSsOAwIaBQCgggHDMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDczMTIyMDgzMFow IwYJKoZIhvcNAQkEMRYEFBc3mNdXCaVRsn3/nKfpF3I8OrOsMFIGCSqGSIb3DQEJDzFFMEMw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEIGolIU1MQtM6eZ8o7IzkjCBhwYLKoZIhvcNAQkQ AgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ EIGolIU1MQtM6eZ8o7IzkjANBgkqhkiG9w0BAQEFAASCAQCOCKcKRutK/8RXCHGxmDCZo+/O aOeXdz18T07lNHc3WIMf/zP25D7nv3cFaVmGDT61jOlNmzx1mSWzbsBtPaRcWJmDbES3Aaxn 7tZo2pgRp3SXzegoF+HL65e+//RtJ2W6RfBQy9pzNtxoy9i5T6PJzGCDTGVQeAtSwna5NBo2 VMCMx5nlmcrc/bhPAMReOZDFxIOhxHM/KHYAsSnR5tlghE2awQLZJkt/2UxfUCqPYkAsYgKn Vb6ZAzdUmTlTXOUJCG1AFmsltlsP2NllLwvrzHYz3mWD7UsToXYI8ky3gXWJICWXEBMTpaxS Lg0K8CYcCe/Ovd9jq5D6uIURYcHLAAAAAAAA --------------ms060608090509080909040508-- --===============1713377603== 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 --===============1713377603==--