From p2pi-bounces@ietf.org Fri May 2 15:47:35 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5D43A69AA; Fri, 2 May 2008 15:47: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 1CE2A3A68BB for ; Fri, 2 May 2008 15:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 0zELKVhe9iag for ; Fri, 2 May 2008 15:47:34 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 02F3E3A6860 for ; Fri, 2 May 2008 15:47:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1209768454; x=1209854854; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=CsVUlqGfU83/fHFLtjLccnQi8cuSNX65svfjWQObI18H2Ntsd08JSZLR57XzRg6fPWIUXrH7b2dQi3 WMi0coeg== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.7123119; Fri, 02 May 2008 18:47:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 18:47:16 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A7017649B1@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Position Paper Submission Thread-Index: AcispnhSaRF5tsL8QNC28POYq39wsQ== From: "Peterson, Jon" To: Subject: [p2pi] Position Paper Submission X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , 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 Position Paper Due Date: May 9, 5PM Eastern time Please email Position papers to: p2pi-com@ietf.org The p2pi-com mailing list exists only to house the position papers, and is not to be confused with the regular p2pi list (where you have received this message). You will get a moderator approval message when you send a message to the p2pi-com list - that is normal and not an error, we'll pull it out of the queue. This is a closed list, and there is no need to subscribe to it. Position papers should be in plain text or, if graphics are required, PDF format. Please limit position papers to no more than 5 pages in length. One or two pages is the preferred length. We've had a number of inquiries from people interested in the workshop who are reluctant to submit a paper because they have no particular agenda to push in this space. We'd like to stress that position papers can shed light on any aspect of the problem or solution space, and we'd encourage anyone interested in making a technical contribution to ongoing work in this space at the IETF to submit a paper even if it serves only to further explain the problem, the requirements, or even the non-requirements associated with this work. That much said, if it is not appropriate for you to submit a position paper, please contact Cullen and Jon by May 9th to request a waiver. You can reach us at: jon.peterson@neustar.biz, fluffy@cisco.com Jon and Cullen would also be happy to answer in questions about the position paper submission process or the workshop, either on this list or in private correspondence. Jon Peterson NeuStar, Inc. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 9 13:49: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 259A63A6801; Fri, 9 May 2008 13:49: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 D78593A67FC for ; Fri, 9 May 2008 13:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 GYPowdJLSIMV for ; Fri, 9 May 2008 13:49:28 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id D02783A67EC for ; Fri, 9 May 2008 13:49:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1210366092; x=1210452492; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=E8mYaLRCnn0m3xoZ5jTUQdXbOwyukKytPNOF+vAYP9QLSDnHxnn+UpVW4djdIhqwXgPRW3Mc0/Y5L1 +7L/XCvg== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.7477452; Fri, 09 May 2008 16:47:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 16:47:25 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A7017652FD@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Position Paper Submissions thread-index: AciyFeNQcs2T7Iv7St+ZKwmCkIxlfg== From: "Peterson, Jon" To: Subject: [p2pi] Position Paper Submissions X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , 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 a reminder, position papers should be submitted to: p2pi-com@ietf.org After submitting a paper, you should receive an automatic moderator approval queue message from the ietf.org mail server. I've had a report of one person who had difficulty submitting position papers due to IETF mail server policies. If you do -not- receive a moderator approval queue message, you may send the paper directly to myself and Cullen (fluffy@cisco.com). We'll publish a list of papers received on Monday, in case any were missed. Jon Peterson NeuStar, Inc. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 13 12:55: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 B122D3A6890; Tue, 13 May 2008 12:55: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 9F98D3A6890 for ; Tue, 13 May 2008 12:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuYRHEnSpOjO for ; Tue, 13 May 2008 12:55:40 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 4C8BC3A683B for ; Tue, 13 May 2008 12:55:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1210708382; x=1210794782; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=CD8DR5sgpfwEsWEufgZZCirvY6kXzwhkBuSZCq83aDjd665qdiCOjj/uhLszEAmqrky/DYxgl0xmiK icVqnXnQ== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.7578222; Tue, 13 May 2008 15:52:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 15:52:56 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A7018598AF@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submissions Received thread-index: Aci1Mu/90+V0ZI1FThanvNbnCwe1nQ== From: "Peterson, Jon" To: Subject: [p2pi] Submissions Received X-BeenThere: p2pi@ietf.org X-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 no particular order, we have recevied the submissions listed below. We will try to solicit invitations to speak before this weekend. The format and duration of talks have yet to be decided, but our selection process has a focus on topics that will point to useful engineering directions for ongoing. Also, we are looking into some lunch options for the day of the workshop. To size up the buffet, we may prop up a registration server and pass around the hat, as it were, to fund that lunch. Please stay tuned if you plan on being hungry on May 28th. Thanks for all these contributions, and for giving us a busy week trying to sort them out! [1] Nick Weaver - The case for "Ugly Now" User Fairness [2] Paul Jessop - Position paper of the RIAA [3] Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge Capacity Hosting Overlays of Nano Data Centers [4] Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer Selection Guidance [5] Marie-Jose Montpetit - Community Networks: getting P2P out of prison - the next steps [6] D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related Attributes of App Scenarios for P2PSIP [7] Jiang XingFeng - Analysis of the Service Discovery in DHT network [8] R. Penno - P2P Status and Requirements [9] Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the conflict between ISPs and BitTorrent through mutual cooperation [10] Robb Topolski - Framing Peer to Peer File Sharing [11] M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network Cooperative Overlay System [12] Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer, Tracker-Based Peer-to-Peer Content Distribution Architecture [13] Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications [14] Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer Services [15] Camiant (Jackson) - Camiant Submission [16] Jason Livingood, Rich Woundy - Comcast Submission [17] Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact [18] Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences" [19] Jiang XingFeng, Ning Zong - Content Replication for Internet P2P Applications [20] Sandvine (Dundas) - Analysis of Traffic Demographics in Broadbank networks [21] Sandvine (Dundas) - Traffic Management in a World with Network Neutrality [22] Stanislav Shalunov - Users want P2P, we make it work [23] R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet scale mobility service: a case study on building a DHT based service for ISPs [24] M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations [25] Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer Applications [26] Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture [27] Eric Rescorla - Notes on P2P Blocking and Evasion [28] Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P Systems [29] Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer Cooperation [30] Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With Peer-to-peer Traffic? [31] David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure Considerations [32] Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving this traffic management problem... and the next, and the next _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 16 15:45: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 29E453A6BD5; Fri, 16 May 2008 15:45: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 6DF7D3A6BCB for ; Fri, 16 May 2008 15:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 d5k8FrxH2hIU for ; Fri, 16 May 2008 15:45:46 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 216BC3A693F for ; Fri, 16 May 2008 15:45:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1210977937; x=1211064337; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=S6gI27H3+ylO0AKoRUBg+8pdHkv0yduenyNi9cXiq14LQChiPTEQKPgl3luxPFIDekJXL81MMKUv0e YIvmTr/A== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.7681608; Fri, 16 May 2008 18:45:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 18:45:25 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A701859F10@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Workshop Agenda (and more about lunch) thread-index: Aci3pofnI6ukOeKjTVWA5McgOJy8xA== From: "Peterson, Jon" To: Subject: [p2pi] Workshop Agenda (and more about lunch) X-BeenThere: p2pi@ietf.org X-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 9:30 - Welcome/Note Well/Intro Slides 9:45 - Service Provider Perspective (Comcast) (40m talk/20m discussion) 10:45 - Application Designer Perspective (BitTorrent) (20m/10m) 11:15 - Lightning Talks & General Discussion 11:45 - Lunch 12:45 - Localization and Caches 2:15 - Afternoon Break 2:30 - New Approaches to Congestion 3:15 - Quality of Service 4:00 - Conclusions & Wrap 4:30 - Meeting Ends This is how we'd like to structure the agenda. The morning "lightning talks" will be focused on additional scoping of the problem space. The afternoon topics, encompassing localization/caching, congestion management, and QoS will all have multiple speakers. We will be sending out a few solicitations for speakers based on the position papers starting today. Also, bear in mind that these sorts of events have a tendancy to run a bit late, so the end time is flexible. Interest in this workshop has been very high, and we'd like to thank everyone who submitted position papers. Since the scale of the workshop is steadily growing (requests for waivers have continued to come in over the past week, and this mailing list has in fact grown by about 30 persons in that time frame), our main logistical challenge has become planning for lunch. Compounding this problem, many position papers have multiple authors who may or may not be there, and many waivers came in the form of family RSVPs ("me + 2 or so"). To address this, we are going to prop up a registration server, hopefully by the middle of next week. We'll use these registrations to print nametags, but the server will also beat you up for some lunch money, given that feeding the number of interested parties has become a non-trivial task. Please do keep an eye out for the announcement of the registration page. We do apologize for the last-minute nature of this, but the alternative is a roomful of hungry engineers, and none of us wants to see that. Jon Peterson NeuStar, Inc. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 16 16: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 027E93A6AFC; Fri, 16 May 2008 16: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 C1EC828C284 for ; Fri, 16 May 2008 16:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_40=-0.185, 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 5vthWIniRb7f for ; Fri, 16 May 2008 16:13:36 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id A666C3A6AFC for ; Fri, 16 May 2008 16:13:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1210979609; x=1211066009; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=PUBvEmn1wTwsOrRhmHEYnzIzgs8pE/v2CO4PmX3NFUgYhCtouHh34miToX6Ho5rFPoAZrawHxKyfCM rEtwkDdg== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.7520517; Fri, 16 May 2008 19:13:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 19:13:10 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A701859F13@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: List of Submissions (final) thread-index: Aci3qmiKbc2NSsrwTAODdF9xYx3qZg== From: "Peterson, Jon" To: Subject: [p2pi] List of Submissions (final) X-BeenThere: p2pi@ietf.org X-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="===============0590658844==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0590658844== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B7AA.68E548FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B7AA.68E548FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is our final list of submissions received, including a few we missed collecting last Friday (apologies) and a few who requested extensions on the deadline. =20 We will make these presentations available in a .zip file in a link off the Wiki page soon. More information forthcoming. =20 =20 [1] Nick Weaver - The case for "Ugly Now" User Fairness =20 [2] Paul Jessop - Position Paper of the RIAA =20 [3] Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge Capacity Hosting Overlays of Nano Data Centers =20 [4] Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer Selection Guidance =20 [5] Marie-Jose Montpetit - Community Networks: Getting P2P out of Prison - the Next Steps =20 [6] D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related Attributes of Application Scenarios for P2PSIP =20 [7] Jiang XingFeng - Analysis of the Service Discovery in DHT network =20 [8] R. Penno - P2P Status and Requirements =20 [9] Patrick Crowley, Shakir James - Symbiotic P2P: Resolving the conflict between ISPs and BitTorrent through Mutual Cooperation =20 [10] Robb Topolski - Framing Peer to Peer File Sharing =20 [11] M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network Cooperative Overlay System =20 [12] Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer, Tracker-Based Peer-to-Peer Content Distribution Architecture =20 [13] Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy, Laird Popkin - P4P: Provider Portal for P2P Applications =20 [14] Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer Services =20 [15] Camiant (Jackson) - Camiant Submission =20 [16] Jason Livingood, Rich Woundy - Comcast Submission =20 [17] Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact =20 [18] Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences" =20 [19] Jiang XingFeng, Ning Zong - Content Replication for Internet P2P Applications =20 [20] Sandvine (Dundas) - Analysis of Traffic Demographics in Broadband networks =20 [21] Sandvine (Dundas) - Traffic Management in a World with Network Neutrality =20 [22] Stanislav Shalunov - Users want P2P, we make it work =20 [23] R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet scale mobility service: a case study on building a DHT based service for ISPs =20 [24] M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations =20 [25] Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer Applications =20 [26] Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture =20 [27] Eric Rescorla - Notes on P2P Blocking and Evasion =20 [28] Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P Systems =20 [29] Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer Cooperation =20 [30] Toby Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With Peer-to-peer Traffic? =20 [31] David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure Considerations =20 [32] Bob Briscoe, Lou Burness, Toby Moncaster, Phil Eardley - Solving this traffic management problem... and the next, and the next =20 [33] Hannes Tschofenig, Marcin Matuszewski - Dealing with P2P Traffic in an Operator Network: State-of-the-Art =20 [34] Jean-Francois Mule - CableLabs Submission =20 [35] Alan Arolovitch - Peer-to-peer infrastructure: Case for cooperative P2P caching =20 [36] Leslie Daigle - Defining Success: Questions for the Future of the Internet and Bandwidth-Intensive Activities =20 [37] William Check, Rex Bullinger - NCTA Position Paper ------_=_NextPart_001_01C8B7AA.68E548FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is our final = list of submissions received, including a few we missed collecting last Friday (apologies) and a few who requested extensions on the = deadline.

 

We will make these presentations available in a .zip file in a link off the Wiki page soon. = More information forthcoming.

 

 

[1] Nick Weaver - = The case for "Ugly Now" User Fairness

 

[2] Paul Jessop - = Position Paper of the RIAA

 

[3] Nikloaos = Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge Capacity Hosting Overlays of = Nano Data Centers

 

[4] Bruce Davie, = Stefano Previdi, Jan Medved, Albert Tian - Peer Selection = Guidance

 

[5] Marie-Jose = Montpetit - Community Networks: Getting P2P out of Prison - the Next = Steps

 

[6] D. Bryan, S. = Dawkins, B. Lowekamp, E. Shim - Infrastructure-related Attributes of Application = Scenarios for P2PSIP

 

[7] Jiang XingFeng = - Analysis of the Service Discovery in DHT = network

 

[8] R. Penno - P2P = Status and Requirements

 

[9] Patrick = Crowley, Shakir James - Symbiotic P2P: Resolving the conflict between ISPs and = BitTorrent through Mutual Cooperation

 

[10] Robb = Topolski  - Framing Peer to Peer File Sharing

 

[11] M. = Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network Cooperative Overlay = System

 

[12] Y. Wang, S. = Tan, R. Grove - Traffic Localization with Multi-Layer, Tracker-Based = Peer-to-Peer Content Distribution Architecture

 

[13] Haiyong Xie, = Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy, Laird Popkin - P4P: = Provider Portal for P2P Applications

 

[14] Michael = Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-Peer = Services

 

[15] Camiant = (Jackson) - Camiant Submission

 

[16] Jason = Livingood, Rich Woundy - Comcast Submission

 

[17] Benny Rodrig - = Enterprise IP = Networks and the P2P Traffic Load Impact

 

[18] Ted Hardie - Peer-to-Peer traffic and "Unattended = Consequences"

 

[19] Jiang = XingFeng, Ning Zong - Content Replication for Internet P2P = Applications

 

[20] Sandvine = (Dundas) - = Analysis of Traffic Demographics in Broadband networks

 

[21] Sandvine = (Dundas) - = Traffic  Management in a World with Network = Neutrality

 

[22] Stanislav = Shalunov - Users want P2P, we make it work

 

[23] R. Cuevas, A. = Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet scale mobility service: a case = study on building a DHT based service for ISPs

 

[24] M. Barnes, B. = McCormick - Peer to Peer Infrastructure = Considerations

 

[25] Henning = Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-Peer = Applications

 

[26] Damien Saucez, = Benoit Donnet, Olivier Bonaventure, Dimitri Papdimitriou - Towards an Open Path Selection Architecture

 

[27] Eric Rescorla = - Notes on P2P Blocking and Evasion

 

[28] Vinay = Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P = Systems

 

[29] Enrico = Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer = Cooperation

 

[30] Toby = Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With Peer-to-peer = Traffic?

 

[31] David Sohn, = Alissa Cooper - Peer-to-Peer Infrastructure = Considerations

 

[32] Bob Briscoe, = Lou Burness, Toby Moncaster, Phil Eardley - Solving this traffic management problem... and the next, and the next

 

[33] Hannes = Tschofenig, Marcin Matuszewski - Dealing with P2P Traffic in an Operator Network: State-of-the-Art

 

[34] Jean-Francois = Mule - CableLabs Submission

 

[35] Alan = Arolovitch - Peer-to-peer infrastructure: Case for cooperative P2P = caching

 

[36] Leslie Daigle = - Defining Success: Questions for the Future of the Internet and Bandwidth-Intensive Activities

 

[37] William Check, = Rex Bullinger - NCTA Position Paper

------_=_NextPart_001_01C8B7AA.68E548FB-- --===============0590658844== 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 --===============0590658844==-- From p2pi-bounces@ietf.org Mon May 19 16:46: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 E5C6C3A6ABD; Mon, 19 May 2008 16:46: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 AE65F3A6B39 for ; Mon, 19 May 2008 16:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yfh6OfaEqvg for ; Mon, 19 May 2008 16:46:49 -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 6F1623A6868 for ; Mon, 19 May 2008 16:46:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,512,1204531200"; d="scan'208";a="101045515" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 May 2008 16:46:47 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4JNklDq027899 for ; Mon, 19 May 2008 16:46:47 -0700 Received: from [128.107.103.115] ([128.107.103.115]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4JNklnr000319 for ; Mon, 19 May 2008 23:46:47 GMT Message-Id: From: Cullen Jennings To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 19 May 2008 16:47:32 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=129; t=1211240807; x=1212104807; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Submitted=20papers=20are=20available |Sender:=20; bh=7WkkocM566i/S777DAIMfy59gUXwu2PuIfLrMF0P/wA=; b=GnKfjDsqmrIAj/BLndNflGhMAEtS4e45ffdao2eMAraqkVpkKhPgcBcta9 zO9vm+JGzJWABxmoORvOvNfLO2hj6HPwzEXna78J2KJ/oe/YBjQE6Pw6+pYh PWzg7/mDLq; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 papers we received are available at the following link: http://idisk.mac.com/cullenfluffyjennings-Public/P2PI?view=web _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon May 19 17:43: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 EF98C3A6AFC; Mon, 19 May 2008 17: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 25F9B3A6AFC for ; Mon, 19 May 2008 17:43:24 -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 Fddo93HpMAOM for ; Mon, 19 May 2008 17:43:23 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 257343A6AD8 for ; Mon, 19 May 2008 17:43:23 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.45903823; Mon, 19 May 2008 20:43:08 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 May 2008 20:43:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 20:43:01 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Submitted papers are available Thread-Index: Aci6CtDqUx7XraVZQCqJmteEtUYphgAB4QXQ References: From: "Livingood, Jason" To: "Cullen Jennings" , X-OriginalArrivalTime: 20 May 2008 00:43:07.0857 (UTC) FILETIME=[78C76410:01C8BA12] Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 Are you sure they are all there? Perhaps you can ZIP them all up so we can download in one file? Thanks Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Monday, May 19, 2008 7:48 PM > To: p2pi@ietf.org > Subject: [p2pi] Submitted papers are available > > > The papers we received are available at the following link: > > http://idisk.mac.com/cullenfluffyjennings-Public/P2PI?view=web > > > _______________________________________________ > 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 May 19 17:54: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 DB6C53A69C0; Mon, 19 May 2008 17:54: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 5108A3A685D for ; Mon, 19 May 2008 17:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTCMiRGRI2DP for ; Mon, 19 May 2008 17:54:08 -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 D1CA13A6BA9 for ; Mon, 19 May 2008 17:52:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,512,1204531200"; d="scan'208";a="69900137" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 19 May 2008 17:52:59 -0700 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 m4K0qwNr006838; Mon, 19 May 2008 17:52:58 -0700 Received: from [128.107.103.115] ([128.107.103.115]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4K0qwka020398; Tue, 20 May 2008 00:52:58 GMT Message-Id: <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> From: Cullen Jennings To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 19 May 2008 17:53:44 -0700 References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1047; t=1211244778; x=1212108778; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[p2pi]=20Submitted=20papers=20are=20ava ilable |Sender:=20; bh=QUqEAj3cQlZcMW/z+dHhBOvOH5r4nqN4ZBIh+ES7dCU=; b=WADfH/xTvUFv9BOLyAQ4PAtBex22IlgtTrPdRwxS8rnCu5hatkA9z7M5EA Is3j68RG22Uk0W/w2axr4Psbjo5ohiD3QjFD68PJXaut7FZP4xUbeobd89Ub lf+qKua4wt; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 hope I have them all there - let me know if you see anything missing. They should be numbered 1 to 37 matching the numbering in Jon's list of all the received papers. I put a ZIP file at called p2pi-all.zip with all of them at http://idisk.mac.com/cullenfluffyjennings-Public?view=web On May 19, 2008, at 5:43 PM, Livingood, Jason wrote: > Are you sure they are all there? Perhaps you can ZIP them all up so > we > can download in one file? > > Thanks > Jason > > > -----Original Message----- > > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: Monday, May 19, 2008 7:48 PM > > To: p2pi@ietf.org > > Subject: [p2pi] Submitted papers are available > > > > > > The papers we received are available at the following link: > > > > http://idisk.mac.com/cullenfluffyjennings-Public/P2PI?view=web > > > > > > _______________________________________________ > > 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 May 19 18: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 A4D833A6B8B; Mon, 19 May 2008 18: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 022263A6B7F for ; Mon, 19 May 2008 18:08:03 -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 NfDmjr7VeU3N for ; Mon, 19 May 2008 18:08:02 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id BD9153A6B72 for ; Mon, 19 May 2008 18:08:01 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.55513032; Mon, 19 May 2008 21:07:47 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 May 2008 21:07:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 21:07:39 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Submitted papers are available Thread-Index: Aci6E+hbUOa41PqBRKyaf0Y7C3B9CQAAZF0Q References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> From: "Livingood, Jason" To: "Cullen Jennings" X-OriginalArrivalTime: 20 May 2008 01:07:47.0666 (UTC) FILETIME=[EAD05320:01C8BA15] Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 Perhaps IE7 does not like .mac - I only counted something like 19 papers. The ZIP file had all of them though. Thanks! Jason > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, May 19, 2008 8:54 PM > To: Livingood, Jason > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Submitted papers are available > > > I hope I have them all there - let me know if you see > anything missing. They should be numbered 1 to 37 matching > the numbering in Jon's list of all the received papers. > > I put a ZIP file at called p2pi-all.zip with all of them at > > http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > > On May 19, 2008, at 5:43 PM, Livingood, Jason wrote: > > > Are you sure they are all there? Perhaps you can ZIP them > all up so > > we can download in one file? > > > > Thanks > > Jason > > > > > -----Original Message----- > > > From: p2pi-bounces@ietf.org > [mailto:p2pi-bounces@ietf.org] On Behalf > > > Of Cullen Jennings > > > Sent: Monday, May 19, 2008 7:48 PM > > > To: p2pi@ietf.org > > > Subject: [p2pi] Submitted papers are available > > > > > > > > > The papers we received are available at the following link: > > > > > > http://idisk.mac.com/cullenfluffyjennings-Public/P2PI?view=web > > > > > > > > > _______________________________________________ > > > 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 May 20 00:06: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 903333A6BA1; Tue, 20 May 2008 00:06: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 1D3F83A6B5B for ; Tue, 20 May 2008 00:06:24 -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 oJvXJRdpS-jp for ; Tue, 20 May 2008 00:06:23 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 04A333A67FA for ; Tue, 20 May 2008 00:06:21 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:06:20 +0200 Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:06:19 +0200 Received: from [10.229.8.119] (10.229.8.119) by smtp.telecomitalia.it (10.188.101.115) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 20 May 2008 09:06:19 +0200 Message-ID: <4832785C.50607@telecomitalia.it> Date: Tue, 20 May 2008 09:06:04 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "Livingood, Jason" References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> <45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 20 May 2008 07:06:19.0759 (UTC) FILETIME=[010537F0:01C8BA48] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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="===============0834318235==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0834318235== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308060401080308090202" --------------ms000308060401080308090202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Livingood, Jason wrote: > Perhaps IE7 does not like .mac - I only counted something like 19 > papers. It seems other browsers have problems as well (neither Firefox 3.0 nor Iceweasel seem to work). However, being idisk a webdav service, it should work with any dav client (e.g. cadaver). -- Ciao, Enrico --------------ms000308060401080308090202 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA1MjAwNzA2MDRaMCMG CSqGSIb3DQEJBDEWBBSkP0qVpqwTRzAFSGgRmeHbQI46hDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAHLuzYNorJ5O /DqO5mAw04OzPJDhhnRTzbMclq1OrKuNHvUW8JIYud/tEEAsxr1BWStx9ytsTA/pnUe+I2BN ui9cSWUaGcfICXpL88g5rnbkHaFGKcu1LgLEOQVjX9+W6tryyd3oBz44fiVLkvo+Qqg4hD0J HPB+MeaL9eKIsnnT0mF3XDuR9elD8fDuwN/+oxcuIQTCLz/grzN0+W1Gqj2m587TODmYE+aK F4D810htE85qSL19HPY4RLEBKGCLXAulGRFYFOJdGfN2s1PfTYUTs3Yx+4EcqfPWf5EgHkhQ iyg7FFUJhnzFFCQJDDKg2sDJp7bDVSN0BiUKiSAfG4IAAAAAAAA= --------------ms000308060401080308090202-- --===============0834318235== 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 --===============0834318235==-- From p2pi-bounces@ietf.org Tue May 20 20: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 51B543A743D; Tue, 20 May 2008 20: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 32EBE3A7412 for ; Tue, 20 May 2008 20:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8XlRpc2Yp-8 for ; Tue, 20 May 2008 20:37:06 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B5F633A68F8 for ; Tue, 20 May 2008 06:14:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,515,1204531200"; d="scan'208";a="13838664" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 20 May 2008 06:07:36 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4KD7aoN022995; Tue, 20 May 2008 06:07:36 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m4KD7alR016808; Tue, 20 May 2008 13:07:36 GMT From: Cullen Jennings To: "Enrico Marocco" In-Reply-To: <4832785C.50607@telecomitalia.it> Impp: xmpp:cullenfluffyjennings@jabber.org References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> <45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> <4832785C.50607@telecomitalia.it> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 20 May 2008 06:07:10 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=554; t=1211288856; x=1212152856; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[p2pi]=20Submitted=20papers=20are=20ava ilable |Sender:=20; bh=NWby9yyoJw7BYgu8ML47lDt63yg3OAhNjxo8yfkpMjA=; b=bh1w37fY+SGpIL+9HPBZ6MwgB73+A6q4OIxy6tEVwoZhrr3xp+wE1T5c2O WlbZLxI2rMY/6ZkIJJcBLn/XbncI6eIXvCbEXuDVSdlbqIbYXD2yH+o766QO XGW6HmQrwd; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: p2pi@ietf.org, "Livingood, Jason" Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 Interesting ... sorry it did not work - so much .mac :-) I put a mirror copy of the zip files with all the papers at http://www.iii.ca/p2pi-all.zip On May 20, 2008, at 12:06 AM, Enrico Marocco wrote: > Livingood, Jason wrote: >> Perhaps IE7 does not like .mac - I only counted something like 19 >> papers. > > It seems other browsers have problems as well (neither Firefox 3.0 nor > Iceweasel seem to work). However, being idisk a webdav service, it > should work with any dav client (e.g. cadaver). > > -- > Ciao, > Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 20 20:42: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 9211328C215; Tue, 20 May 2008 20:42: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 1CCD33A67CC for ; Tue, 20 May 2008 20:42:39 -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 7WLknUPY06hf for ; Tue, 20 May 2008 20:42:38 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id 121D228C21F for ; Tue, 20 May 2008 06:18:48 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 15:18:47 +0200 Received: from grfhub702rm001.griffon.local ([10.19.3.9]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 15:18:44 +0200 Received: from [10.229.8.119] (10.229.8.119) by smtp.telecomitalia.it (10.19.3.41) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 20 May 2008 15:18:43 +0200 Message-ID: <4832CFA4.3050102@telecomitalia.it> Date: Tue, 20 May 2008 15:18:28 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Cullen Jennings References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com> <45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> <4832785C.50607@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 20 May 2008 13:18:44.0259 (UTC) FILETIME=[07615730:01C8BA7C] Cc: "p2pi@ietf.org" , "Livingood, Jason" Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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="===============0244797893==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0244797893== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030102010609080005040906" --------------ms030102010609080005040906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Interesting ... sorry it did not work - so much .mac :-) I put a > mirror copy of the zip files with all the papers at > > http://www.iii.ca/p2pi-all.zip Not a big deal actually. I'm sure all people on this list have access to a Mac, can use a command-line dav client or at worst can fall back on their iPhone's Safari ;-) -- Ciao, Enrico --------------ms030102010609080005040906 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA1MjAxMzE4MjhaMCMG CSqGSIb3DQEJBDEWBBQWA6qtIDUzc0vvtt0xnfFfgFicbzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKOigs1x3ECT 7dV14Kprw7AdjQnaYkFD4BkBcR5IXc/RTU0izIv1YIDhSeO92pDpKXC1bbKGsMWrH/LqPHZ6 xORw1yN54beLFTkbIyoOwxJbtHTbDCcdKVl13glvHUGwzFbhOaUuEQ2wQMZswX2JIAG1S9Ib pJOiuz70DPSHpGwV5g3re8+oMpHYu/FwScAy+LWhmyjpGkyH6HD1xba1ATp9HkhbKUitA65T KYUhOwzhVMILiCeH7NKz87oXzHx25n7GclkKrbpbfilJhUB54yodFrK9IVEU1ihd74lC+J3n OZzA63a860kJIP7526PbqkdT5lTYzXDABE4VCiI+bdYAAAAAAAA= --------------ms030102010609080005040906-- --===============0244797893== 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 --===============0244797893==-- From p2pi-bounces@ietf.org Tue May 20 20:50:18 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA10928C3EE; Tue, 20 May 2008 20:50:17 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF56C28C3B2 for ; Tue, 20 May 2008 20:50:15 -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_50=0.001, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqo9c5EY1SeN for ; Tue, 20 May 2008 20:50:14 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id C38F328E18D for ; Tue, 20 May 2008 13:01:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1211313713; x=1211400113; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=gr7z9Wf5t8J+r+cRjZ4pEt+gd/yJx9D1ZaiY/o+9qMIO878Gk1KWGBlG0V7F/MMj5Hw6F514+WFqp8 vIJBux3w== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.6917574; Tue, 20 May 2008 16:01:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 16:01:36 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A70185A2D0@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PI registration now online, REGISTER NOW thread-index: Aci6tE9Wg3KLbXcpTaOvciuRQGRXQQ== From: "Peterson, Jon" To: Subject: [p2pi] P2PI registration now online, REGISTER NOW X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org If you are going to make it to P2PI in person, please register for the event online at the following URL by this Friday (May 20) at 5PM Eastern time: https://www.ietf.org/registration/RAI/ietfreg.py Bear in mind that online registrations will be used to size the lunch, so if you put it off and try to register on site, we can't guarantee to feed you. So actually, don't wait until Friday, just register right now. This applies if you submitted a paper, received a waiver, or got a colleague to request a waiver on your behalf. Also, we have at this point sent out most of the speaker invitations. We're still finalizing one or two slots, but probably if you have not heard from us yet, you are off the hook. Remember, IF YOU ARE ATTENDING REGISTER NOW. Jon Peterson NeuStar, Inc. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 20 20:55: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 EB7033A6FD0; Tue, 20 May 2008 20:55: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 D48CA3A6FA8 for ; Tue, 20 May 2008 20:55:12 -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 KtXukEzrJ7EY for ; Tue, 20 May 2008 20:55:11 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id A3DF828E999 for ; Tue, 20 May 2008 14:54:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Michael.Needham@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1211320459!759931!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25969 invoked from network); 20 May 2008 21:54:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 20 May 2008 21:54:19 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m4KLsENL000727 for ; Tue, 20 May 2008 14:54:18 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m4KLsEs5006960 for ; Tue, 20 May 2008 16:54:14 -0500 (CDT) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m4KLsDfX006955 for ; Tue, 20 May 2008 16:54:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 17:54:11 -0400 Message-ID: <87CD2EA51868284A93E4F291E6190286026853AB@de01exm69.ds.mot.com> In-Reply-To: <4832785C.50607@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Submitted papers are available Thread-Index: Aci6SAl5e6VpT5TOS/exkGInhZP4VAAe4Tig References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com><45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> <4832785C.50607@telecomitalia.it> From: "Needham Mike-CMN002" To: "Enrico Marocco" , "Livingood, Jason" X-CFilter-Loop: Reflected Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-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 page seems to lack a scroll function. However, if you sort by name (by clicking the "name" bar), then reverse sort (by clicking again), you'll see all the papers. -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Enrico Marocco Sent: Tuesday, May 20, 2008 2:06 AM To: Livingood, Jason Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available Livingood, Jason wrote: > Perhaps IE7 does not like .mac - I only counted something like 19 > papers. It seems other browsers have problems as well (neither Firefox 3.0 nor Iceweasel seem to work). However, being idisk a webdav service, it should work with any dav client (e.g. cadaver). -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 20 20:57: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 EBB543A6FFB; Tue, 20 May 2008 20:57: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 0480C3A6FD4 for ; Tue, 20 May 2008 20:57: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 2304GzACnhVm for ; Tue, 20 May 2008 20:57:48 -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 7BEEF28D474 for ; Tue, 20 May 2008 09:29:48 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1882324wfd.31 for ; Tue, 20 May 2008 09:29:47 -0700 (PDT) Received: by 10.142.231.7 with SMTP id d7mr3415153wfh.194.1211300986037; Tue, 20 May 2008 09:29:46 -0700 (PDT) Received: from TOPOL009 ( [76.115.95.63]) by mx.google.com with ESMTPS id 32sm457866wfc.16.2008.05.20.09.29.44 (version=SSLv3 cipher=RC4-MD5); Tue, 20 May 2008 09:29:44 -0700 (PDT) From: "Robb Topolski" To: "'Enrico Marocco'" , "'Livingood, Jason'" References: <45AEC6EF95942140888406588E1A6602045CB881@PACDCEXCMB04.cable.comcast.com> <1E89A4AE-B8A9-4E6A-9B3D-69895395C337@cisco.com><45AEC6EF95942140888406588E1A6602045CB883@PACDCEXCMB04.cable.comcast.com> <4832785C.50607@telecomitalia.it> Date: Tue, 20 May 2008 09:29:43 -0700 Message-ID: <001801c8ba96$b65da3f0$d1b1a8c0@mshome.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4832785C.50607@telecomitalia.it> Thread-Index: Aci6SAXulF5jc3tXR6aaSA1hkocWIAATopSA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I have posted the files and the .zip archive to http://www.funchords.com/p2pi/ for those that are having problems. --Robb Topolski -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Enrico Marocco Sent: Tuesday, May 20, 2008 12:06 AM To: Livingood, Jason Cc: p2pi@ietf.org Subject: Re: [p2pi] Submitted papers are available Livingood, Jason wrote: > Perhaps IE7 does not like .mac - I only counted something like 19 > papers. It seems other browsers have problems as well (neither Firefox 3.0 nor Iceweasel seem to work). However, being idisk a webdav service, it should work with any dav client (e.g. cadaver). -- Ciao, Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu May 22 13:44: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 2075E28C130; Thu, 22 May 2008 13:44: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 84F6F28C116 for ; Thu, 22 May 2008 13:43:03 -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 rXKogufZRhSL for ; Thu, 22 May 2008 13:43:02 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 9556428C130 for ; Thu, 22 May 2008 13:43:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1211488980; x=1211575380; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=bjZGZuWTUQy5Up5WhChqxFJDq/hqw+KHeqmYVWQtCPugETvj8HCLpsnzc0H6ekuCxptbvvcFyNvckR QaNFTLKQ== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.7007836; Thu, 22 May 2008 16:42:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 16:42:45 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A70185A6B1@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REMINDER: Register for P2PI thread-index: Aci8TGN4uxST4srgRIabHCLjaZSfTQ== From: "Peterson, Jon" To: Subject: [p2pi] REMINDER: Register for P2PI X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This morning's numbers suggested that around fifty people have registered for P2PI so far. While this would be a nice size for our discussion, I suspect that there are more folks out there who have not gotten around to registering yet. Please register at the URL below by tomorrow COB Eastern time. Remember that this is a holiday weekend in the USA, so if we don't get your registrations by the weekend, we may not be able to tally lunch next Wednesday. https://www.ietf.org/registration/RAI/ietfreg.py Jon Peterson NeuStar, Inc. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 27 05:20: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 9681A3A6AE2; Tue, 27 May 2008 05:20: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 C062228C247 for ; Tue, 27 May 2008 05:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCZIcVFlZlNi for ; Tue, 27 May 2008 05:20:20 -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 8374128C24A for ; Tue, 27 May 2008 05:15:55 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2240733wfd.31 for ; Tue, 27 May 2008 05:15:59 -0700 (PDT) Received: by 10.142.215.5 with SMTP id n5mr480321wfg.177.1211890558810; Tue, 27 May 2008 05:15:58 -0700 (PDT) Received: by 10.142.143.10 with HTTP; Tue, 27 May 2008 05:15:58 -0700 (PDT) Message-ID: <3efc39a60805270515s1800ae09jf006053d342e9435@mail.gmail.com> Date: Tue, 27 May 2008 08:15:58 -0400 From: "Robb Topolski" To: "Peterson, Jon" In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A701859F10@STNTEXCH11.cis.neustar.com> MIME-Version: 1.0 References: <31D151A3D66E404AACBBB0247ACA54A701859F10@STNTEXCH11.cis.neustar.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Workshop Agenda (and more about lunch) X-BeenThere: p2pi@ietf.org X-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="===============1398103677==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1398103677== Content-Type: multipart/alternative; boundary="----=_Part_10191_24772821.1211890558798" ------=_Part_10191_24772821.1211890558798 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Best of luck tomorrow, Jon. I'm looking forward to it and still planning on doing the Lightning Talk. Slides on USB key okay? Do you want something before then? On Fri, May 16, 2008 at 6:45 PM, Peterson, Jon wrote: > > 9:30 - Welcome/Note Well/Intro Slides > 9:45 - Service Provider Perspective (Comcast) (40m talk/20m discussion) > 10:45 - Application Designer Perspective (BitTorrent) (20m/10m) > 11:15 - Lightning Talks & General Discussion > 11:45 - Lunch > 12:45 - Localization and Caches > 2:15 - Afternoon Break > 2:30 - New Approaches to Congestion > 3:15 - Quality of Service > 4:00 - Conclusions & Wrap > 4:30 - Meeting Ends > > > This is how we'd like to structure the agenda. The morning "lightning > talks" will be focused on additional scoping of the problem space. The > afternoon topics, encompassing localization/caching, congestion > management, and QoS will all have multiple speakers. We will be sending > out a few solicitations for speakers based on the position papers > starting today. Also, bear in mind that these sorts of events have a > tendancy to run a bit late, so the end time is flexible. > > Interest in this workshop has been very high, and we'd like to thank > everyone who submitted position papers. Since the scale of the workshop > is steadily growing (requests for waivers have continued to come in over > the past week, and this mailing list has in fact grown by about 30 > persons in that time frame), our main logistical challenge has become > planning for lunch. Compounding this problem, many position papers have > multiple authors who may or may not be there, and many waivers came in > the form of family RSVPs ("me + 2 or so"). > > To address this, we are going to prop up a registration server, > hopefully by the middle of next week. We'll use these registrations to > print nametags, but the server will also beat you up for some lunch > money, given that feeding the number of interested parties has become a > non-trivial task. Please do keep an eye out for the announcement of the > registration page. We do apologize for the last-minute nature of this, > but the alternative is a roomful of hungry engineers, and none of us > wants to see that. > > Jon Peterson > NeuStar, Inc. > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_10191_24772821.1211890558798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Best of luck tomorrow, Jon.  I'm looking forward to it and still planning on doing the Lightning Talk.  Slides on USB key okay?  Do you want something before then?

On Fri, May 16, 2008 at 6:45 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:

 9:30 - Welcome/Note Well/Intro Slides
 9:45 - Service Provider Perspective (Comcast) (40m talk/20m discussion)
10:45 - Application Designer Perspective (BitTorrent) (20m/10m)
11:15 - Lightning Talks & General Discussion
11:45 - Lunch
12:45 - Localization and Caches
 2:15 - Afternoon Break
 2:30 - New Approaches to Congestion
 3:15 - Quality of Service
 4:00 - Conclusions & Wrap
 4:30 - Meeting Ends


This is how we'd like to structure the agenda. The morning "lightning
talks" will be focused on additional scoping of the problem space. The
afternoon topics, encompassing localization/caching, congestion
management, and QoS will all have multiple speakers. We will be sending
out a few solicitations for speakers based on the position papers
starting today. Also, bear in mind that these sorts of events have a
tendancy to run a bit late, so the end time is flexible.

Interest in this workshop has been very high, and we'd like to thank
everyone who submitted position papers. Since the scale of the workshop
is steadily growing (requests for waivers have continued to come in over
the past week, and this mailing list has in fact grown by about 30
persons in that time frame), our main logistical challenge has become
planning for lunch. Compounding this problem, many position papers have
multiple authors who may or may not be there, and many waivers came in
the form of family RSVPs ("me + 2 or so").

To address this, we are going to prop up a registration server,
hopefully by the middle of next week. We'll use these registrations to
print nametags, but the server will also beat you up for some lunch
money, given that feeding the number of interested parties has become a
non-trivial task. Please do keep an eye out for the announcement of the
registration page. We do apologize for the last-minute nature of this,
but the alternative is a roomful of hungry engineers, and none of us
wants to see that.

Jon Peterson
NeuStar, Inc.
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi



--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_10191_24772821.1211890558798-- --===============1398103677== 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 --===============1398103677==-- From p2pi-bounces@ietf.org Tue May 27 15:14: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 DA4B73A6910; Tue, 27 May 2008 15:14: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 302253A68DC for ; Tue, 27 May 2008 15:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.678 X-Spam-Level: X-Spam-Status: No, score=-104.678 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_50=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt6qx4TEVE8n for ; Tue, 27 May 2008 15:14:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 034933A6910 for ; Tue, 27 May 2008 15:14:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,550,1204531200"; d="scan'208";a="29193012" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 May 2008 15:14:02 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4RME2JP015916 for ; Tue, 27 May 2008 15:14:02 -0700 Received: from [10.0.129.52] (sjc-vpn4-63.cisco.com [10.21.80.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4RME1mq012340 for ; Tue, 27 May 2008 22:14:01 GMT Message-Id: <81F82335-60FE-4B4A-91A6-A51A800E093E@cisco.com> From: Cullen Jennings To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 18:15:32 -0400 References: <483BD175.7090205@piuha.net> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24430; t=1211926442; x=1212790442; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Incentives=20and=20Deployment=20Considerations= 20for=20P2PI=20Solutions |Sender:=20; bh=hd0c8uDqfWbDypqUbZYPByUV8i2L5J018y11A8Df9GQ=; b=De6HI8UiF3FaBHgKsK4R5eAG3inEcpdGuJbPz/cnKyYUDLAk0DB4+CI4QR Lr+h3paPSqpcHX8qebFDjSz8eakB5ukFdqdRgXnsWhBG28ifNRMV+k7Y8mVc 5Vpl9HclRZ; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [p2pi] Incentives and Deployment Considerations for P2PI Solutions X-BeenThere: p2pi@ietf.org X-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 more paper ... Begin forwarded message: > From: Jari Arkko > Date: May 27, 2008 5:16:37 AM EDT > To: p2pi-com@ietf.org, Cullen Jennings > Subject: later position paper submission > > > I wrote this as a part of my preparations for the workshop. > > Jari > > > > > Network Working Group J. > Arkko > Internet-Draft > Ericsson > Intended status: Informational May 27, > 2008 > Expires: November 28, 2008 > > > Incentives and Deployment Considerations for P2PI Solutions > draft-arkko-p2pi-incentives-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on November 28, 2008. > > Abstract > > Several papers in this workshop have argued that there is a need to > build new protocol mechanisms to accommodate peer-to-peer traffic in > networks in the most efficient way and with minimal impact to other > traffic. This paper presents an analysis of such solutions from the > point of view of the incentives of the different parties involved in > peer-to-peer traffic. The paper concludes that it is essential to > understand the incentives in order to have a deployable solution. > > > 1. Introduction > > Peer-to-peer (P2P) networking has been cited as the leading consumer > > > > Arkko Expires November 28, 2008 > [Page 1] > > Internet-Draft P2P and Incentives May > 2008 > > > of network bandwidth in networks serving private subscribers. This > is by itself not a problem, as the network providers are in the > business of providing a service to their customers, including the > ones that employ P2P tools. However, the issue is whether P2P > traffic causes undue congestion and reduced level of service for > other customers in the network [I-D.briscoe-tsvwg-relax-fairness]. > > Historically, the Internet service provider market has developed for > interactive services where the bandwidth requirements for each user > vary significantly from over time. This allowed the service > providers to employ statistical multiplexing. At the same time, the > nominal link speeds have been a major factor in marketing Internet > service. But during the last few years, the nature of the traffic > has changed from interactive to more always-on type traffic, for > instance from P2P applications. As a result, statistical > multiplexing is no longer effective, and service providers are > finding that a large sets of users are actually trying to utilize > their full link speed at all times. This is making the service > providers either increase the capacity of their networks to match > the > changing traffic mix and increasingly high broadband service speeds, > or find other ways to deal with the problems. > > It is important to see that these problems are not limited to P2P > tools [P2PI.daigle]. Indeed, not even all P2P applications have > these problems. Some forms of video communication exhibit the same > problems that large file sharing P2P applications do [P2PI.hardie]. > And as the Internet applications evolve, we expect to see new forms > of traffic with these issues. In the remainder of this paper, we > assume any bandwidth-intensive, semi-permanently running application > that may or may not attempt to be friendly with other network usage. > > The fairness problem can present itself in various ways. For > instance, users opening multiple transport sessions may get a > disproportionate share of a congested link. Permanent, high > bandwidth sessions may slow down the ramp-up of short-term, > interactive sessions. Or some users may utilize a transit link far > more than others, resulting in these users gaining a larger share of > the transit costs that the provider has to pay. > > These problems are not just abstract issues. There has been highly > publicized debates about what forms of traffic management are > acceptable for network providers. In reality, network providers > already employ a number of techniques [P2PI.tschofenig]. Solutions > addressing issues in this space have been worked on by network > providers, vendors, and researchers. This paper looks at the > different classes of solutions in Section 2 and analyzes them based > on the incentives of the involved parties in Section 3. The key > issue is finding a solution that provides immediate benefits to > > > > Arkko Expires November 28, 2008 > [Page 2] > > Internet-Draft P2P and Incentives May > 2008 > > > everyone who needs to add new mechanisms or equipment. Another key > issue is the information available to different parties. This leads > us to make conclusions in Section 4. > > > 2. Solution Classes > > A number of solutions have already been deployed to mitigate issues > caused by the changed traffic pattern. Other solutions are actively > being worked on. We divide the solutions in three rough classes, > based partially on similar classifications in [P2PI.tschofenig] > [P2PI.moncaster]: > > Contractual > > These solutions are based on choosing pricing models and > contractual conditions that persuade users to avoid always-on > traffic. For instance, volume-based accounting can be employed, > or the contracts of the heaviest users can be discontinued. > > Voluntary changes in applications > > These solutions are based on some change of behaviour in the > applications, leading to taking other users better into account, > reducing congestion or the use of expensive links, and so on. > > Some of the solutions in this category include: > > * Indicating the desired quality of service, so that interactive > and always-on applications can be distinguished in the network > [P2PI.moncaster]. This assumes that there is a basic level of > quality of service filtering capabilities in the network. > > * Making decisions with better information about the network > topology and cost. For instance, algorithms that P2P > applications use to determine which peers to talk to can > probably be improved. One particular class of improvements > involves "oracles" in the service provider network to help > applications determine the most likely peers with good > connectivity. For instance, peers that are in the local > service provider network vs. behind an expensive and/or > congested transit service provider. > > * New congestion control mechanisms. For instance, BitTorrent > has gotten positive results from their new algorithm > [P2PI.shalunov]. Another example is Bob Briscoe's re-ECN > mechanism [I-D.briscoe-tsvwg-re-ecn-tcp], which allows hosts > and networks to co-operate in the treatment of congestion, and > > > > Arkko Expires November 28, 2008 > [Page 3] > > Internet-Draft P2P and Incentives May > 2008 > > > allows networks to treat different users in a fair manner. > > Network-based mechanisms > > These mechanisms are implemented solely in the network. Examples > include: > > * Prioritization, slowdown, or even blocking of traffic based on > packet header information. Relatively complicated designs > that > peek further into the packet, Deep Packet Inspection (DPI) > have > also been deployed. Priorities can also be set based on user > accounting information, e.g., traffic shaping heavy users > during a rush hour. > > * Changing the "scheduling algorithm", by attempting to complete > the short jobs first everyone's performance will improve. > Similar techniques as discussed above are needed to determine > which jobs are "short" and "long", however. > > * Building caches and peer-to-peer network components in the > service provider network. > > > 3. Incentives > > This section discusses motives, deployment considerations, and how > information available to the different parties affects the > incentives. > > 3.1. Motives > > For any solution to be adopted the involved parties have to have > compatible motives. This is not always trivial, because the parties > may either optimize for different goals, or because there is room > for > malicious behaviour. > > For instance, one type of a quality-of-service solution involves > voluntary marking of packets by applications and subsequent > differentiated treatment of these packets by the network. In this > case the motives of well-behaving users and service providers are > similar: both want interactive applications to be given more > priority, while allowing always-on batch applications to run in the > background, and take as much bandwidth as is available. However, if > the prioritization happens across multiple users, this also implies > that a lower priority marking has the potential to reduce the user's > share of the overall throughput. Clever users can distort the > system > by claiming to run only interactive applications. A tragedy of the > commons follows: The optimal strategy from the point of view of the > > > > Arkko Expires November 28, 2008 > [Page 4] > > Internet-Draft P2P and Incentives May > 2008 > > > entire group of users would be to correctly classify traffic. But > from the point of an individual user a better strategy would be to > lie. > > Note that no misbehaviour is needed from a human user for this to > happen. It is enough that the user runs applications that do this. > And if such applications appear to produce better results than other > applications, the user has an incentive to use them. Having said > this, past experience tells us that a vast majority of networking > software plays by the rules. Attempts to improve or bypass TCP > congestion control are relatively rare, for instance. > > An example where the motives themselves may be conflict is the co- > operation between P2P applications and service providers to > determine > the "best" peers to connect to. The definition of "best" from the > P2P client perspective is a peer that has the highest possible > actual > transfer rate. But the service provider is more interested in > minimization of their costs and overall network congestion. This > may > or may not coincide with the client's desires. For instance, a > service provider may prefer a local peer with a slow access link > over > a remote peer that is connected via an expensive transit connection. > > While not part of the incentives, the available information to the > different parties plays an interesting role as well. It can be > expected that P2P nodes are capable of measuring actual transfer > rates across the end-to-end path, including the behaviour of the end > systems. P2P applications might even be able to accumulate this > information from multiple clients and over time. In contrast, the > service provider network at its basic form would be limited to > understanding the topology and link speeds. More advanced service > provider networks may be capable of traffic-engineering and tracking > congestion in different parts of their network. However, they are > fundamentally incapable of measuring end systems or end-to-end > behaviour in paths that cross multiple networks. > > As a result of the motive conflict and lack of information, any > "oracle" style design [RIPE.feldmann] needs to play a fairly limited > role in supplying additional information to the P2P applications. > Information from the service provider network can help make an > initial guess or to narrow the search for the best peer. But it > cannot replace or govern the overall decision that the P2P > application needs to make on its own. > > Having basic support for peer selection in the P2P applications also > allows the service providers to focus on improvements in their own > network, as opposed to attempting to build tools that try to guide > selection of peers across multiple networks. As long as the oracle > focuses on increasing the number of peers within the service > > > > Arkko Expires November 28, 2008 > [Page 5] > > Internet-Draft P2P and Incentives May > 2008 > > > provider's network, the algorithms in P2P applications can take care > of optimizing the connectivity to peers in other networks. > > 3.2. Deployment Considerations > > Another important consideration is what needs to change in order for > a particular solution to be deployed. Some solutions can be > deployed > unilaterally, some require coordinated action. The coordination may > act as a disincentive to build support for a particular solution. > For instance, P2P application developers do not invest time in > building support for contacting an oracle in the service provider > network until it becomes likely that such oracles can actually used > in some fraction of networks; the limited development resources are > better invested in actions that the developers are in full control > of > -- for instance in improved peer selection algorithms that do not > depend on new infrastructure nodes. Similarly, service providers do > not invest in an oracle until there is software that actually uses > it. > > This problem affects the following types of solutions: > > o Quality of service marking in the host and priority treatment in > the network. > > o Network-assisted P2P peer selection. > > o Network-assisted congestion control mechanisms. > > 3.3. Availability of Information > > Section 3.1 discussed how available information affects the way best > peer selection can be made to work. But there are other aspects of > information availability as well. Specifically, when networks have > unilaterally implemented mechanisms that do not align with the > motives of P2P applications, the applications have employed > information hiding in order to prevent the network from making non- > desireable prioritization decisions for them. Eric Rescorla makes > the argument that ultimately P2P traffic can be secured and made to > resemble other types of traffic, such as VPN traffic. This makes it > very hard for the network to de-prioritize or modify P2P traffic > [P2PI.rescorla]. It is interesting that many of the solutions in > this workshop attempt to increase the amount of information > available > to the parties, while in reality the converse seems to happen. > > We would like to suggest that this trend can only be reversed if the > motives becomes more aligned between the players. That is, no P2P > application will participate in a system designed to restrict P2P > traffic. But they may participate in systems that attempt to > > > > Arkko Expires November 28, 2008 > [Page 6] > > Internet-Draft P2P and Incentives May > 2008 > > > optimize P2P traffic. > > > 4. Conclusions > > The right incentives are a key to the successful standardization and > deployment of any solution in this space. Based on our analysis, we > would like to suggest that the following avenues for IETF > documentation and standards be looked at: > > o Improved and/or standardized peer selection algorithms. These > can > be deployed unilaterally by application developers. > > o Co-operative designs where service provider networks supply > additional information that helps the P2P applications to make a > better initial selection of peers. This should only be done as a > sub-item to the above one; service provider networks do not have > sufficient information or incentives to make the full decision, > and attempting to do so would dissuade the P2P applications from > using such a system. > > o Improved and/or standardized congestion control mechanisms > suitable for P2P and other "always-on" applications. Again, > these > can be deployed unilaterally, and IETF can help ensure they > algorithms are safe for other traffic in the Internet. Note the > difference to quality of service mechanisms that typically > require > deployment at both ends; the quality of service mechanisms would > in many ways be the right solution for this problem, but it is > hard to get them deployed and used due to the issues mentioned > earlier in this paper. > > Still, both the co-operative designs and congestion control > mechanisms depend on the interest of the P2P application > developers and users. The primary incentive from their > perspective is the desire to be nice for the user's other > traffic. > > In any case, these items are tactical, short-term efforts. There is > an associated longer-term issue where the market place has to learn > to provide services without relying on statistical multiplexing. > Ultimately, if there is demand for communication services > (interactive or not) it should be met with an offering that allows > providers to build the infrastructure needed to support it, and > still > be profitable. Pricing models and service packaging has perhaps > even > more to do with this than technical solutions. > > > > > > > > Arkko Expires November 28, 2008 > [Page 7] > > Internet-Draft P2P and Incentives May > 2008 > > > Appendix A. Acknowledgments > > The author would like to thank Magnus Westerlund and Gonzalo > Camarillo for interesting discussions in this problem space. > > > 5. Informative References > > [I-D.briscoe-tsvwg-relax-fairness] > Briscoe, B., Moncaster, T., and A. Burness, "Problem > Statement: We Don't Have To Do Fairness Ourselves", > draft-briscoe-tsvwg-relax-fairness-00 (work in progress), > November 2007. > > [P2PI.daigle] > Daigle, L., "Defining Success: Questions for the Future > of > the Internet and Bandwidth-Intensive Activities", P2PI > position paper LLD-P2P-Position-May15.pdf, May 2008. > > [P2PI.tschofenig] > Tschofenig, H. and M. Matuszewski, "Dealing with P2P > Traffic in an Operator Network: State of the Art", P2PI > position paper p2p-state-of-the-art.pdf, May 2008. > > [P2PI.hardie] > Hardie, T., "Peer-to-peer Traffic and "Unattended > Consequences", P2PI position paper hardie - p2pi position > paper.rtf, May 2008. > > [P2PI.rescorla] > Rescorla, E., "Notes on P2P Blocking and Evasion", P2PI > position paper rescorla-p2pi.pdf, May 2008. > > [P2PI.shalunov] > Shalunov, S., "Users want P2P, we make it work", P2PI > position paper BitTorrent-Position-IETF-P2P.pdf, May > 2008. > > [P2PI.moncaster] > Moncaster, T., Briscoe, B., and L. Burness, "Is There a > Problem with Peer-to-peer Traffic", P2PI position paper > Is > There a Problem with Peer-to-Peer Traffic.pdf, May 2008. > > [RIPE.feldmann] > Feldmann, A., "ISP-Aided Neighbor Selection in P2P > Systems", RIPE presentation at RIPE-56, Berlin, May 2008. > > [I-D.briscoe-tsvwg-re-ecn-tcp] > Briscoe, B., "Re-ECN: Adding Accountability for Causing > > > > Arkko Expires November 28, 2008 > [Page 8] > > Internet-Draft P2P and Incentives May > 2008 > > > Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-04 > (work in progress), July 2007. > > > Author's Address > > Jari Arkko > Ericsson > Jorvas 02420 > Finland > > Email: jari.arkko@piuha.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Arkko Expires November 28, 2008 > [Page 9] > > Internet-Draft P2P and Incentives May > 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on > an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST > AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE > OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Arkko Expires November 28, 2008 [Page > 10] > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue May 27 19:00: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 A3E013A696B; Tue, 27 May 2008 19:00: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 E99033A68C4 for ; Tue, 27 May 2008 19:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 lm+RqzdBKzfb for ; Tue, 27 May 2008 19:00:22 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CDB593A69DD for ; Tue, 27 May 2008 19:00:21 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id AC86D1986F0 for ; Wed, 28 May 2008 05:00:26 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4F2871986D8 for ; Wed, 28 May 2008 05:00:23 +0300 (EEST) Message-ID: <483CA2D7.2080708@piuha.net> Date: Tue, 27 May 2008 20:09:59 -0400 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: p2pi@ietf.org References: <483BD175.7090205@piuha.net> <81F82335-60FE-4B4A-91A6-A51A800E093E@cisco.com> In-Reply-To: <81F82335-60FE-4B4A-91A6-A51A800E093E@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [p2pi] Incentives and Deployment Considerations for P2PI Solutions X-BeenThere: p2pi@ietf.org X-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 Also available at http://www.arkko.com/publications/arkko-p2pi-incentives.txt Jari _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed May 28 03:15: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 91DEC28C114; Wed, 28 May 2008 03:15: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 43C0D3A6CB2 for ; Wed, 28 May 2008 03:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, J_CHICKENPOX_53=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 Dw7yjJy2JscI for ; Wed, 28 May 2008 03:15:24 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3772828C114 for ; Wed, 28 May 2008 03:15:23 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 11:15:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 11:15:09 +0100 Message-ID: In-Reply-To: <81F82335-60FE-4B4A-91A6-A51A800E093E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Incentives and Deployment Considerations for P2PI Solutions Thread-Index: AcjARwtVNSv9EpzdSeeqFn5Z68tUBwAZFqfA From: To: , X-OriginalArrivalTime: 28 May 2008 10:15:26.0182 (UTC) FILETIME=[BF51F860:01C8C0AB] Subject: Re: [p2pi] Incentives and Deployment Considerations for P2PI Solutions X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Just for everyones info, Bob's re-ECN draft is currently at version 05 (not 04 as quoted here): Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: 27 May 2008 23:16 > To: p2pi@ietf.org > Subject: [p2pi] Incentives and Deployment Considerations for > P2PI Solutions > > > One more paper ... > > Begin forwarded message: > > > From: Jari Arkko > > Date: May 27, 2008 5:16:37 AM EDT > > To: p2pi-com@ietf.org, Cullen Jennings > > Subject: later position paper submission > > > > > > I wrote this as a part of my preparations for the workshop. > > > > Jari > > > > > > > > > > Network Working Group J. > > Arkko > > Internet-Draft > > Ericsson > > Intended status: Informational > May 27, > > 2008 > > Expires: November 28, 2008 > > > > > > Incentives and Deployment Considerations for P2PI Solutions > > draft-arkko-p2pi-incentives-00 > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > > months > > and may be updated, replaced, or obsoleted by other > documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This Internet-Draft will expire on November 28, 2008. > > > > Abstract > > > > Several papers in this workshop have argued that there is > a need to > > build new protocol mechanisms to accommodate peer-to-peer > traffic in > > networks in the most efficient way and with minimal > impact to other > > traffic. This paper presents an analysis of such > solutions from the > > point of view of the incentives of the different parties > involved in > > peer-to-peer traffic. The paper concludes that it is essential to > > understand the incentives in order to have a deployable solution. > > > > > > 1. Introduction > > > > Peer-to-peer (P2P) networking has been cited as the > leading consumer > > > > > > > > Arkko Expires November 28, 2008 > > [Page 1] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > of network bandwidth in networks serving private > subscribers. This > > is by itself not a problem, as the network providers are in the > > business of providing a service to their customers, including the > > ones that employ P2P tools. However, the issue is whether P2P > > traffic causes undue congestion and reduced level of service for > > other customers in the network [I-D.briscoe-tsvwg-relax-fairness]. > > > > Historically, the Internet service provider market has > developed for > > interactive services where the bandwidth requirements for > each user > > vary significantly from over time. This allowed the service > > providers to employ statistical multiplexing. At the > same time, the > > nominal link speeds have been a major factor in marketing Internet > > service. But during the last few years, the nature of the traffic > > has changed from interactive to more always-on type traffic, for > > instance from P2P applications. As a result, statistical > > multiplexing is no longer effective, and service providers are > > finding that a large sets of users are actually trying to utilize > > their full link speed at all times. This is making the service > > providers either increase the capacity of their networks > to match > > the > > changing traffic mix and increasingly high broadband > service speeds, > > or find other ways to deal with the problems. > > > > It is important to see that these problems are not limited to P2P > > tools [P2PI.daigle]. Indeed, not even all P2P applications have > > these problems. Some forms of video communication > exhibit the same > > problems that large file sharing P2P applications do > [P2PI.hardie]. > > And as the Internet applications evolve, we expect to see > new forms > > of traffic with these issues. In the remainder of this paper, we > > assume any bandwidth-intensive, semi-permanently running > application > > that may or may not attempt to be friendly with other > network usage. > > > > The fairness problem can present itself in various ways. For > > instance, users opening multiple transport sessions may get a > > disproportionate share of a congested link. Permanent, high > > bandwidth sessions may slow down the ramp-up of short-term, > > interactive sessions. Or some users may utilize a > transit link far > > more than others, resulting in these users gaining a > larger share of > > the transit costs that the provider has to pay. > > > > These problems are not just abstract issues. There has > been highly > > publicized debates about what forms of traffic management are > > acceptable for network providers. In reality, network providers > > already employ a number of techniques [P2PI.tschofenig]. > Solutions > > addressing issues in this space have been worked on by network > > providers, vendors, and researchers. This paper looks at the > > different classes of solutions in Section 2 and analyzes > them based > > on the incentives of the involved parties in Section 3. The key > > issue is finding a solution that provides immediate benefits to > > > > > > > > Arkko Expires November 28, 2008 > > [Page 2] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > everyone who needs to add new mechanisms or equipment. > Another key > > issue is the information available to different parties. > This leads > > us to make conclusions in Section 4. > > > > > > 2. Solution Classes > > > > A number of solutions have already been deployed to > mitigate issues > > caused by the changed traffic pattern. Other solutions > are actively > > being worked on. We divide the solutions in three rough classes, > > based partially on similar classifications in [P2PI.tschofenig] > > [P2PI.moncaster]: > > > > Contractual > > > > These solutions are based on choosing pricing models and > > contractual conditions that persuade users to avoid always-on > > traffic. For instance, volume-based accounting can be > employed, > > or the contracts of the heaviest users can be discontinued. > > > > Voluntary changes in applications > > > > These solutions are based on some change of behaviour in the > > applications, leading to taking other users better > into account, > > reducing congestion or the use of expensive links, and so on. > > > > Some of the solutions in this category include: > > > > * Indicating the desired quality of service, so that > interactive > > and always-on applications can be distinguished in > the network > > [P2PI.moncaster]. This assumes that there is a > basic level of > > quality of service filtering capabilities in the network. > > > > * Making decisions with better information about the network > > topology and cost. For instance, algorithms that P2P > > applications use to determine which peers to talk to can > > probably be improved. One particular class of improvements > > involves "oracles" in the service provider network to help > > applications determine the most likely peers with good > > connectivity. For instance, peers that are in the local > > service provider network vs. behind an expensive and/or > > congested transit service provider. > > > > * New congestion control mechanisms. For instance, BitTorrent > > has gotten positive results from their new algorithm > > [P2PI.shalunov]. Another example is Bob Briscoe's re-ECN > > mechanism [I-D.briscoe-tsvwg-re-ecn-tcp], which allows hosts > > and networks to co-operate in the treatment of > congestion, and > > > > > > > > Arkko Expires November 28, 2008 > > [Page 3] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > allows networks to treat different users in a fair manner. > > > > Network-based mechanisms > > > > These mechanisms are implemented solely in the > network. Examples > > include: > > > > * Prioritization, slowdown, or even blocking of > traffic based on > > packet header information. Relatively complicated designs > > that > > peek further into the packet, Deep Packet Inspection (DPI) > > have > > also been deployed. Priorities can also be set > based on user > > accounting information, e.g., traffic shaping heavy users > > during a rush hour. > > > > * Changing the "scheduling algorithm", by attempting > to complete > > the short jobs first everyone's performance will improve. > > Similar techniques as discussed above are needed to > determine > > which jobs are "short" and "long", however. > > > > * Building caches and peer-to-peer network components in the > > service provider network. > > > > > > 3. Incentives > > > > This section discusses motives, deployment considerations, and how > > information available to the different parties affects the > > incentives. > > > > 3.1. Motives > > > > For any solution to be adopted the involved parties have to have > > compatible motives. This is not always trivial, because > the parties > > may either optimize for different goals, or because there > is room > > for > > malicious behaviour. > > > > For instance, one type of a quality-of-service solution involves > > voluntary marking of packets by applications and subsequent > > differentiated treatment of these packets by the network. In this > > case the motives of well-behaving users and service providers are > > similar: both want interactive applications to be given more > > priority, while allowing always-on batch applications to > run in the > > background, and take as much bandwidth as is available. > However, if > > the prioritization happens across multiple users, this > also implies > > that a lower priority marking has the potential to reduce > the user's > > share of the overall throughput. Clever users can distort the > > system > > by claiming to run only interactive applications. A > tragedy of the > > commons follows: The optimal strategy from the point of > view of the > > > > > > > > Arkko Expires November 28, 2008 > > [Page 4] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > entire group of users would be to correctly classify traffic. But > > from the point of an individual user a better strategy would be to > > lie. > > > > Note that no misbehaviour is needed from a human user for this to > > happen. It is enough that the user runs applications > that do this. > > And if such applications appear to produce better results > than other > > applications, the user has an incentive to use them. Having said > > this, past experience tells us that a vast majority of networking > > software plays by the rules. Attempts to improve or bypass TCP > > congestion control are relatively rare, for instance. > > > > An example where the motives themselves may be conflict is the co- > > operation between P2P applications and service providers to > > determine > > the "best" peers to connect to. The definition of "best" from the > > P2P client perspective is a peer that has the highest possible > > actual > > transfer rate. But the service provider is more interested in > > minimization of their costs and overall network > congestion. This > > may > > or may not coincide with the client's desires. For instance, a > > service provider may prefer a local peer with a slow access link > > over > > a remote peer that is connected via an expensive transit > connection. > > > > While not part of the incentives, the available information to the > > different parties plays an interesting role as well. It can be > > expected that P2P nodes are capable of measuring actual transfer > > rates across the end-to-end path, including the behaviour > of the end > > systems. P2P applications might even be able to accumulate this > > information from multiple clients and over time. In contrast, the > > service provider network at its basic form would be limited to > > understanding the topology and link speeds. More advanced service > > provider networks may be capable of traffic-engineering > and tracking > > congestion in different parts of their network. However, they are > > fundamentally incapable of measuring end systems or end-to-end > > behaviour in paths that cross multiple networks. > > > > As a result of the motive conflict and lack of information, any > > "oracle" style design [RIPE.feldmann] needs to play a > fairly limited > > role in supplying additional information to the P2P applications. > > Information from the service provider network can help make an > > initial guess or to narrow the search for the best peer. But it > > cannot replace or govern the overall decision that the P2P > > application needs to make on its own. > > > > Having basic support for peer selection in the P2P > applications also > > allows the service providers to focus on improvements in their own > > network, as opposed to attempting to build tools that try to guide > > selection of peers across multiple networks. As long as > the oracle > > focuses on increasing the number of peers within the service > > > > > > > > Arkko Expires November 28, 2008 > > [Page 5] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > provider's network, the algorithms in P2P applications > can take care > > of optimizing the connectivity to peers in other networks. > > > > 3.2. Deployment Considerations > > > > Another important consideration is what needs to change > in order for > > a particular solution to be deployed. Some solutions can be > > deployed > > unilaterally, some require coordinated action. The > coordination may > > act as a disincentive to build support for a particular solution. > > For instance, P2P application developers do not invest time in > > building support for contacting an oracle in the service provider > > network until it becomes likely that such oracles can > actually used > > in some fraction of networks; the limited development > resources are > > better invested in actions that the developers are in > full control > > of > > -- for instance in improved peer selection algorithms that do not > > depend on new infrastructure nodes. Similarly, service > providers do > > not invest in an oracle until there is software that actually uses > > it. > > > > This problem affects the following types of solutions: > > > > o Quality of service marking in the host and priority > treatment in > > the network. > > > > o Network-assisted P2P peer selection. > > > > o Network-assisted congestion control mechanisms. > > > > 3.3. Availability of Information > > > > Section 3.1 discussed how available information affects > the way best > > peer selection can be made to work. But there are other > aspects of > > information availability as well. Specifically, when > networks have > > unilaterally implemented mechanisms that do not align with the > > motives of P2P applications, the applications have employed > > information hiding in order to prevent the network from > making non- > > desireable prioritization decisions for them. Eric Rescorla makes > > the argument that ultimately P2P traffic can be secured > and made to > > resemble other types of traffic, such as VPN traffic. > This makes it > > very hard for the network to de-prioritize or modify P2P traffic > > [P2PI.rescorla]. It is interesting that many of the solutions in > > this workshop attempt to increase the amount of information > > available > > to the parties, while in reality the converse seems to happen. > > > > We would like to suggest that this trend can only be > reversed if the > > motives becomes more aligned between the players. That is, no P2P > > application will participate in a system designed to restrict P2P > > traffic. But they may participate in systems that attempt to > > > > > > > > Arkko Expires November 28, 2008 > > [Page 6] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > optimize P2P traffic. > > > > > > 4. Conclusions > > > > The right incentives are a key to the successful > standardization and > > deployment of any solution in this space. Based on our > analysis, we > > would like to suggest that the following avenues for IETF > > documentation and standards be looked at: > > > > o Improved and/or standardized peer selection > algorithms. These > > can > > be deployed unilaterally by application developers. > > > > o Co-operative designs where service provider networks supply > > additional information that helps the P2P applications > to make a > > better initial selection of peers. This should only > be done as a > > sub-item to the above one; service provider networks > do not have > > sufficient information or incentives to make the full decision, > > and attempting to do so would dissuade the P2P > applications from > > using such a system. > > > > o Improved and/or standardized congestion control mechanisms > > suitable for P2P and other "always-on" applications. Again, > > these > > can be deployed unilaterally, and IETF can help ensure they > > algorithms are safe for other traffic in the Internet. > Note the > > difference to quality of service mechanisms that typically > > require > > deployment at both ends; the quality of service > mechanisms would > > in many ways be the right solution for this problem, but it is > > hard to get them deployed and used due to the issues mentioned > > earlier in this paper. > > > > Still, both the co-operative designs and congestion control > > mechanisms depend on the interest of the P2P application > > developers and users. The primary incentive from their > > perspective is the desire to be nice for the user's other > > traffic. > > > > In any case, these items are tactical, short-term > efforts. There is > > an associated longer-term issue where the market place > has to learn > > to provide services without relying on statistical multiplexing. > > Ultimately, if there is demand for communication services > > (interactive or not) it should be met with an offering that allows > > providers to build the infrastructure needed to support it, and > > still > > be profitable. Pricing models and service packaging has perhaps > > even > > more to do with this than technical solutions. > > > > > > > > > > > > > > > > Arkko Expires November 28, 2008 > > [Page 7] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > Appendix A. Acknowledgments > > > > The author would like to thank Magnus Westerlund and Gonzalo > > Camarillo for interesting discussions in this problem space. > > > > > > 5. Informative References > > > > [I-D.briscoe-tsvwg-relax-fairness] > > Briscoe, B., Moncaster, T., and A. Burness, "Problem > > Statement: We Don't Have To Do Fairness Ourselves", > > draft-briscoe-tsvwg-relax-fairness-00 (work in > progress), > > November 2007. > > > > [P2PI.daigle] > > Daigle, L., "Defining Success: Questions for > the Future > > of > > the Internet and Bandwidth-Intensive Activities", P2PI > > position paper LLD-P2P-Position-May15.pdf, May 2008. > > > > [P2PI.tschofenig] > > Tschofenig, H. and M. Matuszewski, "Dealing with P2P > > Traffic in an Operator Network: State of the Art", P2PI > > position paper p2p-state-of-the-art.pdf, May 2008. > > > > [P2PI.hardie] > > Hardie, T., "Peer-to-peer Traffic and "Unattended > > Consequences", P2PI position paper hardie - > p2pi position > > paper.rtf, May 2008. > > > > [P2PI.rescorla] > > Rescorla, E., "Notes on P2P Blocking and Evasion", P2PI > > position paper rescorla-p2pi.pdf, May 2008. > > > > [P2PI.shalunov] > > Shalunov, S., "Users want P2P, we make it work", P2PI > > position paper BitTorrent-Position-IETF-P2P.pdf, May > > 2008. > > > > [P2PI.moncaster] > > Moncaster, T., Briscoe, B., and L. Burness, "Is There a > > Problem with Peer-to-peer Traffic", P2PI > position paper > > Is > > There a Problem with Peer-to-Peer Traffic.pdf, > May 2008. > > > > [RIPE.feldmann] > > Feldmann, A., "ISP-Aided Neighbor Selection in P2P > > Systems", RIPE presentation at RIPE-56, > Berlin, May 2008. > > > > [I-D.briscoe-tsvwg-re-ecn-tcp] > > Briscoe, B., "Re-ECN: Adding Accountability for Causing > > > > > > > > Arkko Expires November 28, 2008 > > [Page 8] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > Congestion to TCP/IP", > draft-briscoe-tsvwg-re-ecn-tcp-04 > > (work in progress), July 2007. > > > > > > Author's Address > > > > Jari Arkko > > Ericsson > > Jorvas 02420 > > Finland > > > > Email: jari.arkko@piuha.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Arkko Expires November 28, 2008 > > [Page 9] > > > > Internet-Draft P2P and Incentives > May > > 2008 > > > > > > Full Copyright Statement > > > > Copyright (C) The IETF Trust (2008). > > > > This document is subject to the rights, licenses and restrictions > > contained in BCP 78, and except as set forth therein, the authors > > retain all their rights. > > > > This document and the information contained herein are > provided on > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST > > AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS > > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY > THAT THE USE > > OF > > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > Intellectual Property > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might > be claimed > > to > > pertain to the implementation or use of the technology > described in > > this document or the extent to which any license under such rights > > might or might not be available; nor does it represent that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission > for the use > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR > repository > > at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > > > > > > > > > > > > > > > > > > > Arkko Expires November 28, 2008 > [Page > > 10] > > > > _______________________________________________ > 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 May 28 08:31: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 79B9A3A6830; Wed, 28 May 2008 08:31: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 1A0C93A6830 for ; Wed, 28 May 2008 08:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 i76YE9tHzkjh for ; Wed, 28 May 2008 08:31:02 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 387773A67D4 for ; Wed, 28 May 2008 08:31:02 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.46201345; Wed, 28 May 2008 11:30:57 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 11:30:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 11:29:21 -0400 Message-ID: <45AEC6EF95942140888406588E1A66020413D88A@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides from Comcast Presentation Thread-Index: Aci6tE9Wg3KLbXcpTaOvciuRQGRXQQGI0qYI References: <31D151A3D66E404AACBBB0247ACA54A70185A2D0@STNTEXCH11.cis.neustar.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 28 May 2008 15:30:57.0426 (UTC) FILETIME=[D3388F20:01C8C0D7] Subject: [p2pi] Slides from Comcast Presentation X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I am sure the Jon and Cullen will post everyone's presentation at some point. In the meantime, you can download our presentation from this morning at: http://ietf71.comcast.net/wp-content/files/Comcast-IETF-P2Pi-20080528.pdf Thanks Jason Livingood & Rich Woundy Comcast _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed May 28 13:51: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 AAD0A3A6ABB; Wed, 28 May 2008 13:51: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 176103A6AAB for ; Wed, 28 May 2008 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 LL0VGV2sRDYV for ; Wed, 28 May 2008 13:51:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 179093A6872 for ; Wed, 28 May 2008 13:50:02 -0700 (PDT) Received: from s73602 (EGG-FIVE-O-FIVE.MIT.EDU [18.105.6.250]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1K1Sb01mIF-0003uT; Wed, 28 May 2008 16:50:08 -0400 Message-ID: <033801c8c104$9471e020$6401a8c0@china.huawei.com> From: "Spencer Dawkins" To: Date: Wed, 28 May 2008 15:51:15 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+Pt6Ex/fcoUTEk+q+A7dg9m7tZrnvqAj+5iEs zdaegebIbrjbNo+wN2Ani+5Xb8BhcoJG17RjhjJ6W2TyLu6Xgk K8ascj9yy6IpDjUjjX4RrdWO9p5OtUuGh9OonL7jF4= Subject: [p2pi] My notes from today's workshop X-BeenThere: p2pi@ietf.org X-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="===============1416304873==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1416304873== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0335_01C8C0DA.A933FFE0" This is a multi-part message in MIME format. ------=_NextPart_000_0335_01C8C0DA.A933FFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here's what I captured... Spencer 3.1 Welcome/Note Well/Intro Slides Goals: =B7 To think about the Comcast/BitTorrent problem. =B7 To think about what the IETF might do to work on the problem = =B7 Focus on what's actionable for the IETF, engineering, not = research or politics. "Not dealing with illegal traffic" - Cullen asked us to focus on the = problems that we still have when all the traffic is legal. 3.2 Service Provider Perspective (Comcast) Presenters are Jason Livingood and Richard Woundy from Comcast = (including attributions because they're presenting a sponsor's = perspective0. View that this is a two-way street - applications becoming more = network-friendly, networks becoming more application-friendly.=20 Comcast has committed to implement a protocol-agnostic network = management technique (by yearend). Comcast was managing Vonage customer traffic, and customers were = complaining. Not all the complaints reflected this management (Comcast = and Vonage both experienced problems with transit providers), but that = wasn't obvious to customers. Most ISPs started managing P2P traffic about 2-3 years ago. When = Comcast started managing its traffic, they stopped getting complaints = from Vonage and from P2P users. The recent concerns have involved a = suspicion that Comcast was degrading Vonage VoIP service in an attempt = to favor Comcast's own VoIP products. Current DOCSIS can experience congestion independently on upstream and = downstream and experience congestion independently across DOCSIS = domains. We talked about some DOCSIS details, but remember that we have to solve = problems for a broad class of access networks, not just for DOCSIS. Slide point: "How 'TCP flow fairness' applies to the DOCSIS upstream is = an open research question". DOCSIS also has constant-bandwidth "service flows" (so you don't need to = request-to-send every packet). A Canadian cable company charges extra to = set up a second service flow for Vonage, but other cable companies = haven't followed this lead because of concerns about "net neutrality".=20 We did note that if you have enough bandwidth, you don't need to = prioritize traffic, but this doesn't help when traffic levels increase = suddenly ("network capacity increases are not instantaneous"), and = capacity increases can be consumed quickly. Not all customers are similar (even at the DOCSIS domain level) - = college populations use more P2P, VoIP/streaming video are more diurnal = than bulk file distribution. Comcast would like to avoid protocol-specific "cat and mouse" detection = and mitigation, and would like to avoid capacity increases that benefit = only 5 percent of heavy users. DOCSIS 3.0 adds capacity but doesn't solve the capacity problem. Comcast = will deploy DOCSIS 3.0 in 20 percent of network by yearend. This more = than doubles bandwidth available per subscriber, but the conflict is = between adding capacity and supporting applications that are designed to = maximize bulk bandwidth consumption. There are Internet2 techniques for client-to-network signaling that = haven't been standardized in IETF yet. Caching content in the network can reduce TCP RTTs and reduce the = peak-to-trough differences of individual flows. Network management trials begin in June - management based on traffic = characteristics, not on specific protocols. Algorithm - mark all flows = as priority and then mark specific flows as "best-effort" when = congestion approaches "the Near Congestion State". Comcast hasn't figured out how to notify users that they have been = marked as best-effort yet. BT is planning a similar mechanism on their DSL network, but they are = planning on varying the bandwidth, not changing QoS markings. Comcast = thinks customers are more concerned about changing markings and don't = want to penalize high-bandwidth users when the network is NOT congested = ("it's a high-bandwidth service, people should use it"). Henning is concerned about mechanisms that have 8 independent tweakable = parameters. Comcast does still care about protocol-specific management mechanisms, = when the carrier is providing the application, or when the traffic is = illegal, etc. 3.3 Application Designer Perspective (BitTorrent) Presenter is Stanislov Shalunov. BitTorrent is willing to make changes based on outcomes at this = conference. BitTorrent sees two problems - RTT measured in seconds, inefficient = overlay routing. Peer selection is random, except that there is some bias towards = established peers. Trackers randomize the peer list, and peers ask the = resulting randomized list what peers they know about. Rarest-first = ensures best reliability and helps peers have pieces of files to = "trade". This also gives peer diversity. The best peers can be farther away - a peer with a big pipe, a long way = away, can drive you at your downlink speed, but a peer on your own cable = modem subnet can only drive you at its uplink speed. Danny's comment - restated for minutes: "If you have more localized = distribution via caching, or location techniques, or whatever, then = burst rates (i.e., peak <> trough ratios) may actually be larger and you = may increase HFC contention (note: HFC in particular, v. DSL, etc..)" Overlay efficiency - Stanislov is experimenting with trying peers on = same AS, or on a set of ASes (but then you need the set), or in a list = of IP prefixes (but then you need the list), or based on some cost = minimization model (but then you need costs). If you have more than 20 peers in an AS, you can probably trade files = happily, and 57 percent of transit traffic could be reduced with this = modification. If there aren't enough local peers, make one a cache (and = please choose a fast one), or 10, or 100. Stanislov's experience is that they can do 30-percent hit rate with 1 = TByte cache, 80-percent with 100 TBytes - and 1 TByte fits into a = device. Dave Oran asked what the required bandwidth for an 80-percent hit rate = of 1 TByte is - he is concerned that this architecture may reveal = bandwidth bottlenecks onto and off the cache device itself. Stanislov hopes the IETF can work in these areas: =B7 Cache discovery protocol =B7 Network information for smart peer selection =B7 Experimental congestion control =B7 BCP on P2P pain Stanislov doesn't think we're ready to do congestion control for P2P yet = - do a framework, but don't standardize the mechanism yet. Lars says there's a TSV committee looking at new congestion control = mechanisms, but the participants are all from the long-delay community. Current BitTorrent cache discovery protocol is DNS-based, with an SRV = record based on the reverse DNS lookup of your IP address. Dave Oran asked for input from DSL and Metro-Ethernet network operators, = because he sees the network characteristics being radically different, = and the problem he sees on deployed networks is under-provisioned = aggregation network links. 3.4 Lightning Talks & General Discussion 3.4.1 Robb Topolski This talk covers about a third of Robb's submitted paper. Robb believes that the common accusations about P2P file-sharing aren't = actually true - for example, it's very rare for any applications to = rate-limit, so almost all applications will use all available bandwidth. We need to know a lot more about the problems we're facing (including = "where congestion actually is") in order to solve problems, instead of = simply dealing with effects. 3.4.2 Nick Weaver The problem with P2P filesharing is that it shifts cost, doesn't save = costs. It increases aggregate costs, and it's transport-inefficient. Could easily build a BitTorrent cache today - all the components are in = place. But it's less efficient than HTTP, and it's lawsuit-bait for = pirated content.=20 3.4.3 Leslie Daigle "The open, decentralized nature must be preserved." The problems aren't about P2P technology itself. There's an assumption = that network operators won't/can't adjust the network to meet demand (as = P2P supernodes move). What are we trying to do: =B7 Make P2P networks work better? =B7 Make applications and networks more aware of each other? =B7 Solve the general-case of bandwidth-intensive applications? =B7 Deal with in-network issues or impact of cross-network = traffic? 3.5 Localization and Caches 3.5.1 Laird Popkin and Haiyong Xie - P4P=20 Average P2P bit travels 5-7 metro hops in Verizon networks - = network-oblivious P2P applications may not be network-efficient. Routing = information is hidden, TCP rate control is coarse-grained.=20 P4P goal is to design a framework that enables better cooperation = between providers and applications. P4P tracker provides static topologies, policies, provider capabilities, = virtual cost. Virtual costs can be distributed based on provider preferences, but they = are talking to providers about 5-minute refresh windows (for scaling = reasons). Costs are provided by the providers (not currently tied to = routing, but could be if someone wants to provide a feed from routing). Trials at Verizon and Telefonica showed significant increases in = intra-ISP traffic, including increase in "local" traffic based on IP = prefixes. This was a large swarm (3500 peers at the peak, 300 after a = few days). Possible IETF work - "trackerless P2P" (DNS), lookup mechanisms to find = AS-PIDs and trackers for a given ASN. Jon asked for information about what IETF protocols are being modified. Henning said it would be nice to have everyone work together, but IETF = is slow. P4P Forum doesn't think they are doing a standard, they think = they are validating a concept. 3.5.2 Yu-Shun Wang - P2PI Traffic Localization - Microsoft Lots of reasons to localize - apply QoS policy, throttling, admission = control - but localization makes the user experience "non-uniform". Using multi-layer trackers (global, local, anything in between). Want to be "local" - but may have to accommodate traffic conditions, = load balancing, policy, etc. Need the right metrics - the policy might = be NOT to localize. Most of focus is on topology matching between link layer and application = layer. Caches are easy (long-lived peers) but caches have to be in the = right place in order to gain benefits. Looking at tracker redirection/delegation. Prefer off-path for = reliability and avoiding performance bottlenecks. Eric Burger asked what incentive people have to deploy a mechanism like = this. Jon liked this paper/presentation because it seemed easy to chop into = engineering-sized parts. Bob raised a concern about ISP liability if they are helping pirates = choose optimal paths for particular swarms, but if you provide = information for all users in all swarms, this isn't scalable. 3.5.3 Vinay Aggrawa - ISP-aided Neighbor Selection - DT Vinay is talking about something that's similar to P4P - having a = provider supply an oracle so that any peer can find its "local = neighbors". Henning is concerned about oracles that dump traffic off-net, and beggar = their neighbors. Dave Oran thought the oracle would also know who was talking to who now = - and this approach doesn't have that information yet. People are thinking that 9000 nodes is a big swarm - for legal content = with advertising, it probably isn't. We need to think about much larger = swarms. Could just run oracle as web server/UDP server at well-known location = (similar to BIND). Open and simple solution, open for all overlays. Oracle service doesn't cache content at ISP, doesn't participate in file = sharing. Are ISPs willing to accept approaches like oracles that rely on = interaction with clients? They've resisted this in the past. 3.5.4 Cullen - IETF work on localization? (Cullen had a slide of possible work from listening to presentations and = questions/answers) Leslie - still need to decide what problem we're trying to solve. EKR - people talked about making clients less aggressive, moving data = into caches so it doesn't consume uplink capacity, and choosing better = peers. All of Cullen's list was about localization. Doesn't seem that = localization would be important to Comcast, and I'm terrified of the = legal issues involved in caching. Would be useful for nodes to find their own locations in a topology - = find own AS numbers, etc. Henning - providing information that customers can't verify, can lead to = undesirable situations (like "hot-potato" in routing). Standardize a protocol to delegate from global trackers to local = trackers? Lisa says lots of HTTP servers have their own mirror mapping = information distribution mechanisms (proprietary). It's possible this = would be reusable, but possible that the two problem spaces are just too = different. Lisa also had concerns about layer-nine concerns with inter-ISP = localization issues. Why not look at the entire problem, and not just parts by parts? We did = IM as an application, and Google is starting to use the standardized = versions. Jon thinks that IM came into the IETF in just the way he's = thinking of for P2P - what are the parts we need? Lars - we have transport technologies that aren't seeing deployment. = Maybe incentives have changed, but something would have to change in = order for new transport stuff to be deployed. Localized changes, at the = point that benefits from the change, do get deployed. Lisa is concerned that localization is one of the technologies that can = work in practice, in a limited environment, but can't be standardized - = because of issues about trust, accuracy, etc. 3.6 New Approaches to Congestion 3.6.1 Bob Briscoe Bob is presenting Diffserv weighted scheduling versus weighted = congestion points.=20 Diffserv is typically used without an API, so the application itself = does nothing about Diffserv. Diffserv isn't designed to work at the granularity of individual users. When a light user sends to a heavy user, the light user is using up = Diffserv limits in his own network, only for the traffic to be marked = down in the heavy user's network. Bob is concerned that we're going to end up in the same place as ATM - = with too many traffic classes. Bob proposes a "congestion harm (cost) metric".=20 Is this anything like Comcast's proposal earlier in the workshop? = Important to take what ISPs are doing now into account as we plan years = into the future. ECN is helpful but ingress policer can't see congestion on the rest of = the path.=20 Bob is asking the IETF/IRTF to set up a longer-term design team for = congestion. 3.6.2 Marcin Matusze This presentation is based on conversations with about 20 ISPs. ISP customer acquisition costs are much higher than monthly revenue, and = cost structure varies (fixed versus mobile). It's difficult to change = contracts, and 5 percent of users generate 75 percent of the traffic. Mobile network operators have more tools (volume-based accounting, fixed = pricing up to a limit). Most tools aren't widely used. BT is starting to use deep packet inspection, and Bob says that's 10 = times more cost-effective than adding bandwidth. Finnish ISPs were very concerned about P2P traffic in 2004, but much = less concerned today. 3.7 Quality of Service 3.7.1 Mary Barnes - QoS-enabled traffic prioritization Many service providers are implementing deep packet inspection, but this = isn't viable long-term. Diffserv can be implemented today but doesn't solve all the problems, = and provisioning/managing still has to look at the events that cause = peak usage. Why hasn't Diffserv been deployed in the past? Maybe the problem is big = enough now? Bob says data is showing that the amount of P2P traffic in = the world is decreasing. People are using QoS - just not on the Internet. More than 50 percent of = Cisco's enterprise users have turned Diffserv on - actually higher than = that, for enterprise VoIP or video users. There's a real problem with = DSLAMs with very limited processing capabilities - Dave Oran made the = point that the problems in layer-two aggregation networks are severe and = overlooked. 3.7.2 Henning Schulzrinne - encouraging bandwidth efficiency Average TV consumption in North America for HDTV =3D 972 GBytes per = month - reasonable upper limit. Goal is to minimize OVERALL cost of content delivery. Focusing only on = HTTP efficiency misses the point.=20 Transit bandwidth trends changed in 2004 - from a steady decline to very = little change since 2004. Cost for sharing content is a step function - moving from the = neighborhood to a national distribution requires different = infrastructure. FIOS TV architecture is very different from the CATV architecture = discussed this morning.=20 We have a general discovery problem (network topology, STUN, HELD, LoST, = SIP local network configuration.). We have a variety of solutions (DHCP, = DNS, anycast.) If you're volume-based, you need application-visible charging indication = to allow people to make rational decisions. Can the IETF help here? Misbehaving applications expose user to risk in a charging situation. 3.8 Conclusions & Wrap Generalized "talking to your local infrastructure" mechanism keeps = coming up, over and over. Indication of charging would be machine-parsed for any "rational actor" = - person or machine. Eric is concerned that we're identifying so many topics that are = application-specific and hard-to-too-hard to generalize into a transport = mechanism.=20 Jon thinks P4P "virtual costs" makes sense as something we can extract = out. Do we need more than "this will be expensive/this will be cheap"? "I'd be happy to tag low-priority traffic if that made any difference to = me" - if ISPs are putting bandwidth caps in place and scavenger-class = traffic didn't count, that would make a difference. Congestion control isn't going to fix the cost issue - if we aren't = going to grow a network to accommodate increased traffic, we're just = deciding what order the packets queue in. The IETF needs to decide = what's about economics and what's about technology. Can we stop whining about P2P using too many TCP connections?=20 Is it possible to please all the parties? What if benefits to users and = benefits to ISPs are just incompatible? We need to be very cautious about matching up network protocols and = economic models - this usually ends badly (micropayments, etc). Focus on = technical topics (congestion, etc).=20 Congestion arises when there's a scarcity, and you allocate resources = based on cost (which may be money, or might be pain). Congestion isn't = different from cost - ISPs know that. Just because cost proposals = haven't worked in the past doesn't mean there's no way to address cost. Greg - worth IETF attention, momentum around caching, momentum around = optimizing peer selection. Good to think about whether we bring all of = the work in at once. On deep packet inspection, as a vendor, unless you = want to trust host markings, first-hop routers have to inspect packets = and that's not cheap. Cullen - Microsoft API will default-mark voice traffic above router = traffic in priority. Unless we get our act together we're headed for a = train wreck. Danny - IETF might want to consider guidelines on application = interaction with transport issues (multiple ports, etc). Mobile networks = have all kinds of differential pricing (nights and weekends), but other = providers have no hooks into charging for things like distance (even = though it might cost the provider more to retrieve a file from Japan). Lars - a lot of the things we're talking about aren't just P2P - IPTV = (for example) might have many of the same issues. What are the other = heavy bandwidth usages of the network? Bob - congestion isn't cost until it becomes part of the contract that = you have with a provider - and providers can't see congestion outside = the provider's own network. Eric - in economics, pricing is a protocol and tells you when you should = spend money. We need to remember that P2P is about content, too - = networks that were engineered for small-request/large-response = applications are now carrying servers from grandmothers. Stanislov - opening multiple TCP connections isn't the problem - delay = is the same for P2P and Facebook. (This got responded to: this is only = the case when you're the only user on the link - but other applications = open multiple links, too. Quoting Dave Oran - "there are non-evil = reasons to open multiple TCP connections and you can't tell them = apart"). ------=_NextPart_000_0335_01C8C0DA.A933FFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Here's what I = captured...

Spencer

3.1          =20 Welcome/Note Well/Intro Slides

Goals:

=B7        =20 To think about the Comcast/BitTorrent problem.

=B7        =20 To think about what the IETF might do to work on = the=20 problem

=B7        =20 Focus on what=92s actionable for the IETF, = engineering, not=20 research or politics.

=93Not dealing with = illegal=20 traffic=94 =96 Cullen asked us to focus on the problems that we still = have when all=20 the traffic is legal.

3.2          =20 Service Provider Perspective = (Comcast)

Presenters are Jason = Livingood=20 and Richard Woundy from Comcast (including attributions because = they=92re=20 presenting a sponsor=92s perspective0.

View that this is a = two-way=20 street =96 applications becoming more network-friendly, networks = becoming more=20 application-friendly.

Comcast has = committed to=20 implement a protocol-agnostic network management technique (by = yearend).

Comcast was managing = Vonage=20 customer traffic, and customers were complaining. Not all the complaints = reflected this management (Comcast and Vonage both experienced problems = with=20 transit providers), but that wasn=92t obvious to customers.

Most ISPs started = managing P2P=20 traffic about 2-3 years ago.  = When=20 Comcast started managing its traffic, they stopped getting complaints = from=20 Vonage and from P2P users. The recent concerns have involved a suspicion = that=20 Comcast was degrading Vonage VoIP service in an attempt to favor = Comcast=92s own=20 VoIP products.

Current DOCSIS can = experience=20 congestion independently on upstream and downstream and experience = congestion=20 independently across DOCSIS domains.

We talked about some = DOCSIS=20 details, but remember that we have to solve problems for a broad class = of access=20 networks, not just for DOCSIS.

Slide point: =93How = =91TCP flow=20 fairness=92 applies to the DOCSIS upstream is an open research = question=94.

DOCSIS also has=20 constant-bandwidth =93service flows=94 (so you don=92t need to = request-to-send every=20 packet). A Canadian cable company charges extra to set up a second = service flow=20 for Vonage, but other cable companies haven=92t followed this lead = because of=20 concerns about =93net neutrality=94.

We did note that if = you have=20 enough bandwidth, you don=92t need to prioritize traffic, but this = doesn=92t help=20 when traffic levels increase suddenly (=93network capacity increases are = not=20 instantaneous=94), and capacity increases can be consumed quickly.

Not all customers = are similar=20 (even at the DOCSIS domain level) =96 college populations use more P2P,=20 VoIP/streaming video are more diurnal than bulk file distribution.

Comcast would like = to avoid=20 protocol-specific =93cat and mouse=94 detection and mitigation, and = would like to=20 avoid capacity increases that benefit only 5 percent of heavy users.

DOCSIS 3.0 adds = capacity but=20 doesn=92t solve the capacity problem. Comcast will deploy DOCSIS 3.0 in = 20 percent=20 of network by yearend. This more than doubles bandwidth available per=20 subscriber, but the conflict is between adding capacity and supporting=20 applications that are designed to maximize bulk bandwidth = consumption.

There are Internet2 = techniques=20 for client-to-network signaling that haven=92t been standardized in IETF = yet=85

Caching content in = the network=20 can reduce TCP RTTs and reduce the peak-to-trough differences of = individual=20 flows.

Network management = trials begin=20 in June =96 management based on traffic characteristics, not on specific = protocols. Algorithm =96 mark all flows as priority and then mark = specific flows=20 as =93best-effort=94 when congestion approaches =93the Near Congestion = State=94.

Comcast hasn=92t = figured out how=20 to notify users that they have been marked as best-effort yet.

BT is planning a = similar=20 mechanism on their DSL network, but they are planning on varying the = bandwidth,=20 not changing QoS markings. Comcast thinks customers are more concerned = about=20 changing markings and don=92t want to penalize high-bandwidth users when = the=20 network is NOT congested (=93it=92s a high-bandwidth service, people = should use=20 it=94).

Henning is concerned = about=20 mechanisms that have 8 independent tweakable parameters=85

Comcast does still = care about=20 protocol-specific management mechanisms, when the carrier is providing = the=20 application, or when the traffic is illegal, etc.

3.3          =20 Application Designer Perspective = (BitTorrent)

Presenter is = Stanislov=20 Shalunov.

BitTorrent is = willing to make=20 changes based on outcomes at this conference.

BitTorrent sees two = problems =96=20 RTT measured in seconds, inefficient overlay routing.

Peer selection is = random, except=20 that there is some bias towards established peers. Trackers randomize = the peer=20 list, and peers ask the resulting randomized list what peers they know = about.=20 Rarest-first ensures best reliability and helps peers have pieces of = files to=20 =93trade=94. This also gives peer diversity.

The best peers can = be farther=20 away =96 a peer with a big pipe, a long way away, can drive you at your = downlink=20 speed, but a peer on your own cable modem subnet can only drive you at = its=20 uplink speed.

Danny=92s comment = =96 restated for=20 minutes: =93If you have more localized distribution via caching, or = location=20 techniques, or whatever, then burst rates (i.e., peak <> trough = ratios)=20 may actually be larger and you may increase HFC contention (note: HFC in = particular, v. DSL, etc..)=94

Overlay efficiency = =96=20 Stanislov  is = experimenting with=20 trying peers on same AS, or on a set of ASes (but then you need the = set), or in=20 a list of IP prefixes (but then you need the list), or based on some = cost=20 minimization model (but then you need costs).

If you have more = than 20 peers=20 in an AS, you can probably trade files happily, and 57 percent of = transit=20 traffic could be reduced with this modification. If there aren=92t = enough local=20 peers, make one a cache (and please choose a fast one), or 10, or = 100.

Stanislov=92s = experience is that=20 they can do 30-percent hit rate with 1 TByte cache, 80-percent with 100 = TBytes =96=20 and 1 TByte fits into a device.

Dave Oran asked what = the=20 required bandwidth for an 80-percent hit rate of 1 TByte is =96 he is = concerned=20 that this architecture may reveal bandwidth bottlenecks onto and off the = cache=20 device itself.

Stanislov hopes the = IETF can=20 work in these areas:

=B7        =20 Cache discovery protocol

=B7        =20 Network information for smart peer selection

=B7        =20 Experimental congestion control

=B7        =20 BCP on P2P pain

Stanislov doesn=92t = think we=92re=20 ready to do congestion control for P2P yet =96 do a framework, but = don=92t=20 standardize the mechanism yet.

Lars says there=92s = a TSV=20 committee looking at new congestion control mechanisms, but the = participants are=20 all from the long-delay community.

Current BitTorrent = cache=20 discovery protocol is DNS-based, with an SRV record based on the reverse = DNS=20 lookup of your IP address.

Dave Oran asked for = input from=20 DSL and Metro-Ethernet network operators, because he sees the network=20 characteristics being radically different, and the problem he sees on = deployed=20 networks is under-provisioned aggregation network links.

3.4          =20 Lightning Talks & General = Discussion

3.4.1           = ;=20 Robb Topolski

This talk covers = about a third=20 of Robb=92s submitted paper.

Robb believes that = the common=20 accusations about P2P file-sharing aren=92t actually true =96 for = example, it=92s very=20 rare for any applications to rate-limit, so almost all applications will = use all=20 available bandwidth.

We need to know a = lot more about=20 the problems we=92re facing (including =93where congestion actually = is=94) in order to=20 solve problems, instead of simply dealing with effects.

3.4.2           = ;=20 Nick Weaver

The problem with P2P = filesharing=20 is that it shifts cost, doesn=92t save costs. It increases aggregate = costs, and=20 it=92s transport-inefficient.

Could easily build a = BitTorrent=20 cache today =96 all the components are in place. But it=92s less = efficient than=20 HTTP, and it=92s lawsuit-bait for pirated content.

3.4.3           = ;=20 Leslie Daigle

=93The open, = decentralized nature=20 must be preserved.=94

The problems = aren=92t about P2P=20 technology itself. There=92s an assumption that network operators = won=92t/can=92t=20 adjust the network to meet demand (as P2P supernodes move).

What are we trying = to do:

=B7        =20 Make P2P networks work better?

=B7        =20 Make applications and networks more aware of each=20 other?

=B7        =20 Solve the general-case of bandwidth-intensive=20 applications?

=B7        =20 Deal with in-network issues or impact of = cross-network=20 traffic?

3.5          =20 Localization and Caches

3.5.1           = ;=20 Laird Popkin and Haiyong Xie =96 P4P =

Average P2P bit = travels 5-7=20 metro hops in Verizon networks =96 network-oblivious P2P applications = may not be=20 network-efficient. Routing information is hidden, TCP rate control is=20 coarse-grained.

P4P goal is to = design a=20 framework that enables better cooperation between providers and=20 applications.

P4P tracker provides = static=20 topologies, policies, provider capabilities, virtual cost=85

Virtual costs can be = distributed=20 based on provider preferences, but they are talking to providers about = 5-minute=20 refresh windows (for scaling reasons). Costs are provided by the = providers (not=20 currently tied to routing, but could be if someone wants to provide a = feed from=20 routing).

Trials at Verizon = and Telefonica=20 showed significant increases in intra-ISP traffic, including increase in = =93local=94=20 traffic based on IP prefixes. This was a large swarm (3500 peers at the = peak,=20 300 after a few days).

Possible IETF work = =96=20 =93trackerless P2P=94 (DNS), lookup mechanisms to find AS-PIDs and = trackers for a=20 given ASN.

Jon asked for = information about=20 what IETF protocols are being modified.

Henning said it = would be nice to=20 have everyone work together, but IETF is slow=85 P4P Forum doesn=92t = think they are=20 doing a standard, they think they are validating a concept.

3.5.2           = ;=20 Yu-Shun Wang =96 P2PI Traffic = Localization -=20 Microsoft

Lots of reasons to = localize =96=20 apply QoS policy, throttling, admission control =96 but localization = makes the=20 user experience =93non-uniform=94.

Using multi-layer = trackers=20 (global, local, anything in between).

Want to be = =93local=94 =96 but may=20 have to accommodate traffic conditions, load balancing, policy, etc. = Need the=20 right metrics =96 the policy might be NOT to localize.

Most of focus is on = topology=20 matching between link layer and application layer. Caches are easy = (long-lived=20 peers) but caches have to be in the right place in order to gain = benefits.

Looking at tracker=20 redirection/delegation. Prefer off-path for reliability and avoiding = performance=20 bottlenecks.

Eric Burger asked = what incentive=20 people have to deploy a mechanism like this.

Jon liked this=20 paper/presentation because it seemed easy to chop into engineering-sized = parts.

Bob raised a concern = about ISP=20 liability if they are helping pirates choose optimal paths for = particular=20 swarms, but if you provide information for all users in all swarms, this = isn=92t=20 scalable.

3.5.3           = ;=20 Vinay Aggrawa =96 ISP-aided Neighbor = Selection =96=20 DT

Vinay is talking = about something=20 that=92s similar to P4P =96 having a provider supply an oracle so that = any peer can=20 find its =93local neighbors=94.

Henning is concerned = about=20 oracles that dump traffic off-net, and beggar their neighbors.

Dave Oran thought = the oracle=20 would also know who was talking to who now =96 and this approach = doesn=92t have that=20 information yet.

People are thinking = that 9000=20 nodes is a big swarm =96 for legal content with advertising, it probably = isn=92t. We=20 need to think about much larger swarms.

Could just run = oracle as web=20 server/UDP server at well-known location (similar to BIND). Open and = simple=20 solution, open for all overlays.

Oracle service = doesn=92t cache=20 content at ISP, doesn=92t participate in file sharing.

Are ISPs willing to = accept=20 approaches like oracles that rely on interaction with clients? They=92ve = resisted=20 this in the past.

3.5.4           = ;=20 Cullen =96 IETF work on=20 localization?

(Cullen had a slide = of possible=20 work from listening to presentations and questions/answers)

Leslie =96 still = need to decide=20 what problem we=92re trying to solve=85

EKR =96 people = talked about making=20 clients less aggressive, moving data into caches so it doesn=92t consume = uplink=20 capacity, and choosing better peers. All of Cullen=92s list was about=20 localization. Doesn=92t seem that localization would be important to = Comcast, and=20 I=92m terrified of the legal issues involved in caching.

Would be useful for = nodes to=20 find their own locations in a topology =96 find own AS numbers, etc.

Henning =96 = providing information=20 that customers can=92t verify, can lead to undesirable situations (like=20 =93hot-potato=94 in routing).

Standardize a = protocol to=20 delegate from global trackers to local trackers? Lisa says lots of HTTP = servers=20 have their own mirror mapping information distribution mechanisms = (proprietary).=20 It=92s possible this would be reusable, but possible that the two = problem spaces=20 are just too different.

Lisa also had = concerns about=20 layer-nine concerns with inter-ISP localization issues.

Why not look at the = entire=20 problem, and not just parts by parts? We did IM as an application, and = Google is=20 starting to use the standardized versions. =20 Jon thinks that IM came into the IETF in just the way he=92s = thinking of=20 for P2P =96 what are the parts we need?

Lars =96 we have = transport=20 technologies that aren=92t seeing deployment. Maybe incentives have = changed, but=20 something would have to change in order for new transport stuff to be = deployed.=20 Localized changes, at the point that benefits from the change, do get=20 deployed.

Lisa is concerned = that=20 localization is one of the technologies that can work in practice, in a = limited=20 environment, but can=92t be standardized =96 because of issues about = trust,=20 accuracy, etc=85

3.6          =20 New Approaches to Congestion

3.6.1           = ;=20 Bob Briscoe

Bob is presenting = Diffserv=20 weighted scheduling versus weighted congestion points.

Diffserv is = typically used=20 without an API, so the application itself does nothing about = Diffserv.

Diffserv isn=92t = designed to work=20 at the granularity of individual users.

When a light user = sends to a=20 heavy user, the light user is using up Diffserv limits in his own = network, only=20 for the traffic to be marked down in the heavy user=92s network.

Bob is concerned = that we=92re=20 going to end up in the same place as ATM =96 with too many traffic = classes.

Bob proposes a = =93congestion harm=20 (cost) metric=94.

Is this anything = like Comcast=92s=20 proposal earlier in the workshop? Important to take what ISPs are doing = now into=20 account as we plan years into the future.

ECN is helpful but = ingress=20 policer can=92t see congestion on the rest of the path.

Bob is asking the = IETF/IRTF to=20 set up a longer-term design team for congestion.

3.6.2           = ;=20 Marcin Matusze

This presentation is = based on=20 conversations with about 20 ISPs.

ISP customer = acquisition costs=20 are much higher than monthly revenue, and cost structure varies (fixed = versus=20 mobile). It=92s difficult to change contracts, and 5 percent of users = generate 75=20 percent of the traffic.

Mobile network = operators have=20 more tools (volume-based accounting, fixed pricing up to a limit). Most = tools=20 aren=92t widely used.

BT is starting to = use deep=20 packet inspection, and Bob says that=92s 10 times more cost-effective = than adding=20 bandwidth.

Finnish ISPs were = very concerned=20 about P2P traffic in 2004, but much less concerned today.

3.7          =20 Quality of Service

3.7.1           = ;=20 Mary Barnes =96 QoS-enabled traffic=20 prioritization

Many service = providers are=20 implementing deep packet inspection, but this isn=92t viable = long-term.

Diffserv can be = implemented=20 today but doesn=92t solve all the problems, and provisioning/managing = still has to=20 look at the events that cause peak usage.

Why hasn=92t = Diffserv been=20 deployed in the past? Maybe the problem is big enough now? Bob says data = is=20 showing that the amount of P2P traffic in the world is decreasing=85

People are using QoS = =96 just not=20 on the Internet. More than 50 percent of Cisco=92s enterprise users have = turned=20 Diffserv on =96 actually higher than that, for enterprise VoIP or video = users.=20 There=92s a real problem with DSLAMs with very limited processing = capabilities =96=20 Dave Oran made the point that the problems in layer-two aggregation = networks are=20 severe and overlooked.

3.7.2           = ;=20 Henning Schulzrinne =96 encouraging = bandwidth=20 efficiency

Average TV = consumption in=20 North America for HDTV =3D 972 = GBytes per month=20 =96 reasonable upper limit.

Goal is to minimize = OVERALL cost=20 of content delivery.  = Focusing only=20 on HTTP efficiency misses the point.

Transit bandwidth = trends changed=20 in 2004 =96 from a steady decline to very little change since 2004.

Cost for sharing = content is a=20 step function =96 moving from the neighborhood to a national = distribution requires=20 different infrastructure.

FIOS TV architecture = is very=20 different from the CATV architecture discussed this morning.

We have a general = discovery=20 problem (network topology, STUN, HELD, LoST, SIP local network = configuration=85).=20 We have a variety of solutions (DHCP, DNS, anycast=85)

If you=92re = volume-based, you need=20 application-visible charging indication to allow people to make rational = decisions. Can the IETF help here?

Misbehaving = applications expose=20 user to risk in a charging situation.

3.8          =20 Conclusions & Wrap

Generalized = =93talking to your=20 local infrastructure=94 mechanism keeps coming up, over and over.

Indication of = charging would be=20 machine-parsed for any =93rational actor=94 =96 person or machine.

Eric is concerned = that we=92re=20 identifying so many topics that are application-specific and = hard-to-too-hard to=20 generalize into a transport mechanism.

Jon thinks P4P = =93virtual costs=94=20 makes sense as something we can extract out.

Do we need more than = =93this will=20 be expensive/this will be cheap=94?

=93I=92d be happy to = tag=20 low-priority traffic if that made any difference to me=94 =96 if ISPs = are putting=20 bandwidth caps in place and scavenger-class traffic didn=92t count, that = would=20 make a difference.

Congestion control = isn=92t going=20 to fix the cost issue =96 if we aren=92t going to grow a network to = accommodate=20 increased traffic, we=92re just deciding what order the packets queue = in. The IETF=20 needs to decide what=92s about economics and what=92s about = technology.

Can we stop whining = about P2P=20 using too many TCP connections?

Is it possible to = please all the=20 parties? What if benefits to users and benefits to ISPs are just=20 incompatible?

We need to be very = cautious=20 about matching up network protocols and economic models =96 this usually = ends=20 badly (micropayments, etc). Focus on technical topics (congestion, etc). =

Congestion arises = when there=92s a=20 scarcity, and you allocate resources based on cost (which may be money, = or might=20 be pain). Congestion isn=92t different from cost =96 ISPs know that. = Just because=20 cost proposals haven=92t worked in the past doesn=92t mean there=92s no = way to address=20 cost.

Greg =96 worth IETF = attention,=20 momentum around caching, momentum around optimizing peer selection. Good = to=20 think about whether we bring all of the work in at once. On deep packet=20 inspection, as a vendor, unless you want to trust host markings, = first-hop=20 routers have to inspect packets and that=92s not cheap.

Cullen =96 Microsoft = API will=20 default-mark voice traffic above router traffic in priority. Unless we = get our=20 act together we=92re headed for a train wreck.

Danny =96 IETF might = want to=20 consider guidelines on application interaction with transport issues = (multiple=20 ports, etc). Mobile networks have all kinds of differential pricing = (nights and=20 weekends), but other providers have no hooks into charging for things = like=20 distance (even though it might cost the provider more to retrieve a file = from=20 Japan).

Lars =96 a lot of = the things we=92re=20 talking about aren=92t just P2P =96 IPTV (for example) might have many = of the same=20 issues. What are the other heavy bandwidth usages of the network?

Bob =96 congestion = isn=92t cost=20 until it becomes part of the contract that you have with a provider =96 = and=20 providers can=92t see congestion outside the provider=92s own = network.

Eric =96 in = economics, pricing is=20 a protocol and tells you when you should spend money. We need to = remember that=20 P2P is about content, too =96 networks that were engineered for=20 small-request/large-response applications are now carrying servers from=20 grandmothers.

Stanislov =96 = opening multiple TCP=20 connections isn=92t the problem =96 delay is the same for P2P and = Facebook. (This=20 got responded to: this is only the case when you=92re the only user on = the link =96=20 but other applications open multiple links, too. Quoting Dave Oran =96 = =93there are=20 non-evil reasons to open multiple TCP connections and you can=92t tell = them=20 apart=94).

------=_NextPart_000_0335_01C8C0DA.A933FFE0-- --===============1416304873== 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 --===============1416304873==-- From p2pi-bounces@ietf.org Wed May 28 14:53: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 2CF153A6A43; Wed, 28 May 2008 14:53: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 591F33A6A29 for ; Wed, 28 May 2008 14:53:02 -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 TMEwLWazUbFL for ; Wed, 28 May 2008 14:53:01 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 74D123A6765 for ; Wed, 28 May 2008 14:53:01 -0700 (PDT) Received: from [192.168.100.123] (70-5-73-190.area3.spcsdns.net [70.5.73.190]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m4SLr10v022815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 28 May 2008 17:53:07 -0400 (EDT) Message-Id: <182597A7-F39D-45E9-8E9E-07A9C9CB50BC@cs.columbia.edu> From: Henning Schulzrinne To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 17:53:00 -0400 X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Subject: [p2pi] Thought on congestion X-BeenThere: p2pi@ietf.org X-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 quick thought on congestion: The discussion seemed to assume that we can throttle sources and make the problem go away. However, this depends on the network capacity. For the Columbia link, the network is essentially fully loaded all day, so the only shifting would be transferring load to the wee hours of the morning, which is presumably feasible only for Windows updates, large physics data sets, network backups and similar bulk date of no direct interest to humans. Even so, that would only yield an increase in overall throughput of maybe 30%, i.e., barely a year's worth of typical traffic growth. In those circumstances, congestion control really means "you can't download that movie". It would be interesting to see the diurnal load curve for consumer networks. Capping peak usage would still be quite useful, as would protecting real-time traffic, but I think we have to be more precise as to what congestion control really means and what amount of time shifting is necessary. I was also a bit surprised by the notion that the top 5/10% of users should simply be cut off in some way. This is not economically efficient; they might, after all, be willing to pay for the benefit they get from all that bandwidth. Henning _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed May 28 15:09: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 EE0F33A6965; Wed, 28 May 2008 15:09: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 98C733A690C for ; Wed, 28 May 2008 15:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KcdtO+6mEka for ; Wed, 28 May 2008 15:09:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 981633A67F8 for ; Wed, 28 May 2008 15:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1212012604; x=1243548604; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<182597A7-F39D-45E9-8E9E -07A9C9CB50BC@cs.columbia.edu>|References:=20<182597A7-F3 9D-45E9-8E9E-07A9C9CB50BC@cs.columbia.edu>|Date:=20Wed, =2028=20May=202008=2015:09:58=20-0700|To:=20Henning=20Sch ulzrinne=20,=20"p2pi@ietf.org"=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[p2pi]=20Thought=20on=20congestion |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5305"=3B=20 a=3D"3476824"; bh=CXCINasqeFaEviibS4P7S+s+dBzCu6jzTKQpRvnvRlM=; b=rtWYB+q19gKy8ExINAFiujE4IK1PKfDOcLB8vp5mwHimRVhWMoWIUJCV MsUHspFu5S5m0grVdSauypnebFVVoZfz2hFOuobv2oiBXtJNRSA/2lcEz rPR8ZttGkoWA5w5hurDImwUXi9eAbWV6P6Yh0THoQIQ/jCdRdVTQsVzkG 0=; X-IronPort-AV: E=McAfee;i="5200,2160,5305"; a="3476824" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2008 15:10:03 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4SMA3DU011674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 May 2008 15:10:03 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4SMA2JG013869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 May 2008 15:10:03 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 28 May 2008 15:10:00 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <182597A7-F39D-45E9-8E9E-07A9C9CB50BC@cs.columbia.edu> References: <182597A7-F39D-45E9-8E9E-07A9C9CB50BC@cs.columbia.edu> Date: Wed, 28 May 2008 15:09:58 -0700 To: Henning Schulzrinne , "p2pi@ietf.org" From: Ted Hardie Subject: Re: [p2pi] Thought on congestion X-BeenThere: p2pi@ietf.org X-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 At 2:53 PM -0700 5/28/08, Henning Schulzrinne wrote: > >I was also a bit surprised by the notion that the top 5/10% of users >should simply be cut off in some way. This is not economically >efficient; they might, after all, be willing to pay for the benefit >they get from all that bandwidth. I think a different way to ask that question is: "Does it make sense for users at the top of the usage curve to share infrastructure with those in the middle?" As I noted in the paper I submitted, lots of networks are built with specific assumptions about how user traffic can be multiplexed over the shared resources. It might be possible to retain those assumptions for a certain period of time by pushing those who didn't operate in the expected way on to different infrastructure (requiring that they buy leased-line capacity, for example); that way the networks' assumptions aren't challenged by their activity. In case it is not obvious, I think that this does not solve the problem, as the current high-end users are likely just a few years ahead of the typical consumer; I think we have to re-think the base usage assumptions to get anywhere in the long term. regards, Ted _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed May 28 19:05:17 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FE13A6CE6; Wed, 28 May 2008 19:05: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 4A1A128C1AA for ; Wed, 28 May 2008 19:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f75HQCZVXqH for ; Wed, 28 May 2008 19:04:42 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C04013A6CE0 for ; Wed, 28 May 2008 19:04:35 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.46235345; Wed, 28 May 2008 22:04:16 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 22:04:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 22:04:12 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CB9B9@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <033801c8c104$9471e020$6401a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] My notes from today's workshop Thread-Index: AcjBBLJvUaNqje9kTX+yIsp5L3kj8gAKr/mA References: <033801c8c104$9471e020$6401a8c0@china.huawei.com> From: "Livingood, Jason" To: "Spencer Dawkins" , X-OriginalArrivalTime: 29 May 2008 02:04:16.0451 (UTC) FILETIME=[4C67A130:01C8C130] Subject: Re: [p2pi] My notes from today's workshop X-BeenThere: p2pi@ietf.org X-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="===============1612020863==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1612020863== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C130.4C5D5344" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C130.4C5D5344 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Spencer - =20 I think it is important to correct that I think you misrecorded what we said regarding Vonage and other R/T traffic. We in fact were NOT managing Vonage or other OTT and R/T traffic in that timeframe, as we were not performing the TCP RSTs at that time. I believe we may have said that some people complaining thought we were in some way degrading Vonage traffic, which we were not. We then noted that after implementation of the NM technique currently in place that the complaints regarding poor Vonage and other R/T traffic began to decline, thus there appeared to be a rough correlation. =20 Thanks=20 Jason =20 ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, May 28, 2008 4:51 PM To: p2pi@ietf.org Subject: [p2pi] My notes from today's workshop =09 =09 Here's what I captured... Spencer =09 3.1 Welcome/Note Well/Intro Slides Goals: * To think about the Comcast/BitTorrent problem. * To think about what the IETF might do to work on the problem=20 * Focus on what's actionable for the IETF, engineering, not research or politics. "Not dealing with illegal traffic" - Cullen asked us to focus on the problems that we still have when all the traffic is legal. 3.2 Service Provider Perspective (Comcast) Presenters are Jason Livingood and Richard Woundy from Comcast (including attributions because they're presenting a sponsor's perspective0. View that this is a two-way street - applications becoming more network-friendly, networks becoming more application-friendly.=20 Comcast has committed to implement a protocol-agnostic network management technique (by yearend). Comcast was managing Vonage customer traffic, and customers were complaining. Not all the complaints reflected this management (Comcast and Vonage both experienced problems with transit providers), but that wasn't obvious to customers. Most ISPs started managing P2P traffic about 2-3 years ago. When Comcast started managing its traffic, they stopped getting complaints from Vonage and from P2P users. The recent concerns have involved a suspicion that Comcast was degrading Vonage VoIP service in an attempt to favor Comcast's own VoIP products. Current DOCSIS can experience congestion independently on upstream and downstream and experience congestion independently across DOCSIS domains. We talked about some DOCSIS details, but remember that we have to solve problems for a broad class of access networks, not just for DOCSIS. Slide point: "How 'TCP flow fairness' applies to the DOCSIS upstream is an open research question". DOCSIS also has constant-bandwidth "service flows" (so you don't need to request-to-send every packet). A Canadian cable company charges extra to set up a second service flow for Vonage, but other cable companies haven't followed this lead because of concerns about "net neutrality".=20 We did note that if you have enough bandwidth, you don't need to prioritize traffic, but this doesn't help when traffic levels increase suddenly ("network capacity increases are not instantaneous"), and capacity increases can be consumed quickly. Not all customers are similar (even at the DOCSIS domain level) - college populations use more P2P, VoIP/streaming video are more diurnal than bulk file distribution. Comcast would like to avoid protocol-specific "cat and mouse" detection and mitigation, and would like to avoid capacity increases that benefit only 5 percent of heavy users. DOCSIS 3.0 adds capacity but doesn't solve the capacity problem. Comcast will deploy DOCSIS 3.0 in 20 percent of network by yearend. This more than doubles bandwidth available per subscriber, but the conflict is between adding capacity and supporting applications that are designed to maximize bulk bandwidth consumption. There are Internet2 techniques for client-to-network signaling that haven't been standardized in IETF yet... Caching content in the network can reduce TCP RTTs and reduce the peak-to-trough differences of individual flows. Network management trials begin in June - management based on traffic characteristics, not on specific protocols. Algorithm - mark all flows as priority and then mark specific flows as "best-effort" when congestion approaches "the Near Congestion State". Comcast hasn't figured out how to notify users that they have been marked as best-effort yet. BT is planning a similar mechanism on their DSL network, but they are planning on varying the bandwidth, not changing QoS markings. Comcast thinks customers are more concerned about changing markings and don't want to penalize high-bandwidth users when the network is NOT congested ("it's a high-bandwidth service, people should use it"). Henning is concerned about mechanisms that have 8 independent tweakable parameters... Comcast does still care about protocol-specific management mechanisms, when the carrier is providing the application, or when the traffic is illegal, etc. 3.3 Application Designer Perspective (BitTorrent) Presenter is Stanislov Shalunov. BitTorrent is willing to make changes based on outcomes at this conference. BitTorrent sees two problems - RTT measured in seconds, inefficient overlay routing. Peer selection is random, except that there is some bias towards established peers. Trackers randomize the peer list, and peers ask the resulting randomized list what peers they know about. Rarest-first ensures best reliability and helps peers have pieces of files to "trade". This also gives peer diversity. The best peers can be farther away - a peer with a big pipe, a long way away, can drive you at your downlink speed, but a peer on your own cable modem subnet can only drive you at its uplink speed. Danny's comment - restated for minutes: "If you have more localized distribution via caching, or location techniques, or whatever, then burst rates (i.e., peak <> trough ratios) may actually be larger and you may increase HFC contention (note: HFC in particular, v. DSL, etc..)" Overlay efficiency - Stanislov is experimenting with trying peers on same AS, or on a set of ASes (but then you need the set), or in a list of IP prefixes (but then you need the list), or based on some cost minimization model (but then you need costs). If you have more than 20 peers in an AS, you can probably trade files happily, and 57 percent of transit traffic could be reduced with this modification. If there aren't enough local peers, make one a cache (and please choose a fast one), or 10, or 100. Stanislov's experience is that they can do 30-percent hit rate with 1 TByte cache, 80-percent with 100 TBytes - and 1 TByte fits into a device. Dave Oran asked what the required bandwidth for an 80-percent hit rate of 1 TByte is - he is concerned that this architecture may reveal bandwidth bottlenecks onto and off the cache device itself. Stanislov hopes the IETF can work in these areas: * Cache discovery protocol * Network information for smart peer selection * Experimental congestion control * BCP on P2P pain Stanislov doesn't think we're ready to do congestion control for P2P yet - do a framework, but don't standardize the mechanism yet. Lars says there's a TSV committee looking at new congestion control mechanisms, but the participants are all from the long-delay community. Current BitTorrent cache discovery protocol is DNS-based, with an SRV record based on the reverse DNS lookup of your IP address. Dave Oran asked for input from DSL and Metro-Ethernet network operators, because he sees the network characteristics being radically different, and the problem he sees on deployed networks is under-provisioned aggregation network links. 3.4 Lightning Talks & General Discussion 3.4.1 Robb Topolski This talk covers about a third of Robb's submitted paper. Robb believes that the common accusations about P2P file-sharing aren't actually true - for example, it's very rare for any applications to rate-limit, so almost all applications will use all available bandwidth. We need to know a lot more about the problems we're facing (including "where congestion actually is") in order to solve problems, instead of simply dealing with effects. 3.4.2 Nick Weaver The problem with P2P filesharing is that it shifts cost, doesn't save costs. It increases aggregate costs, and it's transport-inefficient. Could easily build a BitTorrent cache today - all the components are in place. But it's less efficient than HTTP, and it's lawsuit-bait for pirated content.=20 3.4.3 Leslie Daigle "The open, decentralized nature must be preserved." The problems aren't about P2P technology itself. There's an assumption that network operators won't/can't adjust the network to meet demand (as P2P supernodes move). What are we trying to do: * Make P2P networks work better? * Make applications and networks more aware of each other? * Solve the general-case of bandwidth-intensive applications? * Deal with in-network issues or impact of cross-network traffic? 3.5 Localization and Caches 3.5.1 Laird Popkin and Haiyong Xie - P4P=20 Average P2P bit travels 5-7 metro hops in Verizon networks - network-oblivious P2P applications may not be network-efficient. Routing information is hidden, TCP rate control is coarse-grained.=20 P4P goal is to design a framework that enables better cooperation between providers and applications. P4P tracker provides static topologies, policies, provider capabilities, virtual cost... Virtual costs can be distributed based on provider preferences, but they are talking to providers about 5-minute refresh windows (for scaling reasons). Costs are provided by the providers (not currently tied to routing, but could be if someone wants to provide a feed from routing). Trials at Verizon and Telefonica showed significant increases in intra-ISP traffic, including increase in "local" traffic based on IP prefixes. This was a large swarm (3500 peers at the peak, 300 after a few days). Possible IETF work - "trackerless P2P" (DNS), lookup mechanisms to find AS-PIDs and trackers for a given ASN. Jon asked for information about what IETF protocols are being modified. Henning said it would be nice to have everyone work together, but IETF is slow... P4P Forum doesn't think they are doing a standard, they think they are validating a concept. 3.5.2 Yu-Shun Wang - P2PI Traffic Localization - Microsoft Lots of reasons to localize - apply QoS policy, throttling, admission control - but localization makes the user experience "non-uniform". Using multi-layer trackers (global, local, anything in between). Want to be "local" - but may have to accommodate traffic conditions, load balancing, policy, etc. Need the right metrics - the policy might be NOT to localize. Most of focus is on topology matching between link layer and application layer. Caches are easy (long-lived peers) but caches have to be in the right place in order to gain benefits. Looking at tracker redirection/delegation. Prefer off-path for reliability and avoiding performance bottlenecks. Eric Burger asked what incentive people have to deploy a mechanism like this. Jon liked this paper/presentation because it seemed easy to chop into engineering-sized parts. Bob raised a concern about ISP liability if they are helping pirates choose optimal paths for particular swarms, but if you provide information for all users in all swarms, this isn't scalable. 3.5.3 Vinay Aggrawa - ISP-aided Neighbor Selection - DT Vinay is talking about something that's similar to P4P - having a provider supply an oracle so that any peer can find its "local neighbors". Henning is concerned about oracles that dump traffic off-net, and beggar their neighbors. Dave Oran thought the oracle would also know who was talking to who now - and this approach doesn't have that information yet. People are thinking that 9000 nodes is a big swarm - for legal content with advertising, it probably isn't. We need to think about much larger swarms. Could just run oracle as web server/UDP server at well-known location (similar to BIND). Open and simple solution, open for all overlays. Oracle service doesn't cache content at ISP, doesn't participate in file sharing. Are ISPs willing to accept approaches like oracles that rely on interaction with clients? They've resisted this in the past. 3.5.4 Cullen - IETF work on localization? (Cullen had a slide of possible work from listening to presentations and questions/answers) Leslie - still need to decide what problem we're trying to solve... EKR - people talked about making clients less aggressive, moving data into caches so it doesn't consume uplink capacity, and choosing better peers. All of Cullen's list was about localization. Doesn't seem that localization would be important to Comcast, and I'm terrified of the legal issues involved in caching. Would be useful for nodes to find their own locations in a topology - find own AS numbers, etc. Henning - providing information that customers can't verify, can lead to undesirable situations (like "hot-potato" in routing). Standardize a protocol to delegate from global trackers to local trackers? Lisa says lots of HTTP servers have their own mirror mapping information distribution mechanisms (proprietary). It's possible this would be reusable, but possible that the two problem spaces are just too different. Lisa also had concerns about layer-nine concerns with inter-ISP localization issues. Why not look at the entire problem, and not just parts by parts? We did IM as an application, and Google is starting to use the standardized versions. Jon thinks that IM came into the IETF in just the way he's thinking of for P2P - what are the parts we need? Lars - we have transport technologies that aren't seeing deployment. Maybe incentives have changed, but something would have to change in order for new transport stuff to be deployed. Localized changes, at the point that benefits from the change, do get deployed. Lisa is concerned that localization is one of the technologies that can work in practice, in a limited environment, but can't be standardized - because of issues about trust, accuracy, etc... 3.6 New Approaches to Congestion 3.6.1 Bob Briscoe Bob is presenting Diffserv weighted scheduling versus weighted congestion points.=20 Diffserv is typically used without an API, so the application itself does nothing about Diffserv. Diffserv isn't designed to work at the granularity of individual users. When a light user sends to a heavy user, the light user is using up Diffserv limits in his own network, only for the traffic to be marked down in the heavy user's network. Bob is concerned that we're going to end up in the same place as ATM - with too many traffic classes. Bob proposes a "congestion harm (cost) metric".=20 Is this anything like Comcast's proposal earlier in the workshop? Important to take what ISPs are doing now into account as we plan years into the future. ECN is helpful but ingress policer can't see congestion on the rest of the path.=20 Bob is asking the IETF/IRTF to set up a longer-term design team for congestion. 3.6.2 Marcin Matusze This presentation is based on conversations with about 20 ISPs. ISP customer acquisition costs are much higher than monthly revenue, and cost structure varies (fixed versus mobile). It's difficult to change contracts, and 5 percent of users generate 75 percent of the traffic. Mobile network operators have more tools (volume-based accounting, fixed pricing up to a limit). Most tools aren't widely used. BT is starting to use deep packet inspection, and Bob says that's 10 times more cost-effective than adding bandwidth. Finnish ISPs were very concerned about P2P traffic in 2004, but much less concerned today. 3.7 Quality of Service 3.7.1 Mary Barnes - QoS-enabled traffic prioritization Many service providers are implementing deep packet inspection, but this isn't viable long-term. Diffserv can be implemented today but doesn't solve all the problems, and provisioning/managing still has to look at the events that cause peak usage. Why hasn't Diffserv been deployed in the past? Maybe the problem is big enough now? Bob says data is showing that the amount of P2P traffic in the world is decreasing... People are using QoS - just not on the Internet. More than 50 percent of Cisco's enterprise users have turned Diffserv on - actually higher than that, for enterprise VoIP or video users. There's a real problem with DSLAMs with very limited processing capabilities - Dave Oran made the point that the problems in layer-two aggregation networks are severe and overlooked. 3.7.2 Henning Schulzrinne - encouraging bandwidth efficiency Average TV consumption in North America for HDTV =3D 972 GBytes per month - reasonable upper limit. Goal is to minimize OVERALL cost of content delivery. Focusing only on HTTP efficiency misses the point.=20 Transit bandwidth trends changed in 2004 - from a steady decline to very little change since 2004. Cost for sharing content is a step function - moving from the neighborhood to a national distribution requires different infrastructure. FIOS TV architecture is very different from the CATV architecture discussed this morning.=20 We have a general discovery problem (network topology, STUN, HELD, LoST, SIP local network configuration...). We have a variety of solutions (DHCP, DNS, anycast...) If you're volume-based, you need application-visible charging indication to allow people to make rational decisions. Can the IETF help here? Misbehaving applications expose user to risk in a charging situation. 3.8 Conclusions & Wrap Generalized "talking to your local infrastructure" mechanism keeps coming up, over and over. Indication of charging would be machine-parsed for any "rational actor" - person or machine. Eric is concerned that we're identifying so many topics that are application-specific and hard-to-too-hard to generalize into a transport mechanism.=20 Jon thinks P4P "virtual costs" makes sense as something we can extract out. Do we need more than "this will be expensive/this will be cheap"? "I'd be happy to tag low-priority traffic if that made any difference to me" - if ISPs are putting bandwidth caps in place and scavenger-class traffic didn't count, that would make a difference. Congestion control isn't going to fix the cost issue - if we aren't going to grow a network to accommodate increased traffic, we're just deciding what order the packets queue in. The IETF needs to decide what's about economics and what's about technology. Can we stop whining about P2P using too many TCP connections?=20 Is it possible to please all the parties? What if benefits to users and benefits to ISPs are just incompatible? We need to be very cautious about matching up network protocols and economic models - this usually ends badly (micropayments, etc). Focus on technical topics (congestion, etc).=20 Congestion arises when there's a scarcity, and you allocate resources based on cost (which may be money, or might be pain). Congestion isn't different from cost - ISPs know that. Just because cost proposals haven't worked in the past doesn't mean there's no way to address cost. Greg - worth IETF attention, momentum around caching, momentum around optimizing peer selection. Good to think about whether we bring all of the work in at once. On deep packet inspection, as a vendor, unless you want to trust host markings, first-hop routers have to inspect packets and that's not cheap. Cullen - Microsoft API will default-mark voice traffic above router traffic in priority. Unless we get our act together we're headed for a train wreck. Danny - IETF might want to consider guidelines on application interaction with transport issues (multiple ports, etc). Mobile networks have all kinds of differential pricing (nights and weekends), but other providers have no hooks into charging for things like distance (even though it might cost the provider more to retrieve a file from Japan). Lars - a lot of the things we're talking about aren't just P2P - IPTV (for example) might have many of the same issues. What are the other heavy bandwidth usages of the network? Bob - congestion isn't cost until it becomes part of the contract that you have with a provider - and providers can't see congestion outside the provider's own network. Eric - in economics, pricing is a protocol and tells you when you should spend money. We need to remember that P2P is about content, too - networks that were engineered for small-request/large-response applications are now carrying servers from grandmothers. Stanislov - opening multiple TCP connections isn't the problem - delay is the same for P2P and Facebook. (This got responded to: this is only the case when you're the only user on the link - but other applications open multiple links, too. Quoting Dave Oran - "there are non-evil reasons to open multiple TCP connections and you can't tell them apart"). ------_=_NextPart_001_01C8C130.4C5D5344 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Spencer -
 
I think it is important to correct that I think = you misrecorded what we said regarding Vonage and other R/T = traffic. =20 We in fact were NOT managing Vonage or other OTT and R/T traffic in that = timeframe, as we were not performing the TCP RSTs at that time.  I = believe=20 we may have said that some people complaining thought we were in some = way=20 degrading Vonage traffic, which we were not.  We then noted that = after=20 implementation of the NM technique currently in place that the = complaints=20 regarding poor Vonage and other R/T traffic began to decline, thus there = appeared to be a rough correlation.
 
Thanks=20
Jason
 

From: p2pi-bounces@ietf.org=20 [mailto:p2pi-bounces@ietf.org] On Behalf Of Spencer=20 Dawkins
Sent: Wednesday, May 28, 2008 4:51 PM
To:=20 p2pi@ietf.org
Subject: [p2pi] My notes from today's=20 workshop

Here's what I = captured...

Spencer

3.1          =20 Welcome/Note Well/Intro Slides

Goals:

·        =20 To think about the Comcast/BitTorrent = problem.

·        =20 To think about what the IETF might do to work on = the=20 problem

·        =20 Focus on what’s actionable for the IETF, = engineering, not=20 research or politics.

“Not dealing = with illegal=20 traffic” – Cullen asked us to focus on the problems that = we still have when=20 all the traffic is legal.

3.2          =20 Service Provider Perspective = (Comcast)

Presenters are = Jason Livingood=20 and Richard Woundy from Comcast (including attributions because = they’re=20 presenting a sponsor’s perspective0.

View that this is = a two-way=20 street – applications becoming more network-friendly, networks = becoming more=20 application-friendly.

Comcast has = committed to=20 implement a protocol-agnostic network management technique (by = yearend).

Comcast was = managing Vonage=20 customer traffic, and customers were complaining. Not all the = complaints=20 reflected this management (Comcast and Vonage both experienced = problems with=20 transit providers), but that wasn’t obvious to customers.

Most ISPs started = managing P2P=20 traffic about 2-3 years ago.  = When=20 Comcast started managing its traffic, they stopped getting complaints = from=20 Vonage and from P2P users. The recent concerns have involved a = suspicion that=20 Comcast was degrading Vonage VoIP service in an attempt to favor = Comcast’s own=20 VoIP products.

Current DOCSIS can = experience=20 congestion independently on upstream and downstream and experience = congestion=20 independently across DOCSIS domains.

We talked about = some DOCSIS=20 details, but remember that we have to solve problems for a broad class = of=20 access networks, not just for DOCSIS.

Slide point: = “How ‘TCP flow=20 fairness’ applies to the DOCSIS upstream is an open research = question”.

DOCSIS also has=20 constant-bandwidth “service flows” (so you don’t = need to request-to-send every=20 packet). A Canadian cable company charges extra to set up a second = service=20 flow for Vonage, but other cable companies haven’t followed this = lead because=20 of concerns about “net neutrality”.

We did note that = if you have=20 enough bandwidth, you don’t need to prioritize traffic, but this = doesn’t help=20 when traffic levels increase suddenly (“network capacity = increases are not=20 instantaneous”), and capacity increases can be consumed = quickly.

Not all customers = are similar=20 (even at the DOCSIS domain level) – college populations use more = P2P,=20 VoIP/streaming video are more diurnal than bulk file distribution.

Comcast would like = to avoid=20 protocol-specific “cat and mouse” detection and = mitigation, and would like to=20 avoid capacity increases that benefit only 5 percent of heavy = users.

DOCSIS 3.0 adds = capacity but=20 doesn’t solve the capacity problem. Comcast will deploy DOCSIS = 3.0 in 20=20 percent of network by yearend. This more than doubles bandwidth = available per=20 subscriber, but the conflict is between adding capacity and supporting = applications that are designed to maximize bulk bandwidth = consumption.

There are = Internet2 techniques=20 for client-to-network signaling that haven’t been standardized = in IETF=20 yet…

Caching content in = the network=20 can reduce TCP RTTs and reduce the peak-to-trough differences of = individual=20 flows.

Network management = trials=20 begin in June – management based on traffic characteristics, not = on specific=20 protocols. Algorithm – mark all flows as priority and then mark = specific flows=20 as “best-effort” when congestion approaches “the = Near Congestion State”.

Comcast = hasn’t figured out how=20 to notify users that they have been marked as best-effort yet.

BT is planning a = similar=20 mechanism on their DSL network, but they are planning on varying the=20 bandwidth, not changing QoS markings. Comcast thinks customers are = more=20 concerned about changing markings and don’t want to penalize = high-bandwidth=20 users when the network is NOT congested (“it’s a = high-bandwidth service,=20 people should use it”).

Henning is = concerned about=20 mechanisms that have 8 independent tweakable parameters…

Comcast does still = care about=20 protocol-specific management mechanisms, when the carrier is providing = the=20 application, or when the traffic is illegal, etc.

3.3          =20 Application Designer Perspective=20 (BitTorrent)

Presenter is = Stanislov=20 Shalunov.

BitTorrent is = willing to make=20 changes based on outcomes at this conference.

BitTorrent sees = two problems –=20 RTT measured in seconds, inefficient overlay routing.

Peer selection is = random,=20 except that there is some bias towards established peers. Trackers = randomize=20 the peer list, and peers ask the resulting randomized list what peers = they=20 know about. Rarest-first ensures best reliability and helps peers have = pieces=20 of files to “trade”. This also gives peer diversity.

The best peers can = be farther=20 away – a peer with a big pipe, a long way away, can drive you at = your downlink=20 speed, but a peer on your own cable modem subnet can only drive you at = its=20 uplink speed.

Danny’s = comment – restated for=20 minutes: “If you have more localized distribution via caching, = or location=20 techniques, or whatever, then burst rates (i.e., peak <> trough = ratios)=20 may actually be larger and you may increase HFC contention (note: HFC = in=20 particular, v. DSL, etc..)”

Overlay efficiency = –=20 Stanislov  is = experimenting with=20 trying peers on same AS, or on a set of ASes (but then you need the = set), or=20 in a list of IP prefixes (but then you need the list), or based on = some cost=20 minimization model (but then you need costs).

If you have more = than 20 peers=20 in an AS, you can probably trade files happily, and 57 percent of = transit=20 traffic could be reduced with this modification. If there aren’t = enough local=20 peers, make one a cache (and please choose a fast one), or 10, or = 100.

Stanislov’s = experience is that=20 they can do 30-percent hit rate with 1 TByte cache, 80-percent with = 100 TBytes=20 – and 1 TByte fits into a device.

Dave Oran asked = what the=20 required bandwidth for an 80-percent hit rate of 1 TByte is – he = is concerned=20 that this architecture may reveal bandwidth bottlenecks onto and off = the cache=20 device itself.

Stanislov hopes = the IETF can=20 work in these areas:

·        =20 Cache discovery protocol

·        =20 Network information for smart peer selection

·        =20 Experimental congestion control

·        =20 BCP on P2P pain

Stanislov = doesn’t think we’re=20 ready to do congestion control for P2P yet – do a framework, but = don’t=20 standardize the mechanism yet.

Lars says = there’s a TSV=20 committee looking at new congestion control mechanisms, but the = participants=20 are all from the long-delay community.

Current BitTorrent = cache=20 discovery protocol is DNS-based, with an SRV record based on the = reverse DNS=20 lookup of your IP address.

Dave Oran asked = for input from=20 DSL and Metro-Ethernet network operators, because he sees the network=20 characteristics being radically different, and the problem he sees on = deployed=20 networks is under-provisioned aggregation network links.

3.4          =20 Lightning Talks & General = Discussion

3.4.1           = ;=20 Robb Topolski

This talk covers = about a third=20 of Robb’s submitted paper.

Robb believes that = the common=20 accusations about P2P file-sharing aren’t actually true – = for example, it’s=20 very rare for any applications to rate-limit, so almost all = applications will=20 use all available bandwidth.

We need to know a = lot more=20 about the problems we’re facing (including “where = congestion actually is”) in=20 order to solve problems, instead of simply dealing with effects.

3.4.2           = ;=20 Nick Weaver

The problem with = P2P=20 filesharing is that it shifts cost, doesn’t save costs. It = increases aggregate=20 costs, and it’s transport-inefficient.

Could easily build = a=20 BitTorrent cache today – all the components are in place. But = it’s less=20 efficient than HTTP, and it’s lawsuit-bait for pirated content. =

3.4.3           = ;=20 Leslie Daigle

“The open, = decentralized=20 nature must be preserved.”

The problems = aren’t about P2P=20 technology itself. There’s an assumption that network operators = won’t/can’t=20 adjust the network to meet demand (as P2P supernodes move).

What are we trying = to do:

·        =20 Make P2P networks work better?

·        =20 Make applications and networks more aware of each = other?

·        =20 Solve the general-case of bandwidth-intensive=20 applications?

·        =20 Deal with in-network issues or impact of = cross-network=20 traffic?

3.5          =20 Localization and Caches

3.5.1           = ;=20 Laird Popkin and Haiyong Xie = – P4P=20

Average P2P bit = travels 5-7=20 metro hops in Verizon networks – network-oblivious P2P = applications may not be=20 network-efficient. Routing information is hidden, TCP rate control is=20 coarse-grained.

P4P goal is to = design a=20 framework that enables better cooperation between providers and=20 applications.

P4P tracker = provides static=20 topologies, policies, provider capabilities, virtual cost…

Virtual costs can = be=20 distributed based on provider preferences, but they are talking to = providers=20 about 5-minute refresh windows (for scaling reasons). Costs are = provided by=20 the providers (not currently tied to routing, but could be if someone = wants to=20 provide a feed from routing).

Trials at Verizon = and=20 Telefonica showed significant increases in intra-ISP traffic, = including=20 increase in “local” traffic based on IP prefixes. This was = a large swarm (3500=20 peers at the peak, 300 after a few days).

Possible IETF work = –=20 “trackerless P2P” (DNS), lookup mechanisms to find AS-PIDs = and trackers for a=20 given ASN.

Jon asked for = information=20 about what IETF protocols are being modified.

Henning said it = would be nice=20 to have everyone work together, but IETF is slow… P4P Forum = doesn’t think they=20 are doing a standard, they think they are validating a concept.

3.5.2           = ;=20 Yu-Shun Wang – P2PI Traffic = Localization -=20 Microsoft

Lots of reasons to = localize –=20 apply QoS policy, throttling, admission control – but = localization makes the=20 user experience “non-uniform”.

Using multi-layer = trackers=20 (global, local, anything in between).

Want to be = “local” – but may=20 have to accommodate traffic conditions, load balancing, policy, etc. = Need the=20 right metrics – the policy might be NOT to localize.

Most of focus is = on topology=20 matching between link layer and application layer. Caches are easy = (long-lived=20 peers) but caches have to be in the right place in order to gain = benefits.

Looking at tracker = redirection/delegation. Prefer off-path for reliability and avoiding=20 performance bottlenecks.

Eric Burger asked = what=20 incentive people have to deploy a mechanism like this.

Jon liked this=20 paper/presentation because it seemed easy to chop into = engineering-sized=20 parts.

Bob raised a = concern about ISP=20 liability if they are helping pirates choose optimal paths for = particular=20 swarms, but if you provide information for all users in all swarms, = this isn’t=20 scalable.

3.5.3           = ;=20 Vinay Aggrawa – ISP-aided = Neighbor Selection=20 – DT

Vinay is talking = about=20 something that’s similar to P4P – having a provider supply = an oracle so that=20 any peer can find its “local neighbors”.

Henning is = concerned about=20 oracles that dump traffic off-net, and beggar their neighbors.

Dave Oran thought = the oracle=20 would also know who was talking to who now – and this approach = doesn’t have=20 that information yet.

People are = thinking that 9000=20 nodes is a big swarm – for legal content with advertising, it = probably isn’t.=20 We need to think about much larger swarms.

Could just run = oracle as web=20 server/UDP server at well-known location (similar to BIND). Open and = simple=20 solution, open for all overlays.

Oracle service = doesn’t cache=20 content at ISP, doesn’t participate in file sharing.

Are ISPs willing = to accept=20 approaches like oracles that rely on interaction with clients? = They’ve=20 resisted this in the past.

3.5.4           = ;=20 Cullen – IETF work on=20 localization?

(Cullen had a = slide of=20 possible work from listening to presentations and = questions/answers)

Leslie – = still need to decide=20 what problem we’re trying to solve…

EKR – people = talked about=20 making clients less aggressive, moving data into caches so it = doesn’t consume=20 uplink capacity, and choosing better peers. All of Cullen’s list = was about=20 localization. Doesn’t seem that localization would be important = to Comcast,=20 and I’m terrified of the legal issues involved in caching.

Would be useful = for nodes to=20 find their own locations in a topology – find own AS numbers, = etc.

Henning – = providing=20 information that customers can’t verify, can lead to undesirable = situations=20 (like “hot-potato” in routing).

Standardize a = protocol to=20 delegate from global trackers to local trackers? Lisa says lots of = HTTP=20 servers have their own mirror mapping information distribution = mechanisms=20 (proprietary). It’s possible this would be reusable, but = possible that the two=20 problem spaces are just too different.

Lisa also had = concerns about=20 layer-nine concerns with inter-ISP localization issues.

Why not look at = the entire=20 problem, and not just parts by parts? We did IM as an application, and = Google=20 is starting to use the standardized versions.  Jon thinks that IM came into = the IETF=20 in just the way he’s thinking of for P2P – what are the = parts we need?

Lars – we = have transport=20 technologies that aren’t seeing deployment. Maybe incentives = have changed, but=20 something would have to change in order for new transport stuff to be=20 deployed. Localized changes, at the point that benefits from the = change, do=20 get deployed.

Lisa is concerned = that=20 localization is one of the technologies that can work in practice, in = a=20 limited environment, but can’t be standardized – because = of issues about=20 trust, accuracy, etc…

3.6          =20 New Approaches to Congestion

3.6.1           = ;=20 Bob Briscoe

Bob is presenting = Diffserv=20 weighted scheduling versus weighted congestion points.

Diffserv is = typically used=20 without an API, so the application itself does nothing about = Diffserv.

Diffserv = isn’t designed to=20 work at the granularity of individual users.

When a light user = sends to a=20 heavy user, the light user is using up Diffserv limits in his own = network,=20 only for the traffic to be marked down in the heavy user’s = network.

Bob is concerned = that we’re=20 going to end up in the same place as ATM – with too many traffic = classes.

Bob proposes a = “congestion=20 harm (cost) metric”.

Is this anything = like=20 Comcast’s proposal earlier in the workshop? Important to take = what ISPs are=20 doing now into account as we plan years into the future.

ECN is helpful but = ingress=20 policer can’t see congestion on the rest of the path.

Bob is asking the = IETF/IRTF to=20 set up a longer-term design team for congestion.

3.6.2           = ;=20 Marcin Matusze

This presentation = is based on=20 conversations with about 20 ISPs.

ISP customer = acquisition costs=20 are much higher than monthly revenue, and cost structure varies (fixed = versus=20 mobile). It’s difficult to change contracts, and 5 percent of = users generate=20 75 percent of the traffic.

Mobile network = operators have=20 more tools (volume-based accounting, fixed pricing up to a limit). = Most tools=20 aren’t widely used.

BT is starting to = use deep=20 packet inspection, and Bob says that’s 10 times more = cost-effective than=20 adding bandwidth.

Finnish ISPs were = very=20 concerned about P2P traffic in 2004, but much less concerned = today.

3.7          =20 Quality of Service

3.7.1           = ;=20 Mary Barnes – QoS-enabled = traffic=20 prioritization

Many service = providers are=20 implementing deep packet inspection, but this isn’t viable = long-term.

Diffserv can be = implemented=20 today but doesn’t solve all the problems, and = provisioning/managing still has=20 to look at the events that cause peak usage.

Why hasn’t = Diffserv been=20 deployed in the past? Maybe the problem is big enough now? Bob says = data is=20 showing that the amount of P2P traffic in the world is = decreasing…

People are using = QoS – just=20 not on the Internet. More than 50 percent of Cisco’s enterprise = users have=20 turned Diffserv on – actually higher than that, for enterprise = VoIP or video=20 users. There’s a real problem with DSLAMs with very limited = processing=20 capabilities – Dave Oran made the point that the problems in = layer-two=20 aggregation networks are severe and overlooked.

3.7.2           = ;=20 Henning Schulzrinne – = encouraging bandwidth=20 efficiency

Average TV = consumption in=20 North America for HDTV =3D 972 = GBytes per month=20 – reasonable upper limit.

Goal is to = minimize OVERALL=20 cost of content delivery. =20 Focusing only on HTTP efficiency misses the point.

Transit bandwidth = trends=20 changed in 2004 – from a steady decline to very little change = since 2004.

Cost for sharing = content is a=20 step function – moving from the neighborhood to a national = distribution=20 requires different infrastructure.

FIOS TV = architecture is very=20 different from the CATV architecture discussed this morning.

We have a general = discovery=20 problem (network topology, STUN, HELD, LoST, SIP local network=20 configuration…). We have a variety of solutions (DHCP, DNS, = anycast…)

If you’re = volume-based, you=20 need application-visible charging indication to allow people to make = rational=20 decisions. Can the IETF help here?

Misbehaving = applications=20 expose user to risk in a charging situation.

3.8          =20 Conclusions & Wrap

Generalized = “talking to your=20 local infrastructure” mechanism keeps coming up, over and = over.

Indication of = charging would=20 be machine-parsed for any “rational actor” – person = or machine.

Eric is concerned = that we’re=20 identifying so many topics that are application-specific and = hard-to-too-hard=20 to generalize into a transport mechanism.

Jon thinks P4P = “virtual costs”=20 makes sense as something we can extract out.

Do we need more = than “this=20 will be expensive/this will be cheap”?

“I’d = be happy to tag=20 low-priority traffic if that made any difference to me” – = if ISPs are putting=20 bandwidth caps in place and scavenger-class traffic didn’t = count, that would=20 make a difference.

Congestion control = isn’t going=20 to fix the cost issue – if we aren’t going to grow a = network to accommodate=20 increased traffic, we’re just deciding what order the packets = queue in. The=20 IETF needs to decide what’s about economics and what’s = about technology.

Can we stop = whining about P2P=20 using too many TCP connections?

Is it possible to = please all=20 the parties? What if benefits to users and benefits to ISPs are just=20 incompatible?

We need to be very = cautious=20 about matching up network protocols and economic models – this = usually ends=20 badly (micropayments, etc). Focus on technical topics (congestion, = etc).

Congestion arises = when there’s=20 a scarcity, and you allocate resources based on cost (which may be = money, or=20 might be pain). Congestion isn’t different from cost – = ISPs know that. Just=20 because cost proposals haven’t worked in the past doesn’t = mean there’s no way=20 to address cost.

Greg – worth = IETF attention,=20 momentum around caching, momentum around optimizing peer selection. = Good to=20 think about whether we bring all of the work in at once. On deep = packet=20 inspection, as a vendor, unless you want to trust host markings, = first-hop=20 routers have to inspect packets and that’s not cheap.

Cullen – = Microsoft API will=20 default-mark voice traffic above router traffic in priority. Unless we = get our=20 act together we’re headed for a train wreck.

Danny – IETF = might want to=20 consider guidelines on application interaction with transport issues = (multiple=20 ports, etc). Mobile networks have all kinds of differential pricing = (nights=20 and weekends), but other providers have no hooks into charging for = things like=20 distance (even though it might cost the provider more to retrieve a = file from=20 Japan).

Lars – a lot = of the things=20 we’re talking about aren’t just P2P – IPTV (for = example) might have many of=20 the same issues. What are the other heavy bandwidth usages of the = network?

Bob – = congestion isn’t cost=20 until it becomes part of the contract that you have with a provider = – and=20 providers can’t see congestion outside the provider’s own = network.

Eric – in = economics, pricing=20 is a protocol and tells you when you should spend money. We need to = remember=20 that P2P is about content, too – networks that were engineered = for=20 small-request/large-response applications are now carrying servers = from=20 grandmothers.

Stanislov – = opening multiple=20 TCP connections isn’t the problem – delay is the same for = P2P and Facebook.=20 (This got responded to: this is only the case when you’re the = only user on the=20 link – but other applications open multiple links, too. Quoting = Dave Oran –=20 “there are non-evil reasons to open multiple TCP connections and = you can’t=20 tell them apart”).

------_=_NextPart_001_01C8C130.4C5D5344-- --===============1612020863== 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 --===============1612020863==-- From p2pi-bounces@ietf.org Wed May 28 19:09: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 24CD53A6CE0; Wed, 28 May 2008 19:09: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 580413A6A98 for ; Wed, 28 May 2008 19:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY8ZYIXF21QR for ; Wed, 28 May 2008 19:08:56 -0700 (PDT) Received: from orange.briworks.net (e.brnets.com [216.30.183.80]) by core3.amsl.com (Postfix) with ESMTP id C449F3A6CE0 for ; Wed, 28 May 2008 19:08:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 22:09:03 -0400 Message-ID: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slide decks from today's meetings? Thread-Index: AcjBBK4Sa7AJdkH2QpavHKrR2GbK/gALB1pg References: From: "John Bartlett" To: Subject: [p2pi] Slide decks from today's meetings? X-BeenThere: p2pi@ietf.org X-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 Are the slide decks from today's (MIT) presentations available? Thanks. JB John Bartlett NetForecast, Inc. call +1-508-969-4456 skype amlafrance19 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed May 28 19:46: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 6BF933A6976; Wed, 28 May 2008 19:46: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 1447A3A6968 for ; Wed, 28 May 2008 19:46:10 -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 be9VyDoaYfDF for ; Wed, 28 May 2008 19:46:01 -0700 (PDT) Received: from barracuda.ethostream.com (barracuda.ethostream.com [204.15.100.249]) by core3.amsl.com (Postfix) with ESMTP id 4ED983A6940 for ; Wed, 28 May 2008 19:45:06 -0700 (PDT) X-ASG-Debug-ID: 1212029045-377a00c20000-bcqgfR X-Barracuda-URL: http://204.15.100.249:8000/cgi-bin/mark.cgi Received: from relay.ethostream.com (www2.ethostream.com [204.15.100.237]) by barracuda.ethostream.com (Spam Firewall) with ESMTP id D222641E862 for ; Wed, 28 May 2008 21:44:05 -0500 (CDT) Received: from relay.ethostream.com (www2.ethostream.com [204.15.100.237]) by barracuda.ethostream.com with ESMTP id Yf665V0PTlJijJpg for ; Wed, 28 May 2008 21:44:05 -0500 (CDT) Received: from ethoserver.ezone.net (unknown [66.9.185.27]) by relay.ethostream.com (Postfix) with ESMTP id 185218506DC for ; Wed, 28 May 2008 21:44:02 -0500 (CDT) Received: from s73602 (unknown [10.0.0.191]) by ethoserver.ezone.net (Postfix) with ESMTP id D39C3198F420 for ; Wed, 28 May 2008 21:44:07 -0500 (CDT) Message-ID: <03d601c8c136$0675fe50$6401a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <033801c8c104$9471e020$6401a8c0@china.huawei.com> <45AEC6EF95942140888406588E1A6602045CB9B9@PACDCEXCMB04.cable.comcast.com> X-ASG-Orig-Subj: Re: [p2pi] My notes from today's workshop Date: Wed, 28 May 2008 21:45:15 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Barracuda-Connect: www2.ethostream.com[204.15.100.237] X-Barracuda-Start-Time: 1212029045 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at ethostream.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1.6 tests=BSF_SC0_TG035a, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.51719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC0_TG035a Message contains invalid style definition Subject: Re: [p2pi] My notes from today's workshop X-BeenThere: p2pi@ietf.org X-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="===============1227118944==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1227118944== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D3_01C8C10C.1D0D5340" This is a multi-part message in MIME format. ------=_NextPart_000_03D3_01C8C10C.1D0D5340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Jason, Thanks for the quick correction! and my profuse apologies for = misunderstanding what you guys were saying. To others - Cullen asked me to take notes this morning, so I'm assuming = that he and Jon will produce a workshop report in the not-too-distant = future. If I could make a couple of suggestions: - please look over the notes I took to see whether YOU were correctly = quoted or not, and send corrections if I misunderstood, and - please do that fairly quickly, so the meeting report will still be = useful when it's produced. Thanks, Spencer ----- Original Message -----=20 From: Livingood, Jason=20 To: Spencer Dawkins ; p2pi@ietf.org=20 Sent: Wednesday, May 28, 2008 9:04 PM Subject: RE: [p2pi] My notes from today's workshop Hi Spencer - I think it is important to correct that I think you misrecorded what = we said regarding Vonage and other R/T traffic. We in fact were NOT = managing Vonage or other OTT and R/T traffic in that timeframe, as we = were not performing the TCP RSTs at that time. I believe we may have = said that some people complaining thought we were in some way degrading = Vonage traffic, which we were not. We then noted that after = implementation of the NM technique currently in place that the = complaints regarding poor Vonage and other R/T traffic began to decline, = thus there appeared to be a rough correlation. Thanks=20 Jason -------------------------------------------------------------------------= --- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: Wednesday, May 28, 2008 4:51 PM To: p2pi@ietf.org Subject: [p2pi] My notes from today's workshop Here's what I captured... Spencer 3.1 Welcome/Note Well/Intro Slides Goals: =B7 To think about the Comcast/BitTorrent problem. =B7 To think about what the IETF might do to work on the = problem=20 =B7 Focus on what's actionable for the IETF, engineering, = not research or politics. "Not dealing with illegal traffic" - Cullen asked us to focus on the = problems that we still have when all the traffic is legal. 3.2 Service Provider Perspective (Comcast) Presenters are Jason Livingood and Richard Woundy from Comcast = (including attributions because they're presenting a sponsor's = perspective0. View that this is a two-way street - applications becoming more = network-friendly, networks becoming more application-friendly.=20 Comcast has committed to implement a protocol-agnostic network = management technique (by yearend). Comcast was managing Vonage customer traffic, and customers were = complaining. Not all the complaints reflected this management (Comcast = and Vonage both experienced problems with transit providers), but that = wasn't obvious to customers. Most ISPs started managing P2P traffic about 2-3 years ago. When = Comcast started managing its traffic, they stopped getting complaints = from Vonage and from P2P users. The recent concerns have involved a = suspicion that Comcast was degrading Vonage VoIP service in an attempt = to favor Comcast's own VoIP products. Current DOCSIS can experience congestion independently on upstream = and downstream and experience congestion independently across DOCSIS = domains. We talked about some DOCSIS details, but remember that we have to = solve problems for a broad class of access networks, not just for = DOCSIS. Slide point: "How 'TCP flow fairness' applies to the DOCSIS upstream = is an open research question". DOCSIS also has constant-bandwidth "service flows" (so you don't = need to request-to-send every packet). A Canadian cable company charges = extra to set up a second service flow for Vonage, but other cable = companies haven't followed this lead because of concerns about "net = neutrality".=20 We did note that if you have enough bandwidth, you don't need to = prioritize traffic, but this doesn't help when traffic levels increase = suddenly ("network capacity increases are not instantaneous"), and = capacity increases can be consumed quickly. Not all customers are similar (even at the DOCSIS domain level) - = college populations use more P2P, VoIP/streaming video are more diurnal = than bulk file distribution. Comcast would like to avoid protocol-specific "cat and mouse" = detection and mitigation, and would like to avoid capacity increases = that benefit only 5 percent of heavy users. DOCSIS 3.0 adds capacity but doesn't solve the capacity problem. = Comcast will deploy DOCSIS 3.0 in 20 percent of network by yearend. This = more than doubles bandwidth available per subscriber, but the conflict = is between adding capacity and supporting applications that are designed = to maximize bulk bandwidth consumption. There are Internet2 techniques for client-to-network signaling that = haven't been standardized in IETF yet. Caching content in the network can reduce TCP RTTs and reduce the = peak-to-trough differences of individual flows. Network management trials begin in June - management based on = traffic characteristics, not on specific protocols. Algorithm - mark all = flows as priority and then mark specific flows as "best-effort" when = congestion approaches "the Near Congestion State". Comcast hasn't figured out how to notify users that they have been = marked as best-effort yet. BT is planning a similar mechanism on their DSL network, but they = are planning on varying the bandwidth, not changing QoS markings. = Comcast thinks customers are more concerned about changing markings and = don't want to penalize high-bandwidth users when the network is NOT = congested ("it's a high-bandwidth service, people should use it"). Henning is concerned about mechanisms that have 8 independent = tweakable parameters. Comcast does still care about protocol-specific management = mechanisms, when the carrier is providing the application, or when the = traffic is illegal, etc. 3.3 Application Designer Perspective (BitTorrent) Presenter is Stanislov Shalunov. BitTorrent is willing to make changes based on outcomes at this = conference. BitTorrent sees two problems - RTT measured in seconds, inefficient = overlay routing. Peer selection is random, except that there is some bias towards = established peers. Trackers randomize the peer list, and peers ask the = resulting randomized list what peers they know about. Rarest-first = ensures best reliability and helps peers have pieces of files to = "trade". This also gives peer diversity. The best peers can be farther away - a peer with a big pipe, a long = way away, can drive you at your downlink speed, but a peer on your own = cable modem subnet can only drive you at its uplink speed. Danny's comment - restated for minutes: "If you have more localized = distribution via caching, or location techniques, or whatever, then = burst rates (i.e., peak <> trough ratios) may actually be larger and you = may increase HFC contention (note: HFC in particular, v. DSL, etc..)" Overlay efficiency - Stanislov is experimenting with trying peers = on same AS, or on a set of ASes (but then you need the set), or in a = list of IP prefixes (but then you need the list), or based on some cost = minimization model (but then you need costs). If you have more than 20 peers in an AS, you can probably trade = files happily, and 57 percent of transit traffic could be reduced with = this modification. If there aren't enough local peers, make one a cache = (and please choose a fast one), or 10, or 100. Stanislov's experience is that they can do 30-percent hit rate with = 1 TByte cache, 80-percent with 100 TBytes - and 1 TByte fits into a = device. Dave Oran asked what the required bandwidth for an 80-percent hit = rate of 1 TByte is - he is concerned that this architecture may reveal = bandwidth bottlenecks onto and off the cache device itself. Stanislov hopes the IETF can work in these areas: =B7 Cache discovery protocol =B7 Network information for smart peer selection =B7 Experimental congestion control =B7 BCP on P2P pain Stanislov doesn't think we're ready to do congestion control for P2P = yet - do a framework, but don't standardize the mechanism yet. Lars says there's a TSV committee looking at new congestion control = mechanisms, but the participants are all from the long-delay community. Current BitTorrent cache discovery protocol is DNS-based, with an = SRV record based on the reverse DNS lookup of your IP address. Dave Oran asked for input from DSL and Metro-Ethernet network = operators, because he sees the network characteristics being radically = different, and the problem he sees on deployed networks is = under-provisioned aggregation network links. 3.4 Lightning Talks & General Discussion 3.4.1 Robb Topolski This talk covers about a third of Robb's submitted paper. Robb believes that the common accusations about P2P file-sharing = aren't actually true - for example, it's very rare for any applications = to rate-limit, so almost all applications will use all available = bandwidth. We need to know a lot more about the problems we're facing = (including "where congestion actually is") in order to solve problems, = instead of simply dealing with effects. 3.4.2 Nick Weaver The problem with P2P filesharing is that it shifts cost, doesn't = save costs. It increases aggregate costs, and it's = transport-inefficient. Could easily build a BitTorrent cache today - all the components are = in place. But it's less efficient than HTTP, and it's lawsuit-bait for = pirated content.=20 3.4.3 Leslie Daigle "The open, decentralized nature must be preserved." The problems aren't about P2P technology itself. There's an = assumption that network operators won't/can't adjust the network to meet = demand (as P2P supernodes move). What are we trying to do: =B7 Make P2P networks work better? =B7 Make applications and networks more aware of each other? =B7 Solve the general-case of bandwidth-intensive = applications? =B7 Deal with in-network issues or impact of cross-network = traffic? 3.5 Localization and Caches 3.5.1 Laird Popkin and Haiyong Xie - P4P=20 Average P2P bit travels 5-7 metro hops in Verizon networks - = network-oblivious P2P applications may not be network-efficient. Routing = information is hidden, TCP rate control is coarse-grained.=20 P4P goal is to design a framework that enables better cooperation = between providers and applications. P4P tracker provides static topologies, policies, provider = capabilities, virtual cost. Virtual costs can be distributed based on provider preferences, but = they are talking to providers about 5-minute refresh windows (for = scaling reasons). Costs are provided by the providers (not currently = tied to routing, but could be if someone wants to provide a feed from = routing). Trials at Verizon and Telefonica showed significant increases in = intra-ISP traffic, including increase in "local" traffic based on IP = prefixes. This was a large swarm (3500 peers at the peak, 300 after a = few days). Possible IETF work - "trackerless P2P" (DNS), lookup mechanisms to = find AS-PIDs and trackers for a given ASN. Jon asked for information about what IETF protocols are being = modified. Henning said it would be nice to have everyone work together, but = IETF is slow. P4P Forum doesn't think they are doing a standard, they = think they are validating a concept. 3.5.2 Yu-Shun Wang - P2PI Traffic Localization - = Microsoft Lots of reasons to localize - apply QoS policy, throttling, = admission control - but localization makes the user experience = "non-uniform". Using multi-layer trackers (global, local, anything in between). Want to be "local" - but may have to accommodate traffic conditions, = load balancing, policy, etc. Need the right metrics - the policy might = be NOT to localize. Most of focus is on topology matching between link layer and = application layer. Caches are easy (long-lived peers) but caches have to = be in the right place in order to gain benefits. Looking at tracker redirection/delegation. Prefer off-path for = reliability and avoiding performance bottlenecks. Eric Burger asked what incentive people have to deploy a mechanism = like this. Jon liked this paper/presentation because it seemed easy to chop = into engineering-sized parts. Bob raised a concern about ISP liability if they are helping pirates = choose optimal paths for particular swarms, but if you provide = information for all users in all swarms, this isn't scalable. 3.5.3 Vinay Aggrawa - ISP-aided Neighbor Selection - DT Vinay is talking about something that's similar to P4P - having a = provider supply an oracle so that any peer can find its "local = neighbors". Henning is concerned about oracles that dump traffic off-net, and = beggar their neighbors. Dave Oran thought the oracle would also know who was talking to who = now - and this approach doesn't have that information yet. People are thinking that 9000 nodes is a big swarm - for legal = content with advertising, it probably isn't. We need to think about much = larger swarms. Could just run oracle as web server/UDP server at well-known = location (similar to BIND). Open and simple solution, open for all = overlays. Oracle service doesn't cache content at ISP, doesn't participate in = file sharing. Are ISPs willing to accept approaches like oracles that rely on = interaction with clients? They've resisted this in the past. 3.5.4 Cullen - IETF work on localization? (Cullen had a slide of possible work from listening to presentations = and questions/answers) Leslie - still need to decide what problem we're trying to solve. EKR - people talked about making clients less aggressive, moving = data into caches so it doesn't consume uplink capacity, and choosing = better peers. All of Cullen's list was about localization. Doesn't seem = that localization would be important to Comcast, and I'm terrified of = the legal issues involved in caching. Would be useful for nodes to find their own locations in a topology = - find own AS numbers, etc. Henning - providing information that customers can't verify, can = lead to undesirable situations (like "hot-potato" in routing). Standardize a protocol to delegate from global trackers to local = trackers? Lisa says lots of HTTP servers have their own mirror mapping = information distribution mechanisms (proprietary). It's possible this = would be reusable, but possible that the two problem spaces are just too = different. Lisa also had concerns about layer-nine concerns with inter-ISP = localization issues. Why not look at the entire problem, and not just parts by parts? We = did IM as an application, and Google is starting to use the standardized = versions. Jon thinks that IM came into the IETF in just the way he's = thinking of for P2P - what are the parts we need? Lars - we have transport technologies that aren't seeing deployment. = Maybe incentives have changed, but something would have to change in = order for new transport stuff to be deployed. Localized changes, at the = point that benefits from the change, do get deployed. Lisa is concerned that localization is one of the technologies that = can work in practice, in a limited environment, but can't be = standardized - because of issues about trust, accuracy, etc. 3.6 New Approaches to Congestion 3.6.1 Bob Briscoe Bob is presenting Diffserv weighted scheduling versus weighted = congestion points.=20 Diffserv is typically used without an API, so the application itself = does nothing about Diffserv. Diffserv isn't designed to work at the granularity of individual = users. When a light user sends to a heavy user, the light user is using up = Diffserv limits in his own network, only for the traffic to be marked = down in the heavy user's network. Bob is concerned that we're going to end up in the same place as ATM = - with too many traffic classes. Bob proposes a "congestion harm (cost) metric".=20 Is this anything like Comcast's proposal earlier in the workshop? = Important to take what ISPs are doing now into account as we plan years = into the future. ECN is helpful but ingress policer can't see congestion on the rest = of the path.=20 Bob is asking the IETF/IRTF to set up a longer-term design team for = congestion. 3.6.2 Marcin Matusze This presentation is based on conversations with about 20 ISPs. ISP customer acquisition costs are much higher than monthly revenue, = and cost structure varies (fixed versus mobile). It's difficult to = change contracts, and 5 percent of users generate 75 percent of the = traffic. Mobile network operators have more tools (volume-based accounting, = fixed pricing up to a limit). Most tools aren't widely used. BT is starting to use deep packet inspection, and Bob says that's 10 = times more cost-effective than adding bandwidth. Finnish ISPs were very concerned about P2P traffic in 2004, but much = less concerned today. 3.7 Quality of Service 3.7.1 Mary Barnes - QoS-enabled traffic prioritization Many service providers are implementing deep packet inspection, but = this isn't viable long-term. Diffserv can be implemented today but doesn't solve all the = problems, and provisioning/managing still has to look at the events that = cause peak usage. Why hasn't Diffserv been deployed in the past? Maybe the problem is = big enough now? Bob says data is showing that the amount of P2P traffic = in the world is decreasing. People are using QoS - just not on the Internet. More than 50 = percent of Cisco's enterprise users have turned Diffserv on - actually = higher than that, for enterprise VoIP or video users. There's a real = problem with DSLAMs with very limited processing capabilities - Dave = Oran made the point that the problems in layer-two aggregation networks = are severe and overlooked. 3.7.2 Henning Schulzrinne - encouraging bandwidth = efficiency Average TV consumption in North America for HDTV =3D 972 GBytes per = month - reasonable upper limit. Goal is to minimize OVERALL cost of content delivery. Focusing only = on HTTP efficiency misses the point.=20 Transit bandwidth trends changed in 2004 - from a steady decline to = very little change since 2004. Cost for sharing content is a step function - moving from the = neighborhood to a national distribution requires different = infrastructure. FIOS TV architecture is very different from the CATV architecture = discussed this morning.=20 We have a general discovery problem (network topology, STUN, HELD, = LoST, SIP local network configuration.). We have a variety of solutions = (DHCP, DNS, anycast.) If you're volume-based, you need application-visible charging = indication to allow people to make rational decisions. Can the IETF help = here? Misbehaving applications expose user to risk in a charging = situation. 3.8 Conclusions & Wrap Generalized "talking to your local infrastructure" mechanism keeps = coming up, over and over. Indication of charging would be machine-parsed for any "rational = actor" - person or machine. Eric is concerned that we're identifying so many topics that are = application-specific and hard-to-too-hard to generalize into a transport = mechanism.=20 Jon thinks P4P "virtual costs" makes sense as something we can = extract out. Do we need more than "this will be expensive/this will be cheap"? "I'd be happy to tag low-priority traffic if that made any = difference to me" - if ISPs are putting bandwidth caps in place and = scavenger-class traffic didn't count, that would make a difference. Congestion control isn't going to fix the cost issue - if we aren't = going to grow a network to accommodate increased traffic, we're just = deciding what order the packets queue in. The IETF needs to decide = what's about economics and what's about technology. Can we stop whining about P2P using too many TCP connections?=20 Is it possible to please all the parties? What if benefits to users = and benefits to ISPs are just incompatible? We need to be very cautious about matching up network protocols and = economic models - this usually ends badly (micropayments, etc). Focus on = technical topics (congestion, etc).=20 Congestion arises when there's a scarcity, and you allocate = resources based on cost (which may be money, or might be pain). = Congestion isn't different from cost - ISPs know that. Just because cost = proposals haven't worked in the past doesn't mean there's no way to = address cost. Greg - worth IETF attention, momentum around caching, momentum = around optimizing peer selection. Good to think about whether we bring = all of the work in at once. On deep packet inspection, as a vendor, = unless you want to trust host markings, first-hop routers have to = inspect packets and that's not cheap. Cullen - Microsoft API will default-mark voice traffic above router = traffic in priority. Unless we get our act together we're headed for a = train wreck. Danny - IETF might want to consider guidelines on application = interaction with transport issues (multiple ports, etc). Mobile networks = have all kinds of differential pricing (nights and weekends), but other = providers have no hooks into charging for things like distance (even = though it might cost the provider more to retrieve a file from Japan). Lars - a lot of the things we're talking about aren't just P2P - = IPTV (for example) might have many of the same issues. What are the = other heavy bandwidth usages of the network? Bob - congestion isn't cost until it becomes part of the contract = that you have with a provider - and providers can't see congestion = outside the provider's own network. Eric - in economics, pricing is a protocol and tells you when you = should spend money. We need to remember that P2P is about content, too - = networks that were engineered for small-request/large-response = applications are now carrying servers from grandmothers. Stanislov - opening multiple TCP connections isn't the problem - = delay is the same for P2P and Facebook. (This got responded to: this is = only the case when you're the only user on the link - but other = applications open multiple links, too. Quoting Dave Oran - "there are = non-evil reasons to open multiple TCP connections and you can't tell = them apart"). ------=_NextPart_000_03D3_01C8C10C.1D0D5340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Jason,
 
Thanks for the quick correction! and my = profuse=20 apologies for misunderstanding what you guys were saying.
 
To others - Cullen asked me to take = notes this=20 morning, so I'm assuming that he and Jon will produce a workshop report = in the=20 not-too-distant future. If I could make a couple of = suggestions:
 
- please look over the notes I took to = see whether=20 YOU were correctly quoted or not, and send corrections if I = misunderstood,=20 and
 
- please do that fairly quickly, so the = meeting=20 report will still be useful when it's produced.
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Livingood, Jason =
To: Spencer Dawkins ; p2pi@ietf.org =
Sent: Wednesday, May 28, 2008 = 9:04=20 PM
Subject: RE: [p2pi] My notes = from today's=20 workshop

Hi Spencer -
 
I think it is important to correct that I = think=20 you misrecorded what we said regarding Vonage and other R/T=20 traffic.  We in fact were NOT managing Vonage or other OTT and = R/T=20 traffic in that timeframe, as we were not performing the TCP RSTs at = that=20 time.  I believe we may have said that some people complaining = thought we=20 were in some way degrading Vonage traffic, which we were not.  We = then=20 noted that after implementation of the NM technique currently in=20 place that the complaints regarding poor Vonage and other R/T = traffic=20 began to decline, thus there appeared to be a rough=20 correlation.
 
Thanks
Jason
 

From: p2pi-bounces@ietf.org=20 [mailto:p2pi-bounces@ietf.org] On Behalf Of Spencer=20 Dawkins
Sent: Wednesday, May 28, 2008 4:51 = PM
To:=20 p2pi@ietf.org
Subject: [p2pi] My notes from today's=20 workshop

Here's what I = captured...

Spencer

3.1          =20 Welcome/Note Well/Intro Slides

Goals:

=B7        =20 To think about the Comcast/BitTorrent = problem.

=B7        =20 To think about what the IETF might do to work = on the=20 problem

=B7        =20 Focus on what=92s actionable for the IETF, = engineering,=20 not research or politics.

=93Not dealing = with illegal=20 traffic=94 =96 Cullen asked us to focus on the problems that we = still have when=20 all the traffic is legal.

3.2          =20 Service Provider Perspective = (Comcast)

Presenters are = Jason=20 Livingood and Richard Woundy from Comcast (including attributions = because=20 they=92re presenting a sponsor=92s perspective0.

View that this = is a two-way=20 street =96 applications becoming more network-friendly, networks = becoming more=20 application-friendly.

Comcast has = committed to=20 implement a protocol-agnostic network management technique (by = yearend).

Comcast was = managing Vonage=20 customer traffic, and customers were complaining. Not all the = complaints=20 reflected this management (Comcast and Vonage both experienced = problems with=20 transit providers), but that wasn=92t obvious to customers.

Most ISPs = started managing=20 P2P traffic about 2-3 years ago. =20 When Comcast started managing its traffic, they stopped = getting=20 complaints from Vonage and from P2P users. The recent concerns have = involved=20 a suspicion that Comcast was degrading Vonage VoIP service in an = attempt to=20 favor Comcast=92s own VoIP products.

Current DOCSIS = can=20 experience congestion independently on upstream and downstream and=20 experience congestion independently across DOCSIS domains.

We talked about = some DOCSIS=20 details, but remember that we have to solve problems for a broad = class of=20 access networks, not just for DOCSIS.

Slide point: = =93How =91TCP flow=20 fairness=92 applies to the DOCSIS upstream is an open research = question=94.

DOCSIS also has=20 constant-bandwidth =93service flows=94 (so you don=92t need to = request-to-send=20 every packet). A Canadian cable company charges extra to set up a = second=20 service flow for Vonage, but other cable companies haven=92t = followed this=20 lead because of concerns about =93net neutrality=94.

We did note that = if you have=20 enough bandwidth, you don=92t need to prioritize traffic, but this = doesn=92t=20 help when traffic levels increase suddenly (=93network capacity = increases are=20 not instantaneous=94), and capacity increases can be consumed = quickly.

Not all = customers are=20 similar (even at the DOCSIS domain level) =96 college populations = use more=20 P2P, VoIP/streaming video are more diurnal than bulk file = distribution.

Comcast would = like to avoid=20 protocol-specific =93cat and mouse=94 detection and mitigation, and = would like=20 to avoid capacity increases that benefit only 5 percent of heavy = users.

DOCSIS 3.0 adds = capacity but=20 doesn=92t solve the capacity problem. Comcast will deploy DOCSIS 3.0 = in 20=20 percent of network by yearend. This more than doubles bandwidth = available=20 per subscriber, but the conflict is between adding capacity and = supporting=20 applications that are designed to maximize bulk bandwidth = consumption.

There are = Internet2=20 techniques for client-to-network signaling that haven=92t been = standardized in=20 IETF yet=85

Caching content = in the=20 network can reduce TCP RTTs and reduce the peak-to-trough = differences of=20 individual flows.

Network = management trials=20 begin in June =96 management based on traffic characteristics, not = on specific=20 protocols. Algorithm =96 mark all flows as priority and then mark = specific=20 flows as =93best-effort=94 when congestion approaches =93the Near = Congestion=20 State=94.

Comcast hasn=92t = figured out=20 how to notify users that they have been marked as best-effort = yet.

BT is planning a = similar=20 mechanism on their DSL network, but they are planning on varying the = bandwidth, not changing QoS markings. Comcast thinks customers are = more=20 concerned about changing markings and don=92t want to penalize = high-bandwidth=20 users when the network is NOT congested (=93it=92s a high-bandwidth = service,=20 people should use it=94).

Henning is = concerned about=20 mechanisms that have 8 independent tweakable parameters=85

Comcast does = still care=20 about protocol-specific management mechanisms, when the carrier is = providing=20 the application, or when the traffic is illegal, etc.

3.3          =20 Application Designer Perspective=20 (BitTorrent)

Presenter is = Stanislov=20 Shalunov.

BitTorrent is = willing to=20 make changes based on outcomes at this conference.

BitTorrent sees = two problems=20 =96 RTT measured in seconds, inefficient overlay routing.

Peer selection = is random,=20 except that there is some bias towards established peers. Trackers = randomize=20 the peer list, and peers ask the resulting randomized list what = peers they=20 know about. Rarest-first ensures best reliability and helps peers = have=20 pieces of files to =93trade=94. This also gives peer diversity.

The best peers = can be=20 farther away =96 a peer with a big pipe, a long way away, can drive = you at=20 your downlink speed, but a peer on your own cable modem subnet can = only=20 drive you at its uplink speed.

Danny=92s = comment =96 restated=20 for minutes: =93If you have more localized distribution via caching, = or=20 location techniques, or whatever, then burst rates (i.e., peak = <>=20 trough ratios) may actually be larger and you may increase HFC = contention=20 (note: HFC in particular, v. DSL, etc..)=94

Overlay = efficiency =96=20 Stanislov  is = experimenting with=20 trying peers on same AS, or on a set of ASes (but then you need the = set), or=20 in a list of IP prefixes (but then you need the list), or based on = some cost=20 minimization model (but then you need costs).

If you have more = than 20=20 peers in an AS, you can probably trade files happily, and 57 percent = of=20 transit traffic could be reduced with this modification. If there = aren=92t=20 enough local peers, make one a cache (and please choose a fast one), = or 10,=20 or 100.

Stanislov=92s = experience is=20 that they can do 30-percent hit rate with 1 TByte cache, 80-percent = with 100=20 TBytes =96 and 1 TByte fits into a device.

Dave Oran asked = what the=20 required bandwidth for an 80-percent hit rate of 1 TByte is =96 he = is=20 concerned that this architecture may reveal bandwidth bottlenecks = onto and=20 off the cache device itself.

Stanislov hopes = the IETF can=20 work in these areas:

=B7        =20 Cache discovery protocol

=B7        =20 Network information for smart peer = selection

=B7        =20 Experimental congestion control

=B7        =20 BCP on P2P pain

Stanislov = doesn=92t think=20 we=92re ready to do congestion control for P2P yet =96 do a = framework, but don=92t=20 standardize the mechanism yet.

Lars says = there=92s a TSV=20 committee looking at new congestion control mechanisms, but the = participants=20 are all from the long-delay community.

Current = BitTorrent cache=20 discovery protocol is DNS-based, with an SRV record based on the = reverse DNS=20 lookup of your IP address.

Dave Oran asked = for input=20 from DSL and Metro-Ethernet network operators, because he sees the = network=20 characteristics being radically different, and the problem he sees = on=20 deployed networks is under-provisioned aggregation network = links.

3.4          =20 Lightning Talks & General = Discussion

3.4.1           = ;=20 Robb Topolski

This talk covers = about a=20 third of Robb=92s submitted paper.

Robb believes = that the=20 common accusations about P2P file-sharing aren=92t actually true =96 = for=20 example, it=92s very rare for any applications to rate-limit, so = almost all=20 applications will use all available bandwidth.

We need to know = a lot more=20 about the problems we=92re facing (including =93where congestion = actually is=94)=20 in order to solve problems, instead of simply dealing with = effects.

3.4.2           = ;=20 Nick Weaver

The problem with = P2P=20 filesharing is that it shifts cost, doesn=92t save costs. It = increases=20 aggregate costs, and it=92s transport-inefficient.

Could easily = build a=20 BitTorrent cache today =96 all the components are in place. But = it=92s less=20 efficient than HTTP, and it=92s lawsuit-bait for pirated content. =

3.4.3           = ;=20 Leslie Daigle

=93The open, = decentralized=20 nature must be preserved.=94

The problems = aren=92t about=20 P2P technology itself. There=92s an assumption that network = operators=20 won=92t/can=92t adjust the network to meet demand (as P2P supernodes = move).

What are we = trying to=20 do:

=B7        =20 Make P2P networks work better?

=B7        =20 Make applications and networks more aware of = each=20 other?

=B7        =20 Solve the general-case of bandwidth-intensive=20 applications?

=B7        =20 Deal with in-network issues or impact of = cross-network=20 traffic?

3.5          =20 Localization and Caches

3.5.1           = ;=20 Laird Popkin and Haiyong Xie =96 = P4P=20

Average P2P bit = travels 5-7=20 metro hops in Verizon networks =96 network-oblivious P2P = applications may not=20 be network-efficient. Routing information is hidden, TCP rate = control is=20 coarse-grained.

P4P goal is to = design a=20 framework that enables better cooperation between providers and=20 applications.

P4P tracker = provides static=20 topologies, policies, provider capabilities, virtual cost=85

Virtual costs = can be=20 distributed based on provider preferences, but they are talking to = providers=20 about 5-minute refresh windows (for scaling reasons). Costs are = provided by=20 the providers (not currently tied to routing, but could be if = someone wants=20 to provide a feed from routing).

Trials at = Verizon and=20 Telefonica showed significant increases in intra-ISP traffic, = including=20 increase in =93local=94 traffic based on IP prefixes. This was a = large swarm=20 (3500 peers at the peak, 300 after a few days).

Possible IETF = work =96=20 =93trackerless P2P=94 (DNS), lookup mechanisms to find AS-PIDs and = trackers for=20 a given ASN.

Jon asked for = information=20 about what IETF protocols are being modified.

Henning said it = would be=20 nice to have everyone work together, but IETF is slow=85 P4P Forum = doesn=92t=20 think they are doing a standard, they think they are validating a=20 concept.

3.5.2           = ;=20 Yu-Shun Wang =96 P2PI Traffic = Localization -=20 Microsoft

Lots of reasons = to localize=20 =96 apply QoS policy, throttling, admission control =96 but = localization makes=20 the user experience =93non-uniform=94.

Using = multi-layer trackers=20 (global, local, anything in between).

Want to be = =93local=94 =96 but may=20 have to accommodate traffic conditions, load balancing, policy, etc. = Need=20 the right metrics =96 the policy might be NOT to localize.

Most of focus is = on topology=20 matching between link layer and application layer. Caches are easy=20 (long-lived peers) but caches have to be in the right place in order = to gain=20 benefits.

Looking at = tracker=20 redirection/delegation. Prefer off-path for reliability and avoiding = performance bottlenecks.

Eric Burger = asked what=20 incentive people have to deploy a mechanism like this.

Jon liked this=20 paper/presentation because it seemed easy to chop into = engineering-sized=20 parts.

Bob raised a = concern about=20 ISP liability if they are helping pirates choose optimal paths for=20 particular swarms, but if you provide information for all users in = all=20 swarms, this isn=92t scalable.

3.5.3           = ;=20 Vinay Aggrawa =96 ISP-aided = Neighbor=20 Selection =96 DT

Vinay is talking = about=20 something that=92s similar to P4P =96 having a provider supply an = oracle so that=20 any peer can find its =93local neighbors=94.

Henning is = concerned about=20 oracles that dump traffic off-net, and beggar their neighbors.

Dave Oran = thought the oracle=20 would also know who was talking to who now =96 and this approach = doesn=92t have=20 that information yet.

People are = thinking that=20 9000 nodes is a big swarm =96 for legal content with advertising, it = probably=20 isn=92t. We need to think about much larger swarms.

Could just run = oracle as web=20 server/UDP server at well-known location (similar to BIND). Open and = simple=20 solution, open for all overlays.

Oracle service = doesn=92t cache=20 content at ISP, doesn=92t participate in file sharing.

Are ISPs willing = to accept=20 approaches like oracles that rely on interaction with clients? = They=92ve=20 resisted this in the past.

3.5.4           = ;=20 Cullen =96 IETF work on=20 localization?

(Cullen had a = slide of=20 possible work from listening to presentations and = questions/answers)

Leslie =96 still = need to=20 decide what problem we=92re trying to solve=85

EKR =96 people = talked about=20 making clients less aggressive, moving data into caches so it = doesn=92t=20 consume uplink capacity, and choosing better peers. All of = Cullen=92s list was=20 about localization. Doesn=92t seem that localization would be = important to=20 Comcast, and I=92m terrified of the legal issues involved in = caching.

Would be useful = for nodes to=20 find their own locations in a topology =96 find own AS numbers, = etc.

Henning =96 = providing=20 information that customers can=92t verify, can lead to undesirable = situations=20 (like =93hot-potato=94 in routing).

Standardize a = protocol to=20 delegate from global trackers to local trackers? Lisa says lots of = HTTP=20 servers have their own mirror mapping information distribution = mechanisms=20 (proprietary). It=92s possible this would be reusable, but possible = that the=20 two problem spaces are just too different.

Lisa also had = concerns about=20 layer-nine concerns with inter-ISP localization issues.

Why not look at = the entire=20 problem, and not just parts by parts? We did IM as an application, = and=20 Google is starting to use the standardized versions.  Jon thinks that IM came = into the=20 IETF in just the way he=92s thinking of for P2P =96 what are the = parts we=20 need?

Lars =96 we have = transport=20 technologies that aren=92t seeing deployment. Maybe incentives have = changed,=20 but something would have to change in order for new transport stuff = to be=20 deployed. Localized changes, at the point that benefits from the = change, do=20 get deployed.

Lisa is = concerned that=20 localization is one of the technologies that can work in practice, = in a=20 limited environment, but can=92t be standardized =96 because of = issues about=20 trust, accuracy, etc=85

3.6          =20 New Approaches to Congestion

3.6.1           = ;=20 Bob Briscoe

Bob is = presenting Diffserv=20 weighted scheduling versus weighted congestion points.

Diffserv is = typically used=20 without an API, so the application itself does nothing about = Diffserv.

Diffserv isn=92t = designed to=20 work at the granularity of individual users.

When a light = user sends to a=20 heavy user, the light user is using up Diffserv limits in his own = network,=20 only for the traffic to be marked down in the heavy user=92s = network.

Bob is concerned = that we=92re=20 going to end up in the same place as ATM =96 with too many traffic=20 classes.

Bob proposes a = =93congestion=20 harm (cost) metric=94.

Is this anything = like=20 Comcast=92s proposal earlier in the workshop? Important to take what = ISPs are=20 doing now into account as we plan years into the future.

ECN is helpful = but ingress=20 policer can=92t see congestion on the rest of the path.

Bob is asking = the IETF/IRTF=20 to set up a longer-term design team for congestion.

3.6.2           = ;=20 Marcin Matusze

This = presentation is based=20 on conversations with about 20 ISPs.

ISP customer = acquisition=20 costs are much higher than monthly revenue, and cost structure = varies (fixed=20 versus mobile). It=92s difficult to change contracts, and 5 percent = of users=20 generate 75 percent of the traffic.

Mobile network = operators=20 have more tools (volume-based accounting, fixed pricing up to a = limit). Most=20 tools aren=92t widely used.

BT is starting = to use deep=20 packet inspection, and Bob says that=92s 10 times more = cost-effective than=20 adding bandwidth.

Finnish ISPs = were very=20 concerned about P2P traffic in 2004, but much less concerned = today.

3.7          =20 Quality of Service

3.7.1           = ;=20 Mary Barnes =96 QoS-enabled = traffic=20 prioritization

Many service = providers are=20 implementing deep packet inspection, but this isn=92t viable = long-term.

Diffserv can be = implemented=20 today but doesn=92t solve all the problems, and = provisioning/managing still=20 has to look at the events that cause peak usage.

Why hasn=92t = Diffserv been=20 deployed in the past? Maybe the problem is big enough now? Bob says = data is=20 showing that the amount of P2P traffic in the world is = decreasing=85

People are using = QoS =96 just=20 not on the Internet. More than 50 percent of Cisco=92s enterprise = users have=20 turned Diffserv on =96 actually higher than that, for enterprise = VoIP or video=20 users. There=92s a real problem with DSLAMs with very limited = processing=20 capabilities =96 Dave Oran made the point that the problems in = layer-two=20 aggregation networks are severe and overlooked.

3.7.2           = ;=20 Henning Schulzrinne =96 = encouraging=20 bandwidth efficiency

Average TV = consumption in=20 North America for HDTV =3D 972 = GBytes per=20 month =96 reasonable upper limit.

Goal is to = minimize OVERALL=20 cost of content delivery. =20 Focusing only on HTTP efficiency misses the point.

Transit = bandwidth trends=20 changed in 2004 =96 from a steady decline to very little change = since=20 2004.

Cost for sharing = content is=20 a step function =96 moving from the neighborhood to a national = distribution=20 requires different infrastructure.

FIOS TV = architecture is very=20 different from the CATV architecture discussed this morning.

We have a = general discovery=20 problem (network topology, STUN, HELD, LoST, SIP local network=20 configuration=85). We have a variety of solutions (DHCP, DNS, = anycast=85)

If you=92re = volume-based, you=20 need application-visible charging indication to allow people to make = rational decisions. Can the IETF help here?

Misbehaving = applications=20 expose user to risk in a charging situation.

3.8          =20 Conclusions & Wrap

Generalized = =93talking to your=20 local infrastructure=94 mechanism keeps coming up, over and = over.

Indication of = charging would=20 be machine-parsed for any =93rational actor=94 =96 person or = machine.

Eric is = concerned that we=92re=20 identifying so many topics that are application-specific and=20 hard-to-too-hard to generalize into a transport mechanism.

Jon thinks P4P = =93virtual=20 costs=94 makes sense as something we can extract out.

Do we need more = than =93this=20 will be expensive/this will be cheap=94?

=93I=92d be = happy to tag=20 low-priority traffic if that made any difference to me=94 =96 if = ISPs are=20 putting bandwidth caps in place and scavenger-class traffic didn=92t = count,=20 that would make a difference.

Congestion = control isn=92t=20 going to fix the cost issue =96 if we aren=92t going to grow a = network to=20 accommodate increased traffic, we=92re just deciding what order the = packets=20 queue in. The IETF needs to decide what=92s about economics and = what=92s about=20 technology.

Can we stop = whining about=20 P2P using too many TCP connections?

Is it possible = to please all=20 the parties? What if benefits to users and benefits to ISPs are just = incompatible?

We need to be = very cautious=20 about matching up network protocols and economic models =96 this = usually ends=20 badly (micropayments, etc). Focus on technical topics (congestion, = etc).=20

Congestion = arises when=20 there=92s a scarcity, and you allocate resources based on cost = (which may be=20 money, or might be pain). Congestion isn=92t different from cost =96 = ISPs know=20 that. Just because cost proposals haven=92t worked in the past = doesn=92t mean=20 there=92s no way to address cost.

Greg =96 worth = IETF attention,=20 momentum around caching, momentum around optimizing peer selection. = Good to=20 think about whether we bring all of the work in at once. On deep = packet=20 inspection, as a vendor, unless you want to trust host markings, = first-hop=20 routers have to inspect packets and that=92s not cheap.

Cullen =96 = Microsoft API will=20 default-mark voice traffic above router traffic in priority. Unless = we get=20 our act together we=92re headed for a train wreck.

Danny =96 IETF = might want to=20 consider guidelines on application interaction with transport issues = (multiple ports, etc). Mobile networks have all kinds of = differential=20 pricing (nights and weekends), but other providers have no hooks = into=20 charging for things like distance (even though it might cost the = provider=20 more to retrieve a file from Japan).

Lars =96 a lot = of the things=20 we=92re talking about aren=92t just P2P =96 IPTV (for example) might = have many of=20 the same issues. What are the other heavy bandwidth usages of the=20 network?

Bob =96 = congestion isn=92t cost=20 until it becomes part of the contract that you have with a provider = =96 and=20 providers can=92t see congestion outside the provider=92s own = network.

Eric =96 in = economics, pricing=20 is a protocol and tells you when you should spend money. We need to = remember=20 that P2P is about content, too =96 networks that were engineered for = small-request/large-response applications are now carrying servers = from=20 grandmothers.

Stanislov =96 = opening multiple=20 TCP connections isn=92t the problem =96 delay is the same for P2P = and Facebook.=20 (This got responded to: this is only the case when you=92re the only = user on=20 the link =96 but other applications open multiple links, too. = Quoting Dave=20 Oran =96 =93there are non-evil reasons to open multiple TCP = connections and you=20 can=92t tell them=20 apart=94).

------=_NextPart_000_03D3_01C8C10C.1D0D5340-- --===============1227118944== 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 --===============1227118944==-- From p2pi-bounces@ietf.org Thu May 29 03:27: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 87C233A6B01; Thu, 29 May 2008 03:27: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 91A1D3A6B01 for ; Thu, 29 May 2008 03:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 RCOS8v4Yk9ml for ; Thu, 29 May 2008 03:27:06 -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 8E25C3A69AA for ; Thu, 29 May 2008 03:27:03 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so1241871agb.12 for ; Thu, 29 May 2008 03:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:sender:message-id; bh=KLpS82rZgkY7g0TDjoIjCi3J/MMgN5tu2OGWSV0nQC0=; b=URO6p0H7vPvTvgjq7sRJashxJEidTVl9gFHBaMnOdRdrUACygpN7o7JFtm7y/UH1rWR/tDSaJzHcJDNdhjiSggMBkPeaqTw+6wvy/CJCjLbm4FKQ8mqwe6layctjrOapGYqlk3DZZemarBNZHiNjzX/2rJcjF29FtjgGKNmg3qM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:sender:message-id; b=PkYfxYkn6x4iKMooEPrtsd8PqHAekYihHwwrHa4eJO4qFmO3ThF/Vau9uVhnUwVZCD8ftoJZcNATvbxhnM6SZ6QLHriTK46mvIGYwOTX6f+q/rUH2n5SL5Z6t0aVEzSCWSydni53AMTJmRcjrNBGSLaCsyr0Mk8ONm7jdkUBYIs= Received: by 10.150.78.41 with SMTP id a41mr6644290ybb.179.1212056819981; Thu, 29 May 2008 03:26:59 -0700 (PDT) Received: from AMALIS.gmail.com ( [72.93.228.141]) by mx.google.com with ESMTPS id 9sm844097yws.5.2008.05.29.03.26.54 (version=SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 03:26:57 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 May 2008 06:26:51 -0400 To: "John Bartlett" From: "Andrew G. Malis" In-Reply-To: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int > References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int> Mime-Version: 1.0 Message-ID: <483e84f1.0913c00a.2f7b.76ce@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Slide decks from today's meetings? X-BeenThere: p2pi@ietf.org X-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="===============0240533983==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0240533983== Content-Type: multipart/alternative; boundary="=====================_88491187==.ALT" --=====================_88491187==.ALT Content-Type: text/plain; charset="us-ascii" I haven't seen anyone else answer this yet ... you can find the slides at http://www.funchords.com/p2pi/slides/ . Cheers, Andy At 5/28/2008 10:09 PM -0400, John Bartlett wrote: >Are the slide decks from today's (MIT) presentations available? Thanks. > >JB >John Bartlett NetForecast, Inc. >call +1-508-969-4456 skype amlafrance19 --=====================_88491187==.ALT Content-Type: text/html; charset="us-ascii" I haven't seen anyone else answer this yet ... you can find the slides at http://www.funchords.com/p2pi/slides/  .

Cheers,
Andy

At 5/28/2008 10:09 PM -0400, John Bartlett wrote:
Are the slide decks from today's (MIT) presentations available?  Thanks.

JB
John Bartlett      NetForecast, Inc.
call  +1-508-969-4456    skype amlafrance19
--=====================_88491187==.ALT-- --===============0240533983== 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 --===============0240533983==-- From p2pi-bounces@ietf.org Thu May 29 14:05: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 78DAA3A699A; Thu, 29 May 2008 14:05: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 76A423A6B24 for ; Thu, 29 May 2008 14:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdAiEFNQt6zV for ; Thu, 29 May 2008 14:05:03 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 2A4893A699A for ; Thu, 29 May 2008 14:05:01 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id XXW91Z00117dt5G5806X00; Thu, 29 May 2008 21:05:00 +0000 Received: from pc-00144.lodestar2.dyndns.org ([75.68.245.43]) by OMTA13.westchester.pa.mail.comcast.net with comcast id XZ4y1Z00F0wuKUB3ZZ4y3f; Thu, 29 May 2008 21:04:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=uRydnJU0LcMA:10 a=5y7ma6kdFk4A:10 a=BdUeRBzIAAAA:8 a=K5LMGXRQAAAA:8 a=RRX3Wc9-AAAA:8 a=JVZuB4jk8CadxNIzqb0A:9 a=FLD4--2jXOOx7ei6dSVLFc9TskYA:4 a=vxun5xdmOLcA:10 a=ao2En2T6YTgA:10 a=zoKOyUDlhksA:10 Message-Id: <6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> From: Dan York To: p2pi@ietf.org In-Reply-To: <483e84f1.0913c00a.2f7b.76ce@mx.google.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 17:04:58 -0400 References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int> <483e84f1.0913c00a.2f7b.76ce@mx.google.com> X-Mailer: Apple Mail (2.924) Subject: [p2pi] FYI - "Inside the Attack that Crippled Revision3" X-BeenThere: p2pi@ietf.org X-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 Being in the midst of a physical house move, I was unable to attend the session this week (but have been working through the slides and papers), but this post up today, "Inside the Attack that Crippled Revision3", by the CEO of Revision3 certainly speaks to some of the interesting dynamics going on outside the purely technical realm of P2P: http://revision3.com/?p=153 (As well as the need to ensure the security of your P2P software!) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 30 08:45: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 1E49428C1E7; Fri, 30 May 2008 08:45: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 D392028C1FE for ; Fri, 30 May 2008 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 VpXK6ssGOW7X for ; Fri, 30 May 2008 08:45:07 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E9CC43A68EF for ; Fri, 30 May 2008 08:44:49 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 20179198721; Fri, 30 May 2008 18:44:48 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4C130198701; Fri, 30 May 2008 18:44:47 +0300 (EEST) Message-ID: <484020EA.7080904@piuha.net> Date: Fri, 30 May 2008 11:44:42 -0400 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: Ted Hardie , Henning Schulzrinne References: <182597A7-F39D-45E9-8E9E-07A9C9CB50BC@cs.columbia.edu> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Thought on congestion X-BeenThere: p2pi@ietf.org X-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 Ted, Henning, >> I was also a bit surprised by the notion that the top 5/10% of users >> should simply be cut off in some way. This is not economically >> efficient; they might, after all, be willing to pay for the benefit >> they get from all that bandwidth. >> > > I think a different way to ask that question is: "Does it make sense > for users at the top of the usage curve to share infrastructure with > those in the middle?" As I noted in the paper I submitted, lots of > networks are built with specific assumptions about how user > traffic can be multiplexed over the shared resources. It might be > possible to retain those assumptions for a certain period of time > by pushing those who didn't operate in the expected way on to > different infrastructure (requiring that they buy leased-line capacity, > for example); that way the networks' assumptions aren't challenged > by their activity. > > In case it is not obvious, I think that this does not solve the problem, > as the current high-end users are likely just a few years ahead > of the typical consumer; I think we have to re-think the base > usage assumptions to get anywhere in the long term. > Indeed. If the world changed, it does us no good to either cut off the people who were the first to change, or by force make everyone go back to a traffic mix where statistical multiplexing works. At the end of the day, networks exist to satisfy a demand, and it needs to do so while making economic sense for the players involved. Pricing models and service packaging has perhaps even more to do with this than technical solutions. For instance, part of our problem is that Internet service is marketed primarily through nominal link speeds. When assumptions like the efficiency of statistical multiplexing in today's traffic mix change that has a big impact on the way the business can be run. For a given cost, we've actually been selling a combination of peak, average, guaranteed, etc. service without making that very explicit. But it could be made explicit very easily, e.g., gold service = full link speed, silver service = peak can be full, average must be under 50%, etc. If that doesn't sell, well, I guess we learned something about actual demand. This is not to say that there is no need for technical solutions. Clearly, we can improve service under congested/outside the allowed limits situations by better informing the network what traffic should be given higher priority. We can improve the efficiency of the network by better understanding of its topology. And so on. But the point is that at the end of the day, you WANT to serve the p2p, video, etc. traffic as well -- and this may mean increasing your capacity, changing the ratio of access/backbone capacity, changing your subscriber contract deals and prices, as well. Jari _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 30 10: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 E5EBD28C1F5; Fri, 30 May 2008 10: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 4060F3A698F for ; Fri, 30 May 2008 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-46wA5t5Xeb for ; Fri, 30 May 2008 10:08:17 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 4C40A3A69E6 for ; Fri, 30 May 2008 10:07:51 -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 m4UH7oX8027365; Fri, 30 May 2008 10:07:50 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Dan York , p2pi@ietf.org In-Reply-To: <6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 10:07:49 -0700 References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int> <483e84f1.0913c00a.2f7b.76ce@mx.google.com> <6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" X-BeenThere: p2pi@ietf.org X-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 seems strange is that it doesn't sound like a huge volume to me: 8000 SYN/second, with ethernet MTU overhead is ~80 bytes/packet or 5 Mbps. Even being generous and say 10 Mbps. (The .02 second posted TCPdump shows only SYNs, not SYN/ACKs from their server) I could easily see such a load taking down their tracking server through state-handling issues, but as a TRAFFIC DOS which took down their other services it appears downright mild (as they claim outage on both web and mail due to traffic DOS). Thus I could believe the scum at Media Defender's excuse of "We Just F#@)(*ed up" as being the proper one. The following is to NOT defend Media Defender, thats lowlife behavior and they deserve a visit from the Federales, but... I think this is a classic example of why ISPs have to look at the cost shifting issues on bulk-data P2P, and it worries them: This is a company serving LARGE, multimedia files. Its their ENTIRE business model. And they obviously have at least some customers. Yet their central service can't take a 10 Mbps traffic DOS but they want to distribute video which, being generous, is at least 100 kbps/ customer? So this is a company who's BUSINESS is providing LARGE files (HD video), and ideally to a lot of people, and can't (or won't) spring for even remotely decent bandwidth for their critical infrastructure for their tracker, mail, and web server? (Which traceroute to their mail server suggests is in a UnitedLayer colo facility) Let alone serving the actual contents? Why should an ISP want to facilitate such business models? (For reference, if instead they hosted their tracker server at EC2, the entire incremental bandwidth cost for a 10 Mbps attack at $.10/GB over 3 days would be $33. Parking at SFO for three days costs twice as much! Even at a much more expensive per bit colo/managed hosting facility ($. 85/GB), it would still be just a $250 attack, or less than my total reimbursement request! How cheap are they in buying bandwidth?!?) On May 29, 2008, at 2:04 PM, Dan York wrote: > Being in the midst of a physical house move, I was unable to attend > the session this week (but have been working through the slides and > papers), but this post up today, "Inside the Attack that Crippled > Revision3", by the CEO of Revision3 certainly speaks to some of the > interesting dynamics going on outside the purely technical realm of > P2P: > > http://revision3.com/?p=153 > > (As well as the need to ensure the security of your P2P software!) > > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > _______________________________________________ > 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 May 30 13:16: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 ED9013A67F6; Fri, 30 May 2008 13:16: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 0A1A93A67F6 for ; Fri, 30 May 2008 13:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIxyEBhs32gR for ; Fri, 30 May 2008 13:16:38 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 999C83A63D3 for ; Fri, 30 May 2008 13:16:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so149897and.122 for ; Fri, 30 May 2008 13:16:35 -0700 (PDT) Received: by 10.100.123.4 with SMTP id v4mr9785628anc.107.1212178595646; Fri, 30 May 2008 13:16:35 -0700 (PDT) Received: from TOPOL009 ( [76.115.95.63]) by mx.google.com with ESMTPS id f57sm1025116pyh.38.2008.05.30.13.16.34 (version=SSLv3 cipher=RC4-MD5); Fri, 30 May 2008 13:16:34 -0700 (PDT) From: "Robb Topolski" To: References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int><483e84f1.0913c00a.2f7b.76ce@mx.google.com><6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> Date: Fri, 30 May 2008 15:16:32 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 thread-index: AcjCeC5g6urX9gMARfeh7+69EL2WPAAFz/Yg In-Reply-To: Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" X-BeenThere: p2pi@ietf.org X-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 LOL @ "parking at SFO" A tracker does not normally need a lot of CPU, so they probably didn't have a big machine there. 8000 packets per second is huge volume to a machine capable to run a tracker, and SYN packets being the state-changing things that they are, the load isn't just in moving bits from one process to another. There's probably a lot of allocation going on there. I haven't figured out whether to care about this too much. It sounds like MD was exploiting Revision3's open tracker and when Revision3 closed them late on a Friday before a long holiday, their scripts ran away on some code not adequately tested. Certainly MD didn't commit an intentional DOS attack. While MD looks responsible, it sounds like Amateur Hour on both sides of the wire. "Nick: I think this is a classic example of why ISPs have to look at the cost shifting issues on bulk-data P2P, and it worries them." They can look but it's really bandwidth made available for their consumers to use or not use. It's legal, disclosed, and it's not harmful. (Now if the consumers are conned into giving up bandwidth by a P2P app that doesn't advertise itself as such, I agree that's a different story.) It was nice matching a face to a name this week. You don't look anything like I had imagined. Despite areas were we might disagree, you had some good ideas. --Robb -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Nicholas Weaver Sent: Friday, May 30, 2008 12:08 PM To: Dan York; p2pi@ietf.org Cc: Nicholas Weaver Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" One thing that seems strange is that it doesn't sound like a huge volume to me: 8000 SYN/second, with ethernet MTU overhead is ~80 bytes/packet or 5 Mbps. Even being generous and say 10 Mbps. (The .02 second posted TCPdump shows only SYNs, not SYN/ACKs from their server) I could easily see such a load taking down their tracking server through state-handling issues, but as a TRAFFIC DOS which took down their other services it appears downright mild (as they claim outage on both web and mail due to traffic DOS). Thus I could believe the scum at Media Defender's excuse of "We Just F#@)(*ed up" as being the proper one. The following is to NOT defend Media Defender, thats lowlife behavior and they deserve a visit from the Federales, but... I think this is a classic example of why ISPs have to look at the cost shifting issues on bulk-data P2P, and it worries them: This is a company serving LARGE, multimedia files. Its their ENTIRE business model. And they obviously have at least some customers. Yet their central service can't take a 10 Mbps traffic DOS but they want to distribute video which, being generous, is at least 100 kbps/ customer? So this is a company who's BUSINESS is providing LARGE files (HD video), and ideally to a lot of people, and can't (or won't) spring for even remotely decent bandwidth for their critical infrastructure for their tracker, mail, and web server? (Which traceroute to their mail server suggests is in a UnitedLayer colo facility) Let alone serving the actual contents? Why should an ISP want to facilitate such business models? (For reference, if instead they hosted their tracker server at EC2, the entire incremental bandwidth cost for a 10 Mbps attack at $.10/GB over 3 days would be $33. Parking at SFO for three days costs twice as much! Even at a much more expensive per bit colo/managed hosting facility ($. 85/GB), it would still be just a $250 attack, or less than my total reimbursement request! How cheap are they in buying bandwidth?!?) On May 29, 2008, at 2:04 PM, Dan York wrote: > Being in the midst of a physical house move, I was unable to attend > the session this week (but have been working through the slides and > papers), but this post up today, "Inside the Attack that Crippled > Revision3", by the CEO of Revision3 certainly speaks to some of the > interesting dynamics going on outside the purely technical realm of > P2P: > > http://revision3.com/?p=153 > > (As well as the need to ensure the security of your P2P software!) > > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > _______________________________________________ > 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 May 30 15:17: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 852BC3A6B0F; Fri, 30 May 2008 15:17: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 35F773A6B0F for ; Fri, 30 May 2008 15:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.06 X-Spam-Level: X-Spam-Status: No, score=-5.06 tagged_above=-999 required=5 tests=[AWL=1.539, 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 Xe2pUDs4F8FQ for ; Fri, 30 May 2008 15:17:12 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 50E303A6AC2 for ; Fri, 30 May 2008 15:17:12 -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 m4UMH8Kp027499; Fri, 30 May 2008 15:17:08 -0700 (PDT) Message-Id: <3603DD00-748E-48EF-9E9B-CBBDB39D7C1C@icsi.berkeley.edu> From: Nicholas Weaver To: "Robb Topolski" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 15:17:10 -0700 References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@orange.brnets.int><483e84f1.0913c00a.2f7b.76ce@mx.google.com><6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" X-BeenThere: p2pi@ietf.org X-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 May 30, 2008, at 1:16 PM, Robb Topolski wrote: > LOL @ "parking at SFO" > > A tracker does not normally need a lot of CPU, so they probably > didn't have > a big machine there. 8000 packets per second is huge volume to a > machine > capable to run a tracker, and SYN packets being the state-changing > things > that they are, the load isn't just in moving bits from one process to > another. There's probably a lot of allocation going on there. > It isn't just the tracker. It took down (alegedly) their mail server and web server as well. So <10 Mbps was enough to DoS not jsut the tracker but their entire IT infrastructure! which is located in a colo facility (so bandwidth is cheap). > I haven't figured out whether to care about this too much. It > sounds like > MD was exploiting Revision3's open tracker and when Revision3 closed > them > late on a Friday before a long holiday, their scripts ran away on > some code > not adequately tested. Certainly MD didn't commit an intentional DOS > attack. While MD looks responsible, it sounds like Amateur Hour on > both > sides of the wire. > Actually, it sounds like MD was tracking those who were exploiting Revision3's open tracker. They were set up to agressively monitor, and when they found a hash in the open tracker that was being used to host questinable material, they kept on it. And when all those hashes all got removed at the same time, their monitor went bonkers as it tried to reconnect to every single hash all at once. At least, thats what I'd be doing. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri May 30 15:38: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 091993A6C52; Fri, 30 May 2008 15:38: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 EA5473A6C4E for ; Fri, 30 May 2008 15:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHWgwUWgZtIg for ; Fri, 30 May 2008 15:38:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C1D013A6C73 for ; Fri, 30 May 2008 15:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1212186937; x=1243722937; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<3603DD00-748E-48EF-9E9B -CBBDB39D7C1C@icsi.berkeley.edu>|References:=20<90D8CEF754D7D9448BA111 72BB50=0D=0A=2044320896CDE8@orange.brnets.int><483e84f1.0 913c00a.2f7b.76ce@mx.google.com>=0D=0A=20<6FA8D5A0-12DC-4 CCD-98A7-CA63134F7E74@voxeo.com>=0D=0A=20=0D=0A=20=0D=0A=20<3603DD00-7 48E-48EF-9E9B-CBBDB39D7C1C@icsi.berkeley.edu>|Date:=20Fri ,=2030=20May=202008=2015:35:30=20-0700|To:=20Nicholas=20W eaver=20,=0D=0A=20=20=20=20=20 =20=20=20Robb=20Topolski=0D=0A=09 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20[p2pi]=20FYI=20-=20"Inside=20the=20Attack=20that=20 Crippled=20Revision3"|CC:=20"p2pi@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20Nicholas=20Weaver=0D =0A=09|Content-Type:=20text/pl ain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5200,2160,5307"=3B=20a=3D"3365590"; bh=gvHz/u54pV3zaVmTBkWSt6WiPDU4PIAirmprXYbiO44=; b=OqDSO8o2aYuJKbZp6WBV84i5+O2sLBrsqF42WcB6VwUA2DUKqD14FXfb xK6FLlIVZjs3C+VMYj1I1pX28vsmhjBQbLm0FbrvOXaL/vpP23H8HE0uY /Ebaa7TDwsOlDfq4AvWqb9YKbUmHsZ8Uqf8PyZakOpeGfBJFy/vNvgVHg 0=; X-IronPort-AV: E=McAfee;i="5200,2160,5307"; a="3365590" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 May 2008 15:35:35 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4UMZYTB015089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 May 2008 15:35:34 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4UMZYVk009552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 May 2008 15:35:34 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 30 May 2008 15:35:33 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <3603DD00-748E-48EF-9E9B-CBBDB39D7C1C@icsi.berkeley.edu> References: <90D8CEF754D7D9448BA11172BB50 44320896CDE8@orange.brnets.int><483e84f1.0913c00a.2f7b.76ce@mx.google.com> <6FA8D5A0-12DC-4CCD-98A7-CA63134F7E74@voxeo.com> <3603DD00-748E-48EF-9E9B-CBBDB39D7C1C@icsi.berkeley.edu> Date: Fri, 30 May 2008 15:35:30 -0700 To: Nicholas Weaver , Robb Topolski From: Ted Hardie Cc: Nicholas Weaver , "p2pi@ietf.org" Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" X-BeenThere: p2pi@ietf.org X-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 At 3:17 PM -0700 5/30/08, Nicholas Weaver wrote: > >It isn't just the tracker. It took down (alegedly) their mail server >and web server as well. So <10 Mbps was enough to DoS not jsut the >tracker but their entire IT infrastructure! which is located in a colo >facility (so bandwidth is cheap). As you noted before, tracker servers are typically low usage systems. My guess (with no evidence at all, mind you) is that they put the tracker server on something else that already needed to be in their DMZ, like the DNS server, NAT, or Firewall. That level of SYN flood would chew through the system resources for networking on pretty much any single box, so any other services on that box would die as a result. In other words, it likely wasn't bandwidth, but fate-sharing that got them. regards, Ted _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi